Discussion about the Signer and how to have a remote signing environment out of the box

[nGoline]

We know how important it is to support remote signers.

The question here is: What transport layer should we use between the daemon and the signer?
I'll start by enumerating what layer some of the current implementations use:

• CLinghtning: They use a separate executable that communicates through File Descriptors, meaning they both have to live in the same machine.
• LND: Since their signer lives within the daemon, they decided to use two daemons, one running as a "watch-only" node that signs the transactions, and the other running as a "full-node". They communicate via gRPC.

Nowadays every company has access to a queue or pub/sub service, like RMQ, SQS, or Kafka. I believe that even Redis or Garnet should be enough for this task.

For the first iteration, we could:

• Segregate the Signer to another project, hence having another executable;
• Follow what CLightning does and have one signer instance per channel;
• Use Noise to encrypt communication between the daemon and the signer.

Since pub/sub is inherently network native, this approach could pave the way to a distributed signing system, minimizing attack vectors and availability.

[marceloceccon]

Hi there, long time no see. Awesome project.

Masstransit might be a good call,I haven't had the chance to use it yet but have followed the progress for sometime, it would be a fully fledged comm's layer that allows choosing between several underlying engines.

https://masstransit.io/

https://github.com/MassTransit/MassTransit

[nGoline]

Hey, good to see you here.

Thanks for your comment, I gave it a quick read. It looks very well written.
When the time comes I'll give it a try.

I don't know if you've been following Lightning closely enough and had a chance to use the other implementations yet, but feel free to start discussions that would help our development.

[marceloceccon]

Nowhere near close enough that's for certain hence the interest at such an early stage of the C# implementation. Looking forward for its progress and success.

[rsafier]

took a look at this library and played around with some benchmarks with rabbitmq locally. easy to consume.

[rsafier]

I don't think the daemon should be opinionated on transport of remote signing, just have good hooks for it (simple DTO objects/interface).
The interface implementor deals with those details in a dynamically loaded plugin library that handles those functions.
I suppose the first signing plugin should just use that interface for local signing.

[nGoline]

So you think what Eclair has been doing with plug-ins are the best path forward?
I like the way Clightning has N signers for N channels, isolating the Signer execution from the Daemon altogether.

Dotnet offers a nice isolation layer when it comes to parallel Tasks throwing, though. Maybe I'm worrying too much about isolating the Signer in another process.

[rsafier]

We can always expose node subsystems thru that plug-in interface, that way the plugin can still talk to other subsystems if needed.

I also am partial to having abstraction for channel manager as well, allows for more experimentation like how hosted channels was able to be added to CLN.

[nGoline]

Great points on both the plugin interface and the channel manager abstraction. Exposing node subsystems through plugins opens up significant flexibility and mirrors the successful modular approach seen with CLN's hosted channels.
It's a strong direction for encouraging innovation and adaptability in our architecture.
Looking forward to exploring these concepts further and integrating them into our roadmap.