📅 Original date posted:2017-04-07
📝 Original message:Thank you,
The benches are running in Google Cloud Engine; currently on 8 vCPU
32gb, but I tend to switch hardware regularly.
Roughly, the results are better for Bitcrust with high end hardware and
the difference for total block validations is mostly diminished at 2
vCPU, 7,5 gb.
Note that the spend-tree optimization primarily aims to improve peak
load order validation; when a block with pre-synced transactions comes
in, but this is tricky to accurately bench with Core using this simple
method of comparison by logs.
I will upgrade to, and show the results against 0.14 in the next weeks.
Best,
Tomas
On Fri, Apr 7, 2017, at 16:14, Greg Sanders wrote:
> Interesting work.
>
> I was wondering if you could tellank 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/68d9cba6/attachment.html>;
Tomas [ARCHIVE] /
npub1rs…9evk4
2023-06-07 17:59:38
in reply to nevent1q…28x5
Author Public Key
npub1rsp4w56r24w3zv4xy8zfgesep45qmf9rq6aghxfw3wr7yemqnnwsf9evk4Published at
2023-06-07 17:59:38Event JSON
{
"id": "af45bb9d58637526c15efb955a0f68840a53238552c446ed84561198dc3f9bd2",
"pubkey": "1c03575343555d1132a621c49466190d680da4a306ba8b992e8b87e267609cdd",
"created_at": 1686160778,
"kind": 1,
"tags": [
[
"e",
"d4a682be1f6603f0ff8798c52b7225cac6554e21f3aedb0c80e7d41cf71983ad",
"",
"root"
],
[
"e",
"3de1a5b07172bc2cc7ee900be98c06863eadf92a9166bb2b248fadfc46745a78",
"",
"reply"
],
[
"p",
"937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19"
]
],
"content": "📅 Original date posted:2017-04-07\n📝 Original message:Thank you,\n\n\n\nThe benches are running in Google Cloud Engine; currently on 8 vCPU\n32gb, but I tend to switch hardware regularly.\n\n\nRoughly, the results are better for Bitcrust with high end hardware and\nthe difference for total block validations is mostly diminished at 2\nvCPU, 7,5 gb.\n\n\nNote that the spend-tree optimization primarily aims to improve peak\nload order validation; when a block with pre-synced transactions comes\nin, but this is tricky to accurately bench with Core using this simple\nmethod of comparison by logs.\n\n\nI will upgrade to, and show the results against 0.14 in the next weeks.\n\n\nBest,\n\nTomas\n\n\n\n\n\nOn Fri, Apr 7, 2017, at 16:14, Greg Sanders wrote:\n\n\u003e Interesting work.\n\n\u003e \n\n\u003e I was wondering if you could tellank us what specs for the machine\n\u003e being used as preliminary benchmark is here:\n\u003e https://bitcrust.org/results ?\n\u003e \n\n\u003e I'd be interested to also see comparisons with 0.14 which has some\n\u003e improvements for script validation with more cores.\n\u003e \n\n\u003e On Fri, Apr 7, 2017 at 4:47 AM, Tomas via bitcoin-dev \u003cbitcoin-\n\u003e dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e Thank you Marcos,\n\n\u003e\u003e \n\n\u003e\u003e Though written in Rust, bitcrust-db is definitely usable as\n\u003e\u003e pluggable\n\u003e\u003e module as its interface will be roughly some queries, add_tx and\n\n\u003e\u003e add_block with blobs and flags. (Bitcrust internally uses a\n\n\u003e\u003e deserialize-only model, keeping references to the blobs with the\n\u003e\u003e parsed\n\u003e\u003e data).\n\n\u003e\u003e \n\n\u003e\u003e However, from Core's side I believe network and storage are\n\u003e\u003e currently\n\u003e\u003e rather tightly coupled, which will make this far from trivial.\n\n\u003e\u003e \n\n\u003e\u003e Regardless, I am also hoping (with funding \u0026 a team) to build a\n\u003e\u003e Bitcrust\n\u003e\u003e networking component as well to bring a strong competitor to the\n\u003e\u003e market.\n\u003e\u003e \n\n\u003e\u003e best,\n\n\u003e\u003e Tomas\n\n\u003e\u003e \n\n\u003e\u003e \n\n\u003e\u003e \n\n\u003e\u003e \n\n\u003e\u003e On Fri, Apr 7, 2017, at 09:55, Marcos mayorga wrote:\n\n\u003e\u003e \u003e Hi Tomas,\n\n\u003e\u003e \u003e\n\n\u003e\u003e \u003e I've read it and think it is an excellent work, I'd like to see it\n\u003e\u003e \u003e integrated into bitcoin-core as a 'kernel module'.\n\n\u003e\u003e \u003e\n\n\u003e\u003e \u003e I see there are a lot of proof of concepts out there, IMO\n\u003e\u003e \u003e every one\n\u003e\u003e \u003e deserve a room in the bitcoin client as a selectable feature, to\n\u003e\u003e \u003e make the\n\u003e\u003e \u003e software more flexible and less dictatorial, an user could easily\n\u003e\u003e \u003e select\n\u003e\u003e \u003e which features she wants to run.\n\n\u003e\u003e \u003e\n\n\u003e\u003e \u003e Best regards,\n\n\u003e\u003e \u003e Marcos\n\n\u003e\u003e \u003e\n\n\u003e\u003e \u003e \u003e I have been working on a bitcoin implementation that uses a\n\u003e\u003e \u003e \u003e different\n\u003e\u003e \u003e \u003e approach to indexing for verifying the order of transactions.\n\u003e\u003e \u003e \u003e Instead of\n\u003e\u003e \u003e \u003e using an index of unspent outputs, double spends are verified by\n\u003e\u003e \u003e \u003e using a\n\u003e\u003e \u003e \u003e spend-tree where spends are scanned against spent outputs\n\u003e\u003e \u003e \u003e instead of\n\u003e\u003e \u003e \u003e unspent outputs.\n\n\u003e\u003e \u003e \u003e\n\n\u003e\u003e \u003e \u003e This allows for much better concurrency, as not only blocks, but\n\u003e\u003e \u003e \u003e also\n\u003e\u003e \u003e \u003e individual inputs can be verified fully in parallel.\n\n\u003e\u003e \u003e \u003e\n\n\u003e\u003e \u003e \u003e I explain the approach at https://bitcrust.org, source code is\n\u003e\u003e \u003e \u003e available\n\u003e\u003e \u003e \u003e at https://github.com/tomasvdw/bitcrust\n\n\u003e\u003e \u003e \u003e\n\n\u003e\u003e \u003e \u003e I am sharing this not only to ask for your feedback, but also to\n\u003e\u003e \u003e \u003e call\n\u003e\u003e \u003e \u003e for a clear separation of protocol and implementations: As this\n\u003e\u003e \u003e \u003e solution, reversing the costs of outputs and inputs, seems to\n\u003e\u003e \u003e \u003e have\n\u003e\u003e \u003e \u003e excellent performance characteristics (as shown in the test\n\u003e\u003e \u003e \u003e results),\n\u003e\u003e \u003e \u003e updates to the protocol addressing the UTXO growth, might not be\n\u003e\u003e \u003e \u003e worth\n\u003e\u003e \u003e \u003e considering *protocol improvements* and it might be best to\n\u003e\u003e \u003e \u003e address\n\u003e\u003e \u003e \u003e these concerns as implementation details.\n\n\u003e\u003e \u003e \u003e\n\n\u003e\u003e \u003e \u003e Kind regards,\n\n\u003e\u003e \u003e \u003e Tomas van der Wansem\n\n\u003e\u003e \u003e \u003e tomas at bitcrust.org\n\n\u003e\u003e \u003e \u003e Bitcrust\n\n\u003e\u003e \u003e \u003e _______________________________________________\n\n\u003e\u003e \u003e \u003e bitcoin-dev mailing list\n\n\u003e\u003e \u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\n\u003e\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n\u003e\u003e \u003e \u003e\n\n\u003e\u003e \u003e\n\n\u003e\u003e \u003e\n\n\u003e\u003e _______________________________________________\n\n\u003e\u003e bitcoin-dev mailing list\n\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/68d9cba6/attachment.html\u003e",
"sig": "ab0a01043d0403c764b3c230315aec53210b54724b5a584c0b3cfcafac93b3e4e44d80bdfa3a44c27a12b8a4e3369bc023f67438c4eb826009407d739b84fee3"
}