public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Erik Aronesty <erik@q32.com>
To: Mark Friedenbach <mark@friedenbach.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Would anyone object to adding a dlopen message hook system?
Date: Mon, 14 Aug 2017 21:33:34 -0400	[thread overview]
Message-ID: <CAJowKgLd4u4xZJiRW3uCh823zgcTvcM3Q31VkEjXAorS8=1SxQ@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-v8PnzLSKsZh1xcVpjXqtTczNBsh6qEjtQ-HqpoZQLoiA@mail.gmail.com>

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

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 <mark@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
> >
>

[-- Attachment #2: Type: text/html, Size: 3936 bytes --]

  reply	other threads:[~2017-08-15  1:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-13 18:46 [bitcoin-dev] Would anyone object to adding a dlopen message hook system? Erik Aronesty
2017-08-13 20:00 ` Jonas Schnelli
2017-08-13 20:56   ` Mark Friedenbach
2017-08-15  1:33     ` Erik Aronesty [this message]
     [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='CAJowKgLd4u4xZJiRW3uCh823zgcTvcM3Q31VkEjXAorS8=1SxQ@mail.gmail.com' \
    --to=erik@q32.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=mark@friedenbach.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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