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
|
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C0565C82
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Aug 2017 20:00:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from bitcoin.jonasschnelli.ch (bitcoinsrv.jonasschnelli.ch
[138.201.55.219])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 68F1DCA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Aug 2017 20:00:45 +0000 (UTC)
Received: from [192.168.0.10] (cable-static-238-67.teleport.ch
[213.188.238.67])
by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id 42EFE15E329C;
Sun, 13 Aug 2017 22:00:44 +0200 (CEST)
From: Jonas Schnelli <dev@jonasschnelli.ch>
Content-Type: multipart/signed;
boundary="Apple-Mail=_E368462E-2D2C-4E6B-BEFD-AA6DEF0DC691";
protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 13 Aug 2017 22:00:41 +0200
References: <CAJowKgLXhS2SxwuJnfbHzKSzw+aZie5aO2EsC9qbwWJXMNDuRw@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAJowKgLXhS2SxwuJnfbHzKSzw+aZie5aO2EsC9qbwWJXMNDuRw@mail.gmail.com>
Message-Id: <45BBAF76-CDB7-4D57-920C-70887CABFF48@jonasschnelli.ch>
X-Mailer: Apple Mail (2.3273)
X-Virus-Scanned: clamav-milter 0.99.2 at bitcoinsrv.jonasschnelli.ch
X-Virus-Status: Clean
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:00:45 -0000
--Apple-Mail=_E368462E-2D2C-4E6B-BEFD-AA6DEF0DC691
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
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.
>=20
> When messages are received, modules hooks are called with the message =
data.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
--Apple-Mail=_E368462E-2D2C-4E6B-BEFD-AA6DEF0DC691
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAlmQr+kACgkQHrd2uwPH
ki1HEw/+KHI09hUCXGlYSwqa7HZdQumZEBGXwsiDmzd7s3tzOaskjrsPT1p+NouQ
x6E4/kCJNog9/k+N49Me8O7lFM9GDy1OIi5F6E0py098Qf8Zvr+ljQXQCdMv5yOy
K8PGY/P3hu97J509gGxmtoid4SsieHPeJxrJRQocHXXiAGmZGmB3JW/AdTxAhH+i
41oD4xS4hiWjMzRoEdN6TPnzXtz2j81FpuG9raIN6C1k2iGOB+PcvIj9uc5ZmY21
wxogmb7fbkciWV3YL6SgrDoL1njgQLjSxdW8eXyZ+kAVsnUhpUv/D7ykEcnOY2nX
B1ENEW0wZQ4N6eMqS/11t0Qt/jnkUQ+EAas0Oioa//3ZgY9jEjoucsn9RoS9qxr7
3Q//P6hsLWkU5Tdh4uV8qzROp/URYLw+/JWUbBbVBji5z1oUcx+5pS1mgTli97kD
9au79PhbpRlbqfUhbZx6zqRGsZdZAvz+hXwOnaHnl3G4MwZib9M57HGFmETL670L
61zKW6dX4BZZ1wMlVS4iMZErE5Tw/vqCl6N5vX2xsW8omodx7sWpSkNJ+t6BaSG1
XzfTUp9Hf1gi/Ehq8/uXPmWgocFPOkk6dp0a4eYCOopk0ZNXPrxQR2/jVvMGV7CE
q4lAFVV+xv1d7/Lr0c5fNjv4JbguPoV6DtER1430EYDW5QiE9yY=
=72Gn
-----END PGP SIGNATURE-----
--Apple-Mail=_E368462E-2D2C-4E6B-BEFD-AA6DEF0DC691--
|
