From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C0565C82 for ; 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 ; 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 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: To: Erik Aronesty , Bitcoin Protocol Discussion In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--