path: root/f8/5063d9c49fe60f1623c631a8645d170b0fc8e5

Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BCCB5480
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 15 Aug 2017 01:33:36 +0000 (UTC)
Received: by mail-wm0-f44.google.com with SMTP id f15so5771052wmg.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAOG=w-v8PnzLSKsZh1xcVpjXqtTczNBsh6qEjtQ-HqpoZQLoiA@mail.gmail.com>
References: <CAJowKgLXhS2SxwuJnfbHzKSzw+aZie5aO2EsC9qbwWJXMNDuRw@mail.gmail.com>
	<45BBAF76-CDB7-4D57-920C-70887CABFF48@jonasschnelli.ch>
	<CAOG=w-v8PnzLSKsZh1xcVpjXqtTczNBsh6qEjtQ-HqpoZQLoiA@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Mon, 14 Aug 2017 21:33:34 -0400
X-Google-Sender-Auth: bxSyosJRbfJwsGMiqbh3rrmtcIY
Message-ID: <CAJowKgLd4u4xZJiRW3uCh823zgcTvcM3Q31VkEjXAorS8=1SxQ@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary="001a1144284c9024ab0556c0c46b"
X-Mailman-Approved-At: Tue, 15 Aug 2017 02:31:35 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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
> >
>

--001a1144284c9024ab0556c0c46b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>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:</div><div><br></div><div>- ban a peer (# of hours)<br></div><div>=
- unban a peer (# of hours)<br><br></div><div>As long as I have those two f=
unctions, I can do everything I need.</div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Sun, Aug 13, 2017 at 4:56 PM, Mark Fried=
enbach <span dir=3D"ltr">&lt;<a href=3D"mailto:mark@friedenbach.org" target=
=3D"_blank">mark@friedenbach.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Jonas, I think his proposal is to enable extending the P2P la=
yer, e.g.<br>
adding new message types. Are you suggesting having externalized<br>
message processing? That could be done via RPC/ZMQ while opening up a<br>
much more narrow attack surface than dlopen, although I imagine such<br>
an interface would require a very complex API specification.<br>
<div><div class=3D"h5"><br>
On Sun, Aug 13, 2017 at 1:00 PM, Jonas Schnelli via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt; Hi Erik<br>
&gt;<br>
&gt; Thanks for your proposal.<br>
&gt; In general, modularisation is a good thing, though proposing core to a=
dd modules wie dlopen() seems the wrong direction.<br>
&gt; 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 (!).<br>
&gt;<br>
&gt; 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).<br>
&gt;<br>
&gt; What does speak against using the existing IPC interfaces like RPC/ZMQ=
?<br>
&gt; RPC can be bidirectional using long poll.<br>
&gt;<br>
&gt; /jonas<br>
&gt;<br>
&gt;&gt; I was thinking about something like this that could add the abilit=
y for module extensions in the core client.<br>
&gt;&gt;<br>
&gt;&gt; When messages are received, modules hooks are called with the mess=
age data.<br>
&gt;&gt;<br>
&gt;&gt; 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 &quot;x:&quot; or something like tha=
t.<br>
&gt;&gt;<br>
&gt;&gt; The idea is that the base P2P layer is left undisturbed, but there=
 is now a way to create &quot;enhanced features&quot; that some peers suppo=
rt.<br>
&gt;&gt;<br>
&gt;&gt; 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.<br>
&gt;&gt;<br>
&gt;&gt; But I don&#39;t think this should be &quot;baked in&quot; to core.=
=C2=A0 =C2=A0Nor do I think it should be a &quot;patch&quot;.=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&#39;t stay online.<br>
&gt;<br>
&gt;<br>
</div></div>&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
</blockquote></div><br></div>

--001a1144284c9024ab0556c0c46b--