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 A141116B9 for ; Wed, 23 Sep 2015 00:10:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2F3DA1DE for ; Wed, 23 Sep 2015 00:10:53 +0000 (UTC) Received: by pacex6 with SMTP id ex6so23239357pac.0 for ; Tue, 22 Sep 2015 17:10:53 -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=2m/t/rsjmCROOJs8UpgxfQEEdoJjE4ZkTcIXyFTn+Bw=; b=NkjsqBNNLj3/3oi1geuC+pUyUWk+kmGa8KF7NZM/wsJeq5NreMA62pj5RzLc1p8Npp 1Bh4gEO8HDBLyj68IVg2Leb/18BB3HuKWOVWSpRHk4dKwE+BwosXgdCk7VyvM+gLyuae h75uU6+GfQr3+Bx37eVYRiz8GTbQe8UIvsR07jllcIFd8VBa5doHYNuCnGXfJne0b1tT mTVELUlolG/yqfkwoMuxyaGBDO9zp9NIgh51U1nyxDHgPzRRsvPTpVYgjhskFqlPrV2+ JBBjn3/vA8COqNi0V2OFz8fjmLaL+cooae8RqyXYQPwd2jRCLVM9hdLWwd6TenVKqOvG FuUg== X-Received: by 10.66.142.101 with SMTP id rv5mr33595447pab.25.1442967052952; Tue, 22 Sep 2015 17:10:52 -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 xi1sm4332448pac.48.2015.09.22.17.10.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Sep 2015 17:10:52 -0700 (PDT) From: "Eric Lombrozo" To: =?utf-8?q?Jorge=20Tim=c3=b3n?= , "Wladimir J. van der Laan" Date: Wed, 23 Sep 2015 00:10:50 +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:10:54 -0000 I should also add that the mempool should exist in (2). This way the=20 peer services layer can manage all relay policy and mempool management. ------ Original Message ------ From: "Eric Lombrozo" To: "Jorge Tim=C3=B3n" ; "Wladimir J. van der Laan"=20 Cc: "Bitcoin development mailing list"=20 Sent: 9/22/2015 5:07:22 PM Subject: Re: [bitcoin-dev] Long-term vision for bitcoind (was=20 libconsensus and bitcoin development process) >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=20 >>>subscribed 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