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 --]
next prev parent reply other threads:[~2015-09-18 8:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-15 4:10 [bitcoin-dev] libconsensus and bitcoin development process Jeff Garzik
2015-09-15 9:55 ` Btc Drak
2015-09-15 15:26 ` Jeff Garzik
2015-09-15 16:00 ` Eric Lombrozo
2015-09-15 18:26 ` Btc Drak
2015-09-16 22:29 ` Peter Todd
2015-09-18 0:07 ` Wladimir J. van der Laan
2015-09-18 8:42 ` Eric Lombrozo [this message]
2015-09-18 16:22 ` Mike Hearn
2015-09-22 18:12 ` Jorge Timón
2015-09-22 23:49 ` Dave Scotese
2015-09-23 17:28 ` Jorge Timón
2015-09-29 13:04 ` Jeff Garzik
[not found] ` <CABsx9T0dHxXzemxJN87mU59j4_KZ=zOdwxpXOUe-NhB0ENVMWw@mail.gmail.com>
2015-09-23 16:58 ` Jorge Timón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CADECE8-7A02-4247-99FD-380FFC332BC7@gmail.com \
--to=elombrozo@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=laanwj@gmail.com \
--cc=pete@petertodd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox