Actually the more I think about it, the more I realize that all I need is to listen on a new port, and use the RPC api to affect Bitcoin:
- ban a peer (# of hours) - unban a peer (# of hours) As long as I have those two functions, I can do everything I need. On Sun, Aug 13, 2017 at 4:56 PM, Mark Friedenbach <m...@friedenbach.org> wrote: > 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
