From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9664C481 for ; Thu, 6 Apr 2017 22:21:00 +0000 (UTC) X-Greylist: delayed 00:08:31 by SQLgrey-1.7.6 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 508C27C for ; Thu, 6 Apr 2017 22:20:59 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6B74220911 for ; Thu, 6 Apr 2017 18:12:27 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute2.internal (MEProxy); Thu, 06 Apr 2017 18:12:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=1YXMw0S6vspMW44oa4nNWlE9NSspC MSl0crx2KgiWD8=; b=KMtbf7vw2ik8oKiG4X4aaatRxzm6DEecSlk/xm5+rrO8a 1kqwCfl1gqhukJHPtNjVGzd6WX6uuOPLlYBQyAPlF3ieIrMZOrabv4IH02iwbifL u+LkOJqX35uziPiepXVVK5hMfios9Jvlc6IN9wOYDulJUpYTqU/VyzRUUDDRN0d8 yTFsBYctSG1jkVoOjTns492618Fmw3tOEo62gklV3uaGBJKHc3KGLzvOLFuvPjrU gMvSH7S09Z2DoQgLCdkIX+PZk7OE2JO4H94MAPv4WNW0IOBeT/LXhnu9DAY+UG3d Ev7Wxr5hx9iAZ04lWtFcXPu3BtWYZeUP4k5eoNLPg== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 463A69EC32; Thu, 6 Apr 2017 18:12:27 -0400 (EDT) Message-Id: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com> From: Tomas To: Bitcoin Dev MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-8e6aa83c Date: Fri, 07 Apr 2017 00:12:27 +0200 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_LOW, URIBL_RHS_DOB autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 06 Apr 2017 22:24:56 +0000 Subject: [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: Thu, 06 Apr 2017 22:21:00 -0000 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