Jonas, I think his proposal is to enable extending the P2P layer, e.g. adding new message types. Are you suggesting having externalized message processing? That could be done via RPC/ZMQ while opening up a much more narrow attack surface than dlopen, although I imagine such an interface would require a very complex API specification.
On Sun, Aug 13, 2017 at 1:00 PM, Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Erik > > Thanks for your proposal. > In general, modularisation is a good thing, though proposing core to add > modules wie dlopen() seems the wrong direction. > Core already has the problem of running to many things in the same process. > The consensus logic, p2p system as well as the wallet AND the GUI do all > share the same process (!). > > A module approach like you describe would be a security nightmare (and Core > is currently in the process of separating out the wallet and the GUI into its > own process). > > What does speak against using the existing IPC interfaces like RPC/ZMQ? > RPC can be bidirectional using long poll. > > /jonas > >> I was thinking about something like this that could add the ability for >> module extensions in the core client. >> >> When messages are received, modules hooks are called with the message data. >> >> They can then handle, mark the peer invalid, push a message to the peer or >> pass through an alternate command. Also, modules could have their own >> private commands prefixed by "x:" or something like that. >> >> The idea is that the base P2P layer is left undisturbed, but there is now a >> way to create "enhanced features" that some peers support. >> >> My end goal is to support using lightning network micropayments to allow >> people to pay for better node access - creating a market for node services. >> >> But I don't think this should be "baked in" to core. Nor do I think it >> should be a "patch". It should be a linked-in module, optionally compiled >> and added to bitcoin conf, then loaded via dlopen(). Modules should be >> slightly robust to Bitcoin versions changing out from under them, but not if >> the network layer is changed. This can be ensured by a) keeping a module >> version number, and b) treating module responses as if they were just >> received from the network. Any module incompatibility should throw an >> exception...ensuring broken peers don't stay online. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
