Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E6D9641C for ; Fri, 7 Apr 2017 07:55:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from punisher (unknown [92.51.240.61]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7056B8D for ; Fri, 7 Apr 2017 07:55:50 +0000 (UTC) Received: from [127.0.0.1] (helo=mail.fairluck.net) by punisher with esmtp (Exim 4.88) (envelope-from ) id 1cwOkG-00078l-FE; Fri, 07 Apr 2017 07:55:48 +0000 Received: from 213.1.222.238 (SquirrelMail authenticated user marcos) by mail.fairluck.net with HTTP; Fri, 7 Apr 2017 07:55:48 -0000 Message-ID: In-Reply-To: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com> References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com> Date: Fri, 7 Apr 2017 07:55:48 -0000 From: "Marcos mayorga" To: "Tomas" , "Bitcoin Protocol Discussion" Reply-To: mm@mm-studios.com User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: mm@mm-studios.com X-SA-Exim-Scanned: No (on punisher); SAEximRunCond expanded to false X-Spam-Status: No, score=2.3 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1, RCVD_IN_SORBS_HTTP, RCVD_IN_SORBS_SOCKS, RDNS_NONE, URIBL_RHS_DOB autolearn=no version=3.3.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 07 Apr 2017 11:13:34 +0000 Subject: Re: [bitcoin-dev] Using a storage engine without UTXO-index X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 07:55:51 -0000 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@bitcrust.org > Bitcrust > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >