{"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 Marcos,\n\nThough written in Rust, bitcrust-db is definitely usable as pluggable\nmodule as its interface will be roughly some queries, add_tx and\nadd_block with blobs and flags. (Bitcrust internally uses a\ndeserialize-only model, keeping references to the blobs with the parsed\ndata).  \n\nHowever, from Core's side I believe network and storage are currently\nrather tightly coupled, which will make this far from trivial.\n\nRegardless, I am also hoping (with funding \u0026 a team) to build a Bitcrust\nnetworking component as well to bring a strong competitor to the market.\n\nbest,\nTomas\n\n\n\nOn Fri, Apr 7, 2017, at 09:55, Marcos mayorga wrote:\n\u003e Hi Tomas,\n\u003e \n\u003e I've read it and think it is an excellent work, I'd like to see it\n\u003e integrated into bitcoin-core as a 'kernel module'.\n\u003e \n\u003e I see there are a lot of proof of concepts out there, IMO every one\n\u003e deserve a room in the bitcoin client as a selectable feature, to make the\n\u003e software more flexible and less dictatorial, an user could easily select\n\u003e which features she wants to run.\n\u003e \n\u003e Best regards,\n\u003e Marcos\n\u003e \n\u003e \u003e I have been working on a bitcoin implementation that uses a different\n\u003e \u003e approach to indexing for verifying the order of transactions. Instead of\n\u003e \u003e using an index of unspent outputs, double spends are verified by using a\n\u003e \u003e spend-tree where spends are scanned against spent outputs instead of\n\u003e \u003e unspent outputs.\n\u003e \u003e\n\u003e \u003e This allows for much better concurrency, as not only blocks, but also\n\u003e \u003e individual inputs can be verified fully in parallel.\n\u003e \u003e\n\u003e \u003e I explain the approach at https://bitcrust.org, source code is available\n\u003e \u003e at https://github.com/tomasvdw/bitcrust\n\u003e \u003e\n\u003e \u003e I am sharing this not only to ask for your feedback, but also to call\n\u003e \u003e for a clear separation of protocol and implementations: As this\n\u003e \u003e solution, reversing the costs of outputs and inputs, seems to have\n\u003e \u003e excellent performance characteristics (as shown in the test results),\n\u003e \u003e updates to the protocol addressing the UTXO growth, might not be worth\n\u003e \u003e considering *protocol improvements* and it might be best to address\n\u003e \u003e these concerns as implementation details.\n\u003e \u003e\n\u003e \u003e Kind regards,\n\u003e \u003e Tomas van der Wansem\n\u003e \u003e tomas at bitcrust.org\n\u003e \u003e Bitcrust\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\n\u003e \n\u003e"}