public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jonas Schnelli <dev@jonasschnelli•ch>
To: Erik Aronesty <erik@q32•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Would anyone object to adding a dlopen message hook system?
Date: Sun, 13 Aug 2017 22:00:41 +0200	[thread overview]
Message-ID: <45BBAF76-CDB7-4D57-920C-70887CABFF48@jonasschnelli.ch> (raw)
In-Reply-To: <CAJowKgLXhS2SxwuJnfbHzKSzw+aZie5aO2EsC9qbwWJXMNDuRw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]

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.


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-08-13 20:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-13 18:46 Erik Aronesty
2017-08-13 20:00 ` Jonas Schnelli [this message]
2017-08-13 20:56   ` Mark Friedenbach
2017-08-15  1:33     ` Erik Aronesty
     [not found]       ` <CANAdVnpvEUBWbPa5BUOift-2R783Kc7fKa7xdLkqSgpqCaTp1g@mail.gmail.com>
2017-08-15  4:44         ` Erik Aronesty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45BBAF76-CDB7-4D57-920C-70887CABFF48@jonasschnelli.ch \
    --to=dev@jonasschnelli$(echo .)ch \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=erik@q32$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox