Published on: 2017-08-15T04:44:52+00:00
The discussion revolves around extending the P2P layer of Bitcoin through the addition of module extensions. Erik Voorhees proposed this idea, suggesting that these modules could be loaded via dlopen() and would allow for the creation of enhanced features that certain peers could support. The main goal is to enable lightning network micropayments, allowing users to pay for better node access and ultimately creating a market for node services.However, Jonas Schnelli expressed concern about the security implications of adding modules like dlopen() to the core client. He argued that the current setup, where the consensus logic, p2p system, wallet, and GUI all share the same process, already poses security risks. Instead, he suggested utilizing existing IPC interfaces like RPC/ZMQ, which can provide bidirectional communication using long poll.Erik's proposal involved calling module hooks with message data when messages are received. These hooks would then have the ability to handle the message, mark the peer as invalid, push a message to the peer, or pass through an alternate command. Modules would also have the option to include their own private commands prefixed by "x:". To implement this, Erik suggested having linked-in modules that can be optionally compiled and added to the bitcoin conf file, and then loaded via dlopen(). These modules should be robust enough to handle changes in Bitcoin versions, but not if there are changes in the network layer. Incompatibility between modules should throw an exception to ensure broken peers don't stay online.In general, the writer believes that the core reference could benefit from the ability to create subnetworks within the Bitcoin ecosystem. The proposed MessageHookIn, MessageHookOut, and MessageHook classes illustrate how such a module/hook system could be implemented to extend the functionality of the P2P layer.
Updated on: 2023-08-01T21:25:59.232565+00:00