1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3759FE2D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Aug 2017 20:57:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f42.google.com (mail-it0-f42.google.com
[209.85.214.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 247C8133
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Aug 2017 20:57:01 +0000 (UTC)
Received: by mail-it0-f42.google.com with SMTP id 77so14098063itj.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Aug 2017 13:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=mjkGVneqXEUZLoASLsYj61PBA1AW4F54QYZDpn6HxfE=;
b=MockqweHStoTFUginVn9B31GGjgPaCV2IO/auGHwk7G9oKtvSrUlD27wfMjbNnQEnM
4YAeAOK2VngSZmPm6EkfjME2MZW7DGHqy8vnQ1FoKSkyP3s0WoLjp3YOS/WZzealTfBn
qG70MxHu3qlYUp2SE+ay+acagqugpHJ38Zz/AdJPhBbwkSI+s0sIMX9ACuao44K8vNZV
iWGTNaXe13uGyM1EMjrc4xGQENH0CW2TlDWMS25y0/Z4Xo0tEZApFJIvEzFdLdnLZ16C
7Mz7klk+5QiNOWhzFOpLxqSypOfhWjCGpObOE5EHcpF19+6bbg4NlH4slUQ4blkjVfEY
Fyvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=mjkGVneqXEUZLoASLsYj61PBA1AW4F54QYZDpn6HxfE=;
b=Fe4Vu5syaujxjXkeT7oILAwVNeyfg+mRerN0LO0N9NXtbiXZs6LMpTsK6/a9P0l0wr
wATUkwnzCi1RL7mkk1Wq5OQYCk24/tHBIxIxmoC4ECXhC5N4UH5O+EDwTFlwREq2hqUL
gvZJNdySGzD/sL76Xun8NQNme38vqHGpS0LBIMJ21D0OM+5VSyrZFeQrX5T4HeTPhSDm
UFp3QcvsvY1rmguZamiDKdgPNRg46SWQDBARWHYz/dp/DSD1oueuRZ7WsiOreVQ9vMQX
tz9eGPSi2qBi4YTygo8QdD7mefpWMAKZ8ODw39x3IjuUK3OVZxXN02wA3xUCVADBInpb
nOrA==
X-Gm-Message-State: AHYfb5gUrAg2hq42OkJFpKsLO9cChRN/+69tH/ZcV2F15Rai3TJEM4fU
UPLaBytzUjSSRt31GZS2NlkPhYGDkvuQ
X-Received: by 10.36.192.137 with SMTP id u131mr4569053itf.35.1502657820408;
Sun, 13 Aug 2017 13:57:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.148.82 with HTTP; Sun, 13 Aug 2017 13:56:39 -0700 (PDT)
X-Originating-IP: [67.161.52.102]
In-Reply-To: <45BBAF76-CDB7-4D57-920C-70887CABFF48@jonasschnelli.ch>
References: <CAJowKgLXhS2SxwuJnfbHzKSzw+aZie5aO2EsC9qbwWJXMNDuRw@mail.gmail.com>
<45BBAF76-CDB7-4D57-920C-70887CABFF48@jonasschnelli.ch>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Sun, 13 Aug 2017 13:56:39 -0700
Message-ID: <CAOG=w-v8PnzLSKsZh1xcVpjXqtTczNBsh6qEjtQ-HqpoZQLoiA@mail.gmail.com>
To: Jonas Schnelli <dev@jonasschnelli.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 13 Aug 2017 20:59:39 +0000
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: Sun, 13 Aug 2017 20:57:01 -0000
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 proces=
s. 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 Co=
re is currently in the process of separating out the wallet and the GUI int=
o 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 da=
ta.
>>
>> 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 p=
rivate commands prefixed by "x:" or something like that.
>>
>> The idea is that the base P2P layer is left undisturbed, but there is no=
w 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 compile=
d 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 modu=
le version number, and b) treating module responses as if they were just re=
ceived from the network. Any module incompatibility should throw an excep=
tion...ensuring broken peers don't stay online.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
