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 54946121A for ; Wed, 23 Sep 2015 00:07:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D99F71CC for ; Wed, 23 Sep 2015 00:07:24 +0000 (UTC) Received: by pacbt3 with SMTP id bt3so4835098pac.3 for ; Tue, 22 Sep 2015 17:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version:content-type:content-transfer-encoding; bh=dncAtn0PsDDcR5MFdLSPV6wecCAwZ9OfZ5ulKnXIKus=; b=cCcfPx+YY7MqNYUMtVy7L1ESbOvTiOyCs9MDJU9GUU3o07xc5dzRKE2Xqa2zX1xQVm IqKQQaoRcWNIqb5d08H50sfxUVTO0PIHZrwSoQgAxyShFqLiFWQXtlz/iVdZ+M00Xipp nk90HWCYAM7JSvCVlaimt//YbXjMIb3gEzg2PkFIyg88EG+bm2XJreHdcXZ5gBNGY7Nk JjXzIo12yy6TsgC/F8N6Aipc1VXzjc04BecX/X1YP2Xp19+Fe+nA6oK1X3MLYH28Vi68 bCpWVjYQq3bdwe4ODTA12D2Gh5HqpvGnvPJc+JYzufLzKAqoNMH0Xdxy15PaJON/NjgX eicg== X-Received: by 10.66.144.40 with SMTP id sj8mr34124953pab.72.1442966844610; Tue, 22 Sep 2015 17:07:24 -0700 (PDT) Received: from [192.168.1.108] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id d13sm4402535pbu.17.2015.09.22.17.07.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Sep 2015 17:07:24 -0700 (PDT) From: "Eric Lombrozo" To: =?utf-8?q?Jorge=20Tim=c3=b3n?= , "Wladimir J. van der Laan" Date: Wed, 23 Sep 2015 00:07:22 +0000 Message-Id: In-Reply-To: Reply-To: "Eric Lombrozo" User-Agent: eM_Client/6.0.23181.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] Long-term vision for bitcoind (was libconsensus and bitcoin development process) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 00:07:25 -0000 Here's what I propose as a long-term plan: 1) libconsensus =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We should probably start by defining an API for libconsensus. It should=20 support an abstract DB model, track chain state, provide query=20 mechanisms for blocks and transactions with optional pruning and=20 indexing, expose a subscription mechanism for events such as NEW_TIP,=20 REORG, etc, and contain a script interpreter. We can develop the library in parallel with Bitcoin Core without too=20 much refactoring of Bitcoin Core itself...just moving pieces of Bitcoin=20 Core's consensus code into the new library, tracking code movements to=20 make merging easier. Yes, this is a bit ugly as it requires code=20 duplication...but it will temporarily avoid much of the downstream=20 pushback we're getting. The idea is that we can prove out the library=20 with some simple projects, then start removing the consensus stuff from=20 Bitcoin Core once we have greater acceptance of the library and better=20 documentation. 2) peer services =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We develop a peer services library that performs the tasks of peer=20 discovery and relay, with the ability to connect to appropriate peers=20 and queue messages. It uses libconsensus for all validation=20 functionality and as a datastore for the consensus state but maintains=20 its own database for peer history and statistics. I believe Cory has=20 been working on this already using libevent. I've already developed an=20 async library for this as well. 3) API/RPC =3D=3D=3D=3D=3D=3D=3D We provide high level calls and pub/sub mechanisms. ZMQ has been=20 implemented and added already, but we could support other transports as=20 well. 4) Wallet =3D=3D=3D=3D=3D=3D The wallet is split out into a separate process that connects to the=20 stack via the API/RPC layer. - Eric ------ Original Message ------ From: "Jorge Tim=C3=B3n" To: "Wladimir J. van der Laan" Cc: "Bitcoin development mailing list"=20 Sent: 9/22/2015 11:36:14 AM Subject: [bitcoin-dev] Long-term vision for bitcoind (was libconsensus=20 and bitcoin development process) >On Fri, Sep 18, 2015 at 2:07 AM, Wladimir J. van der Laan via >bitcoin-dev wrote: >> My long-term vision of bitcoind is a P2P node with validation and=20 >>blockchain store, with a couple of data sources that can be subscribed= =20 >>to or pulled from. > >I agree with this long term vision. >Here's how I think it could happen: > >1) Libconsensus is completed and moved to a subtree (which has libsecp >as an internal subtree) > >2) Bitcoind becomes a subtree of bitcoin-wallet (which has >bitcoin-wallet and bitcoin-qt) > >Without aggressively changing it for this purpose, libconsensus should >tend to become C, like libsecp, which is better for proving >correctness. >Hopefully at some point it won't take much to move to C. > >Upper layers should move to C++11 > >Don't focus on the git subtrees, the basic architecture is bitcoin-qt >on top of bitcoin-wallet, bitcoin-wallet on top of bitcoind (and >friends like bitcoin-cli and bitcoin-tx), bitcoind on top of >libconsensus on top of libsecp256k1. > >I believe this would maximize the number of people who can safely >contribute to the project. >I also believe this is the architecture most contributors have in mind >for the long term, but I may be wrong about it. > >Criticisms to this plan? >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev