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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
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 239E1CED
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Aug 2017 18:46:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com
[209.85.128.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D47871F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Aug 2017 18:46:39 +0000 (UTC)
Received: by mail-wr0-f169.google.com with SMTP id 26so12579129wrt.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Aug 2017 11:46:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:from:date:message-id:subject:to;
bh=M3mvfuExcTJ0t2zZeBlzwrsZJDSHL7X2IhlfawXhhH4=;
b=bzXv9QvDlzYRrV0pjdn63UY7Z7OJ3BT0eDaKXLYjA3lxQRGL/BEYYUn3pssc7lh68y
sUerdBjmfoKhFSRcc2WjSD7Z8DrfxCYlieHSlvINg5f0UZfVRZSjUdVCuPt911EeUyb4
6DeYVbwgbnH/TKXPVkS1/RFusY9HpT3+nyBs0AyVkotCX0jK+b3mQu0tMcEpgyUJtZbV
dHveZcRlLkuVJ6E2wosD/OUfEXvFIqpzobCiFJAfHrQNVZxyxq1jvuwBtVBe1tac+n/6
kpjFRCsUdn/X56g7VyLlq5Y9x6YnZeZUleqHmPA9l2gwgPX/A6RW5KhcrRESQ2lRpAR5
NDBw==
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:from:date:message-id:subject
:to; bh=M3mvfuExcTJ0t2zZeBlzwrsZJDSHL7X2IhlfawXhhH4=;
b=lhfrw2OJv8snVXSNFAz4vtt8NFHWCnmJnSOeujG2tqEsPfDnuN4mVnBqALQTPwTjNq
sKWKKoLX1Qq7BxVguxmQ5Gt/853whby0QBrVDtY4jrbOZJCT1KWOIF/TnhO8nM8YtzwN
GFv9rJ+k1hy91cEMt978/Tw3A8Em54Yd+UeCROBb0bV+o9pyzXsf4UzDs2sBaEuQN7NU
QrHnWThRATbijM03EMtvd1MkylSYYkM9uq+M/kC5UhF4Qt8MD2XXDRza2IZBq2V3/tij
NBt4beI9rsTM4asiDKjL+BKXqAFcpfozREJwZLKb6csubdsvo5u5Y4IKNjLpi7SwmhCO
mTKQ==
X-Gm-Message-State: AHYfb5hOzn8aPnB8YpPuat6CWXgz1N3jFRYRTprIGbNuKBgTJ09Q+dsr
X4fNMuiyq+xbTr2IsqJmG8fUw47113RP21U=
X-Received: by 10.223.134.134 with SMTP id 6mr14494465wrx.255.1502649998148;
Sun, 13 Aug 2017 11:46:38 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.28.199.204 with HTTP; Sun, 13 Aug 2017 11:46:37 -0700 (PDT)
From: Erik Aronesty <erik@q32.com>
Date: Sun, 13 Aug 2017 14:46:37 -0400
X-Google-Sender-Auth: wXd9GRW9riC02CXUlZbYnX-roeA
Message-ID: <CAJowKgLXhS2SxwuJnfbHzKSzw+aZie5aO2EsC9qbwWJXMNDuRw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a11459da05c8cbb0556a6f782"
X-Mailman-Approved-At: Sun, 13 Aug 2017 19:19:09 +0000
Subject: [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 18:46:40 -0000
--001a11459da05c8cbb0556a6f782
Content-Type: text/plain; charset="UTF-8"
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.
In general I think the core reference would benefit from the ability to
create subnetworks within the Bitcoin ecosystem. Right now, we have two
choices... full node and get slammed with traffic, or listen-only node, and
do nothing.
Adding a module/hook system would allow a complex ecosystem of
participation - and it would seem to be far more robust in the long term.
Something like this???
class MessageHookIn {
public:
int hookversion;
int64_t nodeid;
int nVersion;
int64_t serviceflags;
const char *strCommand;
const char *nodeaddr;
const char *vRecv;
int vRecvLen;
int64_t nTimeReceived;
};
class MessageHookOut {
public:
int hookversion;
int misbehaving;
const char *logMsg;
const char *pushCommand;
const unsigned char *pushData;
int pushDataLen;
const char *passCommand;
CDataStream passStream;
};
class MessageHook {
public:
int hookversion;
std::string name;
typedef bool (*HandlerType)(const MessageHookIn *in, MessageHookOut
*out);
HandlerType handle;
};
--001a11459da05c8cbb0556a6f782
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I was thinking about something like this that could add th=
e ability for module extensions in the core client. =C2=A0 <br><br>When mes=
sages are received, modules hooks are called with the message data. =C2=A0 =
<br><br>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 t=
heir own private commands prefixed by "x:" or something like that=
. =C2=A0=C2=A0<div><br></div><div>The idea is that the base P2P layer is le=
ft undisturbed, but there is now a way to create "enhanced features&qu=
ot; that some peers support.</div><div><br>My end goal is to support using =
lightning network micropayments to allow people to pay for better node acce=
ss - creating a market for node services. =C2=A0=C2=A0<br><br>But I don'=
;t think this should be "baked in" to core. =C2=A0 Nor do I think=
it should be a "patch". =C2=A0 It should be a linked-in module, =
optionally compiled and added to bitcoin conf, then loaded via dlopen(). =
=C2=A0 =C2=A0Modules should be slightly robust to Bitcoin versions changing=
out from under them, but not if the network layer is changed. =C2=A0 This =
can be ensured by a) keeping a module version number, and b) treating modul=
e responses as if they were just received from the network. =C2=A0 Any modu=
le incompatibility should throw an exception...ensuring broken peers don=
9;t stay online.<br><br>In general I think the core reference would benefit=
from the ability to create subnetworks within the Bitcoin ecosystem. =C2=
=A0 Right now, we have two choices... full node and get slammed with traffi=
c, or listen-only node, and do nothing. =C2=A0<br><br>Adding a module/hook =
system would allow a complex ecosystem of participation - and it would seem=
to be far more robust in the long term.=C2=A0</div><div><br></div><div>Som=
ething like this???<br><br><div>class MessageHookIn {</div><div>public:</di=
v><div>=C2=A0 =C2=A0 int hookversion;</div><div>=C2=A0 =C2=A0 int64_t nodei=
d;</div><div>=C2=A0 =C2=A0 int nVersion;</div><div>=C2=A0 =C2=A0 int64_t se=
rviceflags;</div><div>=C2=A0 =C2=A0 const char *strCommand;</div><div>=C2=
=A0 =C2=A0 const char *nodeaddr;</div><div>=C2=A0 =C2=A0 const char *vRecv;=
</div><div>=C2=A0 =C2=A0 int vRecvLen;</div><div>=C2=A0 =C2=A0 int64_t nTim=
eReceived;</div><div>};</div><div><br></div><div>class MessageHookOut {</di=
v><div>public:</div><div>=C2=A0 =C2=A0 int hookversion;</div><div>=C2=A0 =
=C2=A0 int misbehaving;</div><div>=C2=A0 =C2=A0 const char *logMsg;</div><d=
iv>=C2=A0 =C2=A0 const char *pushCommand;</div><div>=C2=A0 =C2=A0 const uns=
igned char *pushData;</div><div>=C2=A0 =C2=A0 int pushDataLen;</div><div>=
=C2=A0 =C2=A0 const char *passCommand;</div><div>=C2=A0 =C2=A0 CDataStream =
passStream;</div><div>};<br></div><div><br><div>class MessageHook {</div><d=
iv>public:</div><div>=C2=A0 =C2=A0 int hookversion;</div><div>=C2=A0 =C2=A0=
std::string name;</div><div>=C2=A0 =C2=A0 typedef bool (*HandlerType)(cons=
t MessageHookIn *in, MessageHookOut *out);</div><div>=C2=A0 =C2=A0 HandlerT=
ype handle;</div><div>};</div><div><br></div><br></div></div></div>
--001a11459da05c8cbb0556a6f782--
|
