diff options
| author | Tomas <tomas@tomasvdw.nl> | 2017-04-07 03:29:07 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-04-07 01:29:09 +0000 |
| commit | e73adc93c46d0261f88913ef7ab826898ffedfa2 (patch) | |
| tree | 0e0cc41cec8337193b78b5d494c8ae138d20f6dc | |
| parent | 39b7fca4b536517e7b30c17dcc92747d7c57bba9 (diff) | |
| download | pi-bitcoindev-e73adc93c46d0261f88913ef7ab826898ffedfa2.tar.gz pi-bitcoindev-e73adc93c46d0261f88913ef7ab826898ffedfa2.zip | |
Re: [bitcoin-dev] Using a storage engine without UTXO-index
| -rw-r--r-- | bd/cfb54fafceafd398ef83cf60c41cd4d05dcb80 | 112 |
1 files changed, 112 insertions, 0 deletions
diff --git a/bd/cfb54fafceafd398ef83cf60c41cd4d05dcb80 b/bd/cfb54fafceafd398ef83cf60c41cd4d05dcb80 new file mode 100644 index 000000000..f28ae1982 --- /dev/null +++ b/bd/cfb54fafceafd398ef83cf60c41cd4d05dcb80 @@ -0,0 +1,112 @@ +Return-Path: <tomas@tomasvdw.nl> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 5ECE8BAC + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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: <xms:ZOvmWIYHw95d1Sf9QWsUKn0uiVutrqBnRKKUrHFNhzIvTMRkAqZKhw> +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 <tomas@tomasvdw.nl> +To: Gregory Maxwell <greg@xiph.org> +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: <CAAS2fgR0t=QG6HfhF1MKW3k_4mjv7rjWE4T3-wdiL2fB6TVV4Q@mail.gmail.com> +References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com> + <CAAS2fgTEMCkDWdhCWt1EsUrnt3+Z_8m+Y1PTsff5Rc0CBnCKWQ@mail.gmail.com> + <1491526132.723002.936945760.06A943C6@webmail.messagingengine.com> + <CAAS2fgR0t=QG6HfhF1MKW3k_4mjv7rjWE4T3-wdiL2fB6TVV4Q@mail.gmail.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 <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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. + + + |