📅 Original date posted:2017-04-07
📝 Original message:Interesting work.
I was wondering if you could tell us what specs for the machine being used
as preliminary benchmark is here: https://bitcrust.org/results ?
I'd be interested to also see comparisons with 0.14 which has some
improvements for script validation with more cores.
On Fri, Apr 7, 2017 at 4:47 AM, Tomas via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thank you Marcos,
>
> Though written in Rust, bitcrust-db is definitely usable as pluggable
> module as its interface will be roughly some queries, add_tx and
> add_block with blobs and flags. (Bitcrust internally uses a
> deserialize-only model, keeping references to the blobs with the parsed
> data).
>
> However, from Core's side I believe network and storage are currently
> rather tightly coupled, which will make this far from trivial.
>
> Regardless, I am also hoping (with funding & a team) to build a Bitcrust
> networking component as well to bring a strong competitor to the market.
>
> best,
> Tomas
>
>
>
> On Fri, Apr 7, 2017, at 09:55, Marcos mayorga wrote:
> > Hi Tomas,
> >
> > I've read it and think it is an excellent work, I'd like to see it
> > integrated into bitcoin-core as a 'kernel module'.
> >
> > I see there are a lot of proof of concepts out there, IMO every one
> > deserve a room in the bitcoin client as a selectable feature, to make the
> > software more flexible and less dictatorial, an user could easily select
> > which features she wants to run.
> >
> > Best regards,
> > Marcos
> >
> > > I have been working on a bitcoin implementation that uses a different
> > > approach to indexing for verifying the order of transactions. Instead
> of
> > > using an index of unspent outputs, double spends are verified by using
> a
> > > spend-tree where spends are scanned against spent outputs instead of
> > > unspent outputs.
> > >
> > > This allows for much better concurrency, as not only blocks, but also
> > > individual inputs can be verified fully in parallel.
> > >
> > > I explain the approach at https://bitcrust.org, source code is
> available
> > > at https://github.com/tomasvdw/bitcrust
> > >
> > > I am sharing this not only to ask for your feedback, but also to call
> > > for a clear separation of protocol and implementations: As this
> > > solution, reversing the costs of outputs and inputs, seems to have
> > > excellent performance characteristics (as shown in the test results),
> > > updates to the protocol addressing the UTXO growth, might not be worth
> > > considering *protocol improvements* and it might be best to address
> > > these concerns as implementation details.
> > >
> > > Kind regards,
> > > Tomas van der Wansem
> > > tomas at bitcrust.org
> > > Bitcrust
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> >
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/7be2b4cf/attachment.html>;
Greg Sanders [ARCHIVE] /
npub1jd…3gh0m
2023-06-07 17:59:38
in reply to nevent1q…pwug
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-07 17:59:38Event JSON
{
"id": "3de1a5b07172bc2cc7ee900be98c06863eadf92a9166bb2b248fadfc46745a78",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1686160778,
"kind": 1,
"tags": [
[
"e",
"d4a682be1f6603f0ff8798c52b7225cac6554e21f3aedb0c80e7d41cf71983ad",
"",
"root"
],
[
"e",
"b66df57f9838496c1e99f19c911bec889a6ce66b8e5f0a2886756d179d88b4ca",
"",
"reply"
],
[
"p",
"1c03575343555d1132a621c49466190d680da4a306ba8b992e8b87e267609cdd"
]
],
"content": "📅 Original date posted:2017-04-07\n📝 Original message:Interesting work.\n\nI was wondering if you could tell us what specs for the machine being used\nas preliminary benchmark is here: https://bitcrust.org/results ?\n\nI'd be interested to also see comparisons with 0.14 which has some\nimprovements for script validation with more cores.\n\nOn Fri, Apr 7, 2017 at 4:47 AM, Tomas via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Thank you Marcos,\n\u003e\n\u003e Though written in Rust, bitcrust-db is definitely usable as pluggable\n\u003e module as its interface will be roughly some queries, add_tx and\n\u003e add_block with blobs and flags. (Bitcrust internally uses a\n\u003e deserialize-only model, keeping references to the blobs with the parsed\n\u003e data).\n\u003e\n\u003e However, from Core's side I believe network and storage are currently\n\u003e rather tightly coupled, which will make this far from trivial.\n\u003e\n\u003e Regardless, I am also hoping (with funding \u0026 a team) to build a Bitcrust\n\u003e networking component as well to bring a strong competitor to the market.\n\u003e\n\u003e best,\n\u003e Tomas\n\u003e\n\u003e\n\u003e\n\u003e On Fri, Apr 7, 2017, at 09:55, Marcos mayorga wrote:\n\u003e \u003e Hi Tomas,\n\u003e \u003e\n\u003e \u003e I've read it and think it is an excellent work, I'd like to see it\n\u003e \u003e integrated into bitcoin-core as a 'kernel module'.\n\u003e \u003e\n\u003e \u003e I see there are a lot of proof of concepts out there, IMO every one\n\u003e \u003e deserve a room in the bitcoin client as a selectable feature, to make the\n\u003e \u003e software more flexible and less dictatorial, an user could easily select\n\u003e \u003e which features she wants to run.\n\u003e \u003e\n\u003e \u003e Best regards,\n\u003e \u003e Marcos\n\u003e \u003e\n\u003e \u003e \u003e I have been working on a bitcoin implementation that uses a different\n\u003e \u003e \u003e approach to indexing for verifying the order of transactions. Instead\n\u003e of\n\u003e \u003e \u003e using an index of unspent outputs, double spends are verified by using\n\u003e a\n\u003e \u003e \u003e spend-tree where spends are scanned against spent outputs instead of\n\u003e \u003e \u003e unspent outputs.\n\u003e \u003e \u003e\n\u003e \u003e \u003e This allows for much better concurrency, as not only blocks, but also\n\u003e \u003e \u003e individual inputs can be verified fully in parallel.\n\u003e \u003e \u003e\n\u003e \u003e \u003e I explain the approach at https://bitcrust.org, source code is\n\u003e available\n\u003e \u003e \u003e at https://github.com/tomasvdw/bitcrust\n\u003e \u003e \u003e\n\u003e \u003e \u003e I am sharing this not only to ask for your feedback, but also to call\n\u003e \u003e \u003e for a clear separation of protocol and implementations: As this\n\u003e \u003e \u003e solution, reversing the costs of outputs and inputs, seems to have\n\u003e \u003e \u003e excellent performance characteristics (as shown in the test results),\n\u003e \u003e \u003e updates to the protocol addressing the UTXO growth, might not be worth\n\u003e \u003e \u003e considering *protocol improvements* and it might be best to address\n\u003e \u003e \u003e these concerns as implementation details.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Kind regards,\n\u003e \u003e \u003e Tomas van der Wansem\n\u003e \u003e \u003e tomas at bitcrust.org\n\u003e \u003e \u003e Bitcrust\n\u003e \u003e \u003e _______________________________________________\n\u003e \u003e \u003e bitcoin-dev mailing list\n\u003e \u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/7be2b4cf/attachment.html\u003e",
"sig": "1d46eac5d5d260b8454c7dbce429fc9e8c7aec3f2999718592146d80e9388c350ee7c43a419c4ab29c1b68c25465fca740ceb56c9a37eab02667e45ed23ee6a7"
}