Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BCCB5480 for ; Tue, 15 Aug 2017 01:33:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 791C2E4 for ; Tue, 15 Aug 2017 01:33:36 +0000 (UTC) Received: by mail-wm0-f44.google.com with SMTP id f15so5771052wmg.1 for ; Mon, 14 Aug 2017 18:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0c1Q0G7CfuFT8VzH4KBDc3HaIsmPipFAQD4WO6Qqu3w=; b=liUK2FAB2QuWXM2PjeISZR+I6T++nlG2iP/lEEAG558Jp+N3tLXtFDwlhhFjAaj7sZ 2V2WaJd8MFv2r4hd30srynVm2xLDNLRXPGNA08pMTB0VvzVnu8y8HYX3CT0NLOgYHW/d 9PwAYfgrR9+w/TiSvwWlJMcvzvWYNvkjKjfyosrerapy12tld9Rqp7iYL3ihNnJHBjv6 eECB5NRIh12I1MVoFzoOGhanqnKbJgXXJRYIBOxDwDsQs5vIGD/T/3ohdDP9NUQfpE1z R4rMzbQQtMhLfl4SrWk+UZhhSzocAqe6gQvRqBXRLPUmoK65qxGWAbObdRQxaSEjRqlz vTbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0c1Q0G7CfuFT8VzH4KBDc3HaIsmPipFAQD4WO6Qqu3w=; b=k04OWyLSi5nfbRRktWLdbM/tB4fKfXkOadX5yCSDBhBlSb3E87NndEgty3fdfQCGut 3lCyXL1SK2FK8v03IiD1dgUaT2BI8HrMI5n0U30HYwMOxIjPaCgiw0MpQeeWFqfSpgY3 Z0YE12QNZzdq+IKcTlxjBZnT4g5mBFt5vVKVP7zYaH2C1H4ke8QT+34GthzBieUjFPnC Kin7EIYBRAzFdyjOo3487esu8NejvJ7YGslbvs8naOil8DOPhtSBPf88Pnss+7UzxNCn IGphu0OKTGdFdtyhFDlRPZuPPma3Tzodf+X7NolKVu1m+EC7wQgfZ+q/VS/uU9Z1n4+0 tvIg== X-Gm-Message-State: AHYfb5jj4fmTfd7XE8/PQU5bUE8QujTPqp7kJKF7+Yzx7hqiyq4mho11 TLa5imgz+DcF8G6U46K6EURkH71+YQ== X-Received: by 10.28.12.201 with SMTP id 192mr373985wmm.45.1502760815041; Mon, 14 Aug 2017 18:33:35 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.28.199.204 with HTTP; Mon, 14 Aug 2017 18:33:34 -0700 (PDT) In-Reply-To: References: <45BBAF76-CDB7-4D57-920C-70887CABFF48@jonasschnelli.ch> From: Erik Aronesty Date: Mon, 14 Aug 2017 21:33:34 -0400 X-Google-Sender-Auth: bxSyosJRbfJwsGMiqbh3rrmtcIY Message-ID: To: Mark Friedenbach Content-Type: multipart/alternative; boundary="001a1144284c9024ab0556c0c46b" X-Mailman-Approved-At: Tue, 15 Aug 2017 02:31:35 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Would anyone object to adding a dlopen message hook system? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 01:33:36 -0000 --001a1144284c9024ab0556c0c46b Content-Type: text/plain; charset="UTF-8" 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 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 > 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 > > > --001a1144284c9024ab0556c0c46b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Actually the more I think about it, the more I realiz= e 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 f= unctions, I can do everything I need.

On Sun, Aug 13, 2017 at 4:56 PM, Mark Fried= enbach <mark@friedenbach.org> wrote:
Jonas, I think his proposal is to enable extending the P2P la= yer, 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@li= sts.linuxfoundation.org> wrote:
> Hi Erik
>
> Thanks for your proposal.
> In general, modularisation is a good thing, though proposing core to a= dd modules wie dlopen() seems the wrong direction.
> Core already has the problem of running to many things in the same pro= cess. 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 abilit= y for module extensions in the core client.
>>
>> When messages are received, modules hooks are called with the mess= age data.
>>
>> They can then handle, mark the peer invalid, push a message to the= peer or pass through an alternate command.=C2=A0 Also, modules could have = their own private commands prefixed by "x:" or something like tha= t.
>>
>> The idea is that the base P2P layer is left undisturbed, but there= is now a way to create "enhanced features" that some peers suppo= rt.
>>
>> My end goal is to support using lightning network micropayments to= allow people to pay for better node access - creating a market for node se= rvices.
>>
>> But I don't think this should be "baked in" to core.= =C2=A0 =C2=A0Nor do I think it should be a "patch".=C2=A0 =C2=A0I= t should be a linked-in module, optionally compiled and added to bitcoin co= nf, then loaded via dlopen().=C2=A0 =C2=A0 Modules should be slightly robus= t to Bitcoin versions changing out from under them, but not if the network = layer is changed.=C2=A0 =C2=A0This can be ensured by a) keeping a module ve= rsion number, and b) treating module responses as if they were just receive= d from the network.=C2=A0 =C2=A0Any module incompatibility should throw an = exception...ensuring broken peers don't stay online.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a1144284c9024ab0556c0c46b--