{"type":"rich","version":"1.0","author_name":"Tomas [ARCHIVE] (npub1rs…9evk4)","author_url":"https://nostr.ae/npub1rsp4w56r24w3zv4xy8zfgesep45qmf9rq6aghxfw3wr7yemqnnwsf9evk4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 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"}