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 5ECE8BAC for ; Fri, 7 Apr 2017 01:29:09 +0000 (UTC) X-Greylist: from auto-whitelisted 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 D464A18B for ; Fri, 7 Apr 2017 01:29:08 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 29CFD20AB4; Thu, 6 Apr 2017 21:29:08 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute2.internal (MEProxy); Thu, 06 Apr 2017 21:29:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=kkzVXu 1+hgqiyfPg3hJWOH8Mub5+cNvm3eFC6cTp6sQ=; b=EivLNfuheqlojORFxaiyPh ig3xlLmt2AKpeiBy+5IIY2aikUG2YePuz76IhZ1YvQT7dFMA9CzIQ8oAUJmHnbBc XyigR/yAA2kjSaJzrbPmDSifbQsSf+W7RkpQkTl26RlAMJQ1oyL5IorwVl70v6sZ bCOV56UDpsgGXY+sI5q4OHq20MBAcUil9lDhWP0K+GYxnkRStM94PWBgJbx1ugvt hwqc0SPP4C/cceTWMYZtHJoWzzJHbsXpLmweWh9Y+ssGXncr1JOIUg4W6lT7q9zh w33wMqxXkRAsSpB0y/5rHlOskh21J+/4Xc6w0IYCc9A6wi8juW0m+0KVb3BB7alg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0740F9EC32; Thu, 6 Apr 2017 21:29:07 -0400 (EDT) Message-Id: <1491528547.734012.936970328.62366FA5@webmail.messagingengine.com> From: Tomas To: Gregory Maxwell 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 03:29:07 +0200 In-Reply-To: References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com> <1491526132.723002.936945760.06A943C6@webmail.messagingengine.com> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW 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: Fri, 07 Apr 2017 01:30:45 +0000 Cc: Bitcoin Protocol Discussion 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 01:29:09 -0000 On Fri, Apr 7, 2017, at 03:09, Gregory Maxwell wrote: > > How do you deal with validity rules changing based on block height? I expected that one :). Just like the 100 blocks coinbase rule, changes by softforks need to be added as metadata to the transaction-index, but this is not yet in place. As for the script validation itself using libbitcoinconsensus, this is a bit hairy as this expects the rules to be known. Luckily, simply gradually retrying using "lower" rules won't hurt performance, as transaction that mismatch newer rules are rare. Generally, bitcrust would appreciate a "is valid with X rules" instead of a "validate with X rules" approach. > So it sounds like to work the software still needs an analog of a > (U)TXO database? I am confused by the earlier comments about thinking > the the resource consumption of the (U)TXO database is not a > consideration in your design. No, but transactional access is. Bitcrust just uses a *transaction-index*, where outputs can be looked up regardless of being spent. As the concept of being "spent" depends on the branch, script validation ignores this and simply looks up the outputs. Transactions are split in two parts for better locality of reference when accessing outputs. The transaction index only looks similar to an "UTXO-index" after full pruning. > If you get a transaction claiming to spend 0xDEADBEEFDEADBEEF, an > output that never existed how does your spent index reject this spend The spend-tree is scanned until either DEADBEAF is found (=ERR double spent), the transaction of DEADBEEF is found (=all ok!), or the start of the chain is reached (=ERR spending unknown output!) To prevent actually having to scan to genesis, the spent-index "catches" the search after a few blocks and performs the same lookup (positive for tx, negative for output) on a simple bit index.