📅 Original date posted:2015-09-22
📝 Original message:Here's what I propose as a long-term plan:
1) libconsensus
==========
We should probably start by defining an API for libconsensus. It should
support an abstract DB model, track chain state, provide query
mechanisms for blocks and transactions with optional pruning and
indexing, expose a subscription mechanism for events such as NEW_TIP,
REORG, etc, and contain a script interpreter.
We can develop the library in parallel with Bitcoin Core without too
much refactoring of Bitcoin Core itself...just moving pieces of Bitcoin
Core's consensus code into the new library, tracking code movements to
make merging easier. Yes, this is a bit ugly as it requires code
duplication...but it will temporarily avoid much of the downstream
pushback we're getting. The idea is that we can prove out the library
with some simple projects, then start removing the consensus stuff from
Bitcoin Core once we have greater acceptance of the library and better
documentation.
2) peer services
==========
We develop a peer services library that performs the tasks of peer
discovery and relay, with the ability to connect to appropriate peers
and queue messages. It uses libconsensus for all validation
functionality and as a datastore for the consensus state but maintains
its own database for peer history and statistics. I believe Cory has
been working on this already using libevent. I've already developed an
async library for this as well.
3) API/RPC
=======
We provide high level calls and pub/sub mechanisms. ZMQ has been
implemented and added already, but we could support other transports as
well.
4) Wallet
======
The wallet is split out into a separate process that connects to the
stack via the API/RPC layer.
- Eric
------ Original Message ------
From: "Jorge Timón" <bitcoin-dev at lists.linuxfoundation.org>
To: "Wladimir J. van der Laan" <laanwj at gmail.com>
Cc: "Bitcoin development mailing list"
<bitcoin-dev at lists.linuxfoundation.org>
Sent: 9/22/2015 11:36:14 AM
Subject: [bitcoin-dev] Long-term vision for bitcoind (was libconsensus
and bitcoin development process)
>On Fri, Sep 18, 2015 at 2:07 AM, Wladimir J. van der Laan via
>bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> 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.
>
>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 at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:41:04
in reply to nevent1q…y5yx
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:41:04Event JSON
{
"id": "c769dd1a3c8ba9026930c9f27254001ae12ac36d6202a2e635ace14a9aafb4f7",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686159664,
"kind": 1,
"tags": [
[
"e",
"06584fedf60bc7015c2e887f3ff56bb10e3ef162cbdc9c96bca7ab3007479c6f",
"",
"root"
],
[
"e",
"e51ec1495ec7086851ad5a7b4ba1a7da65068097310a36499b6824663d04ff92",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-09-22\n📝 Original message:Here's what I propose as a long-term plan:\n\n1) libconsensus\n==========\nWe should probably start by defining an API for libconsensus. It should \nsupport an abstract DB model, track chain state, provide query \nmechanisms for blocks and transactions with optional pruning and \nindexing, expose a subscription mechanism for events such as NEW_TIP, \nREORG, etc, and contain a script interpreter.\n\nWe can develop the library in parallel with Bitcoin Core without too \nmuch refactoring of Bitcoin Core itself...just moving pieces of Bitcoin \nCore's consensus code into the new library, tracking code movements to \nmake merging easier. Yes, this is a bit ugly as it requires code \nduplication...but it will temporarily avoid much of the downstream \npushback we're getting. The idea is that we can prove out the library \nwith some simple projects, then start removing the consensus stuff from \nBitcoin Core once we have greater acceptance of the library and better \ndocumentation.\n\n\n2) peer services\n==========\nWe develop a peer services library that performs the tasks of peer \ndiscovery and relay, with the ability to connect to appropriate peers \nand queue messages. It uses libconsensus for all validation \nfunctionality and as a datastore for the consensus state but maintains \nits own database for peer history and statistics. I believe Cory has \nbeen working on this already using libevent. I've already developed an \nasync library for this as well.\n\n\n3) API/RPC\n=======\nWe provide high level calls and pub/sub mechanisms. ZMQ has been \nimplemented and added already, but we could support other transports as \nwell.\n\n\n4) Wallet\n======\nThe wallet is split out into a separate process that connects to the \nstack via the API/RPC layer.\n\n\n- Eric\n\n------ Original Message ------\nFrom: \"Jorge Timón\" \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nTo: \"Wladimir J. van der Laan\" \u003claanwj at gmail.com\u003e\nCc: \"Bitcoin development mailing list\" \n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nSent: 9/22/2015 11:36:14 AM\nSubject: [bitcoin-dev] Long-term vision for bitcoind (was libconsensus \nand bitcoin development process)\n\n\u003eOn Fri, Sep 18, 2015 at 2:07 AM, Wladimir J. van der Laan via\n\u003ebitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e My long-term vision of bitcoind is a P2P node with validation and \n\u003e\u003eblockchain store, with a couple of data sources that can be subscribed \n\u003e\u003eto or pulled from.\n\u003e\n\u003eI agree with this long term vision.\n\u003eHere's how I think it could happen:\n\u003e\n\u003e1) Libconsensus is completed and moved to a subtree (which has libsecp\n\u003eas an internal subtree)\n\u003e\n\u003e2) Bitcoind becomes a subtree of bitcoin-wallet (which has\n\u003ebitcoin-wallet and bitcoin-qt)\n\u003e\n\u003eWithout aggressively changing it for this purpose, libconsensus should\n\u003etend to become C, like libsecp, which is better for proving\n\u003ecorrectness.\n\u003eHopefully at some point it won't take much to move to C.\n\u003e\n\u003eUpper layers should move to C++11\n\u003e\n\u003eDon't focus on the git subtrees, the basic architecture is bitcoin-qt\n\u003eon top of bitcoin-wallet, bitcoin-wallet on top of bitcoind (and\n\u003efriends like bitcoin-cli and bitcoin-tx), bitcoind on top of\n\u003elibconsensus on top of libsecp256k1.\n\u003e\n\u003eI believe this would maximize the number of people who can safely\n\u003econtribute to the project.\n\u003eI also believe this is the architecture most contributors have in mind\n\u003efor the long term, but I may be wrong about it.\n\u003e\n\u003eCriticisms to this plan?\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "49b438ba1c3e0fe13f128b55ab6af6deb9fe0be2092b1e235d559b8442b5709a79f5d366907f084b32d404e4cc04da8b1e3c09bc167a57f34f8c505edceaf396"
}