Re: [bitcoin-dev] libconsensus and bitcoin development process

From: Eric Lombrozo <elombrozo@gmail•com>
To: "Wladimir J. van der Laan" <laanwj@gmail•com>,
	"Wladimir J. van der Laan via bitcoin-dev"
	<bitcoin-dev@lists•linuxfoundation.org>,
	Peter Todd <pete@petertodd•org>
Cc: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] libconsensus and bitcoin development process
Date: Fri, 18 Sep 2015 01:42:53 -0700	[thread overview]
Message-ID: <3CADECE8-7A02-4247-99FD-380FFC332BC7@gmail.com> (raw)
In-Reply-To: <20150918000718.GA5251@amethyst.visucore.com>

[-- Attachment #1: Type: text/plain, Size: 3270 bytes --]

You're aware that my entire stack was built around this model and I've even built a fully fledged desktop GUI, multisig account manager, and servers supporting pull and event subscription atop it, right?

On September 17, 2015 5:07:20 PM PDT, "Wladimir J. van der Laan via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation.org> wrote:
>On Wed, Sep 16, 2015 at 06:29:28PM -0400, Peter Todd via bitcoin-dev
>wrote:
>
>> I've run into a number of cases where companies were maintaining
>forks
>> of Bitcoin Core unnecessarily, where a different, loosely coupled,
>> architecture could do what they needed to do without including the
>new
>> logic in the codebase itself.
>
>This is the same point I have been making to Jeff privately.
>
>Refactors are a means to an end: a more modular, reusable and
>maintainable codebase. This goal is that new functionality can be
>plugged in more easily, and rebase work for e.g. functionality built on
>top can go down, not up, if it just hooks into well-defined interfaces
>here and there.
>
>Although there has been a lot of progress, bitcoind's design is still
>too monolithic. To add a more involved feature, like say a new index
>over the block chain data, code needs to be touched all over the place.
>This change interacts with all other functionality, potentially
>breaking the base node functionality - risk for users that do NOT use
>the functionality. This increases risk and review time.
>
>- *If possible* functionality should be built without changing
>bitcoind's code at all. An external process should be able to keep up
>to date with the chain, notice reorgs, and process block data
>accordingly. If bitcoind's interface does not allow that, or it is too
>difficult, that is what should be fixed. 
>- *if not possible* then a change should at least touch the code in as
>few places as possible, and integrate with e.g. signal notification.
>
>To name an example of it done right, IMO: Monero's 'simplewallet'. It
>is a command-line utility wallet that communicates with the node
>software, and remembers where it was in the chain, and processes
>changes to the chain state since its last invocation when it
>'refreshes'. 
>What is nice is that one can run an arbitary number of simplewallets
>against one node daemon, and unlike bitcoind's wallet it doesn't need
>to run as always-on daemon itself. It can be invoked when the user
>wants to do something with the wallet, or see if there are new
>transactions.
>
>An index could be implemented entirely externally in a similar way,
>while still fully handling reorgs.
>
>What one needs for that, I think, is a library that communicate with
>the node, and which offers functionality abstractly be similar to 'git
>pull': give me the tree path from my current known tip to the best tip,
>and supply the block hashes (and block data) along the way. 
>
>My long-term vision of bitcoind is a P2P node with validation and
>blockchain store, with a couple of data sources that can be subscribed
>to or pulled from.
>
>Wladimir
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists•linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 3802 bytes --]