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>
Subject: Re: [bitcoin-dev] Would anyone object to adding a dlopen message
 hook system?
Precedence: list


--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--