📅 Original date posted:2015-09-18
📝 Original message: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 at 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 at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/138066de/attachment.html>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:40:19
in reply to nevent1q…w42a
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:40:19Event JSON
{
"id": "f64c59a7bcf7152310bbbc3007d6164748bed3b5c26f1ea521801c39f38296fa",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686159619,
"kind": 1,
"tags": [
[
"e",
"5693970ede8357f5aa1e378a2f22e843f3a5f1b8b35bba794e5ea1856edc9c5d",
"",
"root"
],
[
"e",
"fc719dd645f5e15e84abab0bf09043490cb516ea42515c0e2ba98a6a000a10c1",
"",
"reply"
],
[
"p",
"5c0b7fca51fd4830b4d9f840de063faebeeabd3bb5dd118de9cdf50a6feaaf98"
]
],
"content": "📅 Original date posted:2015-09-18\n📝 Original message: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?\n\nOn September 17, 2015 5:07:20 PM PDT, \"Wladimir J. van der Laan via bitcoin-dev\" \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003eOn Wed, Sep 16, 2015 at 06:29:28PM -0400, Peter Todd via bitcoin-dev\n\u003ewrote:\n\u003e\n\u003e\u003e I've run into a number of cases where companies were maintaining\n\u003eforks\n\u003e\u003e of Bitcoin Core unnecessarily, where a different, loosely coupled,\n\u003e\u003e architecture could do what they needed to do without including the\n\u003enew\n\u003e\u003e logic in the codebase itself.\n\u003e\n\u003eThis is the same point I have been making to Jeff privately.\n\u003e\n\u003eRefactors are a means to an end: a more modular, reusable and\n\u003emaintainable codebase. This goal is that new functionality can be\n\u003eplugged in more easily, and rebase work for e.g. functionality built on\n\u003etop can go down, not up, if it just hooks into well-defined interfaces\n\u003ehere and there.\n\u003e\n\u003eAlthough there has been a lot of progress, bitcoind's design is still\n\u003etoo monolithic. To add a more involved feature, like say a new index\n\u003eover the block chain data, code needs to be touched all over the place.\n\u003eThis change interacts with all other functionality, potentially\n\u003ebreaking the base node functionality - risk for users that do NOT use\n\u003ethe functionality. This increases risk and review time.\n\u003e\n\u003e- *If possible* functionality should be built without changing\n\u003ebitcoind's code at all. An external process should be able to keep up\n\u003eto date with the chain, notice reorgs, and process block data\n\u003eaccordingly. If bitcoind's interface does not allow that, or it is too\n\u003edifficult, that is what should be fixed. \n\u003e- *if not possible* then a change should at least touch the code in as\n\u003efew places as possible, and integrate with e.g. signal notification.\n\u003e\n\u003eTo name an example of it done right, IMO: Monero's 'simplewallet'. It\n\u003eis a command-line utility wallet that communicates with the node\n\u003esoftware, and remembers where it was in the chain, and processes\n\u003echanges to the chain state since its last invocation when it\n\u003e'refreshes'. \n\u003eWhat is nice is that one can run an arbitary number of simplewallets\n\u003eagainst one node daemon, and unlike bitcoind's wallet it doesn't need\n\u003eto run as always-on daemon itself. It can be invoked when the user\n\u003ewants to do something with the wallet, or see if there are new\n\u003etransactions.\n\u003e\n\u003eAn index could be implemented entirely externally in a similar way,\n\u003ewhile still fully handling reorgs.\n\u003e\n\u003eWhat one needs for that, I think, is a library that communicate with\n\u003ethe node, and which offers functionality abstractly be similar to 'git\n\u003epull': give me the tree path from my current known tip to the best tip,\n\u003eand supply the block hashes (and block data) along the way. \n\u003e\n\u003eMy long-term vision of bitcoind is a P2P node with validation and\n\u003eblockchain store, with a couple of data sources that can be subscribed\n\u003eto or pulled from.\n\u003e\n\u003eWladimir\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-- \nSent from my Android device with K-9 Mail. Please excuse my brevity.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/138066de/attachment.html\u003e",
"sig": "4049778c3e266d08840a2a367317882ec4e2f5b60694b31cfb723ce61479a17fed7271eb1c356078706c1eb40b4569d794f5392c7a924b94f38505e4df1f642c"
}