rich1.0npub1u3hslvx87efh4ee4n8w32ytmx9c0jq7mt9ykjpk35nqcglyte4dsa3p337https://nostr.ae/npub1u3hslvx87efh4ee4n8w32ytmx9c0jq7mt9ykjpk35nqcglyte4dsa3p337njumphttps://nostr.ae📅 Original date posted:2017-04-07 📝 Original message: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 >