Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 949B6956 for ; Thu, 16 Jun 2016 09:07:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 78FB913D for ; Thu, 16 Jun 2016 09:07:46 +0000 (UTC) Received: by mail-it0-f41.google.com with SMTP id i6so23415713ith.0 for ; Thu, 16 Jun 2016 02:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bittorrent-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SovlNT4hmdV9ABy7nTHLWRFiy18y0D8pxvv+UUQN+pE=; b=yhiD4gFuwwOr4Ua6phhoItq2EUWcfVTAzYPjHe8VE3kyYMZSfB2JijI8BB6FNJAv+8 X2JLA3HCEVUdnqnshYG95mDL94gjppD4UQ7sLQCcsCZxwKxqrxdTZRh0gM7qQB0DW40W 4dp1qn7EaZBOxrbXjOJkcTkWNK1VnuhIbX1Vn3gwr9y6xdz8hsx8D4pFp1NUO6qBaO/x SGeroBxhOVWQ/mM9tnxuFJGh1iEEiKK1uYshX5OcLuaqiQbMfry8owfSIbquAXw5Bas1 PxFJx3oDrN18x30+GlEyPRJWqJ3ED1b88FIMe8pfwo1yqjg8M4BbE8FcisT2vfpAoRId TGaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SovlNT4hmdV9ABy7nTHLWRFiy18y0D8pxvv+UUQN+pE=; b=Lb16REWI6nmQZWjJa/BLZum2L31i9kUCAn6viCSmJWRh5ZVUvrAFnSvuvLgl84X367 2UDJNZqdF5ocx2SyOax6KWMKLc9mTeIYu06fzEkcU8w92efqvZFoYr4VX4G0eC7N1E+l oEnuUrIC9VQm4nnfgyxzBw8nTmCMr8UWS/MNruEpGJ2OYCmpdeci9r5nr0KpgxOPqZGb DRZuMImxMMnk/XrkSq5kRRsz3un7XTENp2Mao/PACmnuy0J2xvvxV4/TuDXdhizIXWJp S3PWg44vIsb3oCiat3Vnt/CPf3hHfR6vkE3dgzTmpNL8oMS0mVt1L19g8CCMtYO3yjjH YFqQ== X-Gm-Message-State: ALyK8tLXkvUC+ZQU1xISLvvECokTZ80Yxy2orqQNv+fwcL8MMSL2Hi/I/1CQo9p6X4ziYj8/trRntuLqLXbMoslA X-Received: by 10.36.149.215 with SMTP id m206mr6178133itd.20.1466068065706; Thu, 16 Jun 2016 02:07:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.134.68 with HTTP; Thu, 16 Jun 2016 02:07:26 -0700 (PDT) In-Reply-To: <20160616032612.GA7792@fedora-21-dvm> References: <20160616001040.GA5026@fedora-21-dvm> <20160616032612.GA7792@fedora-21-dvm> From: Bram Cohen Date: Thu, 16 Jun 2016 02:07:26 -0700 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary=94eb2c05e21a4614a8053561923b X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,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 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Merkle trees and mountain ranges 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, 16 Jun 2016 09:07:47 -0000 --94eb2c05e21a4614a8053561923b Content-Type: text/plain; charset=UTF-8 On Wed, Jun 15, 2016 at 8:26 PM, Peter Todd wrote: > > > > What do you mean by TXO commitments? If you mean that it only records > > insertions rather than deletions, then that can do many of the same > proofs > > but has no way of proving that something is currently in the UTXO set, > > which is functionality I'd like to provide. > > I think you need to re-read my original post on TXO commitments, > specifically > where I say: > > # TXO Commitments > > A merkle tree committing to the state of __all transaction outputs, > both spent > and unspent__, we can provide a method of compactly proving the > current state of > an output. > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html Okay, clearly my assumptions about the parts of that post I didn't read carefully were way off. I'll have to look through it carefully to be able to make coherent apples to apples comparisons. > I'm worried that once there's real transaction fees everyone might stop > > consolidating dust and the set of unspent transactions might grow without > > bound as well, but that's a topic for another day. > > Ok, but then if you're concerned about that risk, why introduce a data > structure - the STXO set - that's _guaranteed_ to grow without bound? > I'm not proposing STXO set commitments either. My point was that there should be incentives for collecting dust. That has nothing to do with this thread though and should be discussed separately (also I don't feel like discussing it because I don't have a good proposal). > > What I'm making is a patricia trie. Its byte level definition is very > > similar to the one in your MMR codebase. > > Which codebase exactly? I have both a insertion-ordered list (MMR) and a > key:value mapping (referred to as a "merbinner tree" in the codebase) in > the > proofchains codebase. They're very different data structures. > I'm talking about your merbinner trees. I read through that part of your codebase carefully and got the impression that the MMR tree section used it as a building block. > > The main differences to your patricia trie are the non-padding sha256 and > > that each level doesn't hash in a record of its depth and the usage of > > ONLY0 and ONLY1. > > I'm rather confused, as the above sounds nothing like what I've > implemented, > which only has leaf nodes, inner nodes, and the special empty node > singleton, > for both the MMR and merbinner trees. > It's quite a bit like merbinner trees. I've basically taken the leaf nodes and smushed them into the inner nodes above them, thus saving a hashing operation and some memory. They're both binary radix trees. > Technically even a patricia trie utxo commitment can have sub-1 cache > > misses per update if some of the updates in a single block are close to > > each other in memory. I think I can get practical Bitcoin updates down > to a > > little bit less than one l2 cache miss per update, but not a lot less. > > I'm very confused as to why you think that's possible. When you say > "practical > Bitcoin updates", what exactly is the data structure you're proposing to > update? How is it indexed? My calculations are: a Bitcoin block contains about 2000 updates. The l2 cache is about 256 kilobytes, and if an update is about 32 bytes times two for the parents, grandparents, etc. then an l2 cache can contain about 4000 values. If the current utxo size is about 2000 * 4000 = 8,000,000 in size then about half the pages which contain a transaction will contain a second one. I think the utxo set is currently about an order of magnitude greater than that, so the number of such collisions will be fairly mall, hence my 'less than one but not a lot less' comment. As for how it's indexed, at a crypto definition level it's just a binary radix tree. In terms of how it's indexed in memory, that involves some optimizations to avoid cache misses. Memory is allocated into blocks of about the size of an 12 cache (or maybe an l1 cache, it will require some testing and optimization). Blocks are either branch blocks, which keep everything in fixed positions, or leaf blocks, which contain fixed size entries for nodes plus indexes within the same leaf block of their children. Branch blocks can have many children which can be either branch blocks or leaf blocks, but typically are either all branch blocks or all leaf blocks. Branch blocks always have exactly one parent. Leaf blocks always have all their inputs come from a single branch block, but there can be multiple ones of those. When a branch block overflows it first tries to put stuff into the last leaf block it used, and if there's no more room it allocates a new one. It's fairly common for branches to have just a few leaf children, but they also could have a lot, depending on whether the base 2 log of the number of things currently in the set modulo the number levels in a branch is a small number. Usually when an update is done it consists of first checking the appropriate output of the root block (it's jumped to directly to avoid unnecessary memory lookups. If there's nothing there the algorithm will walk back until it finds something.) That leads directly to (usually) another branch whose output is jumped to directly again. At Bitcoin utxo set sizes that will usually lead to a leaf block, which is then walked down manually to find the actual terminal node, which is then updated, and the parent, grandparent, etc. is then marked invalid until something which was already marked invalid is hit, and it exits. Calculation of hash values is done lazily. --94eb2c05e21a4614a8053561923b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 15, 2016 at 8:26 PM, Peter Todd <pete@petertodd.org> wrote:
>
> What do you mean by TXO commitments? If you mean that it only records<= br> > insertions rather than deletions, then that can do many of the same pr= oofs
> but has no way of proving that something is currently in the UTXO set,=
> which is functionality I'd like to provide.

I think you need to re-read my original post on TXO commitments, spe= cifically
where I say:

=C2=A0 =C2=A0 # TXO Commitments

=C2=A0 =C2=A0 A merkle tree committing to the state of __all transaction ou= tputs, both spent
=C2=A0 =C2=A0 and unspent__, we can provide a method of compactly proving t= he current state of
=C2=A0 =C2=A0 an output.

https://lists.linuxfound= ation.org/pipermail/bitcoin-dev/2016-May/012715.html
<= br>
Okay, clearly my assumptions about the parts of that post I d= idn't read carefully were way off. I'll have to look through it car= efully to be able to make coherent apples to apples comparisons.
=
> I'm worr= ied that once there's real transaction fees everyone might stop
> consolidating dust and the set of unspent transactions might grow with= out
> bound as well, but that's a topic for another day.

Ok, but then if you're concerned about that risk, why introduce = a data
structure - the STXO set - that's _guaranteed_ to grow without bound?

I'm not proposing STXO set commitmen= ts either. My point was that there should be incentives for collecting dust= . That has nothing to do with this thread though and should be discussed se= parately (also I don't feel like discussing it because I don't have= a good proposal).
=C2=A0
> What I'm making is a patricia trie. Its byte level d= efinition is very
> similar to the one in your MMR codebase.

Which codebase exactly? I have both a insertion-ordered list (MMR) a= nd a
key:value mapping (referred to as a "merbinner tree" in the codeb= ase) in the
proofchains codebase. They're very different data structures.

I'm talking about your merbinner trees. I re= ad through that part of your codebase carefully and got the impression that= the MMR tree section used it as a building block.
=C2=A0
> The main differences to = your patricia trie are the non-padding sha256 and
> that each level doesn't hash in a record of its depth and the usag= e of
> ONLY0 and ONLY1.

I'm rather confused, as the above sounds nothing like what I'= ;ve implemented,
which only has leaf nodes, inner nodes, and the special empty node singleto= n,
for both the MMR and merbinner trees.

I= t's quite a bit like merbinner trees. I've basically taken the leaf= nodes and smushed them into the inner nodes above them, thus saving a hash= ing operation and some memory. They're both binary radix trees.

> Technical= ly even a patricia trie utxo commitment can have sub-1 cache
> misses per update if some of the updates in a single block are close t= o
> each other in memory. I think I can get practical Bitcoin updates down= to a
> little bit less than one l2 cache miss per update, but not a lot less.=

I'm very confused as to why you think that's possible. When = you say "practical
Bitcoin updates", what exactly is the data structure you're propos= ing to
update? How is it indexed?

My calculations = are: a Bitcoin block contains about 2000 updates. The l2 cache is about 256= kilobytes, and if an update is about 32 bytes times two for the parents, g= randparents, etc. then an l2 cache can contain about 4000 values. If the cu= rrent utxo size is about 2000 * 4000 =3D 8,000,000 in size then about half = the pages which contain a transaction will contain a second one. I think th= e utxo set is currently about an order of magnitude greater than that, so t= he number of such collisions will be fairly mall, hence my 'less than o= ne but not a lot less' comment.

As for how it&= #39;s indexed, at a crypto definition level it's just a binary radix tr= ee. In terms of how it's indexed in memory, that involves some optimiza= tions to avoid cache misses. Memory is allocated into blocks of about the s= ize of an 12 cache (or maybe an l1 cache, it will require some testing and = optimization). Blocks are either branch blocks, which keep everything in fi= xed positions, or leaf blocks, which contain fixed size entries for nodes p= lus indexes within the same leaf block of their children. Branch blocks can= have many children which can be either branch blocks or leaf blocks, but t= ypically are either all branch blocks or all leaf blocks. Branch blocks alw= ays have exactly one parent. Leaf blocks always have all their inputs come = from a single branch block, but there can be multiple ones of those. When a= branch block overflows it first tries to put stuff into the last leaf bloc= k it used, and if there's no more room it allocates a new one. It's= fairly common for branches to have just a few leaf children, but they also= could have a lot, depending on whether the base 2 log of the number of thi= ngs currently in the set modulo the number levels in a branch is a small nu= mber.

Usually when an update is done it consists o= f first checking the appropriate output of the root block (it's jumped = to directly to avoid unnecessary memory lookups. If there's nothing the= re the algorithm will walk back until it finds something.) That leads direc= tly to (usually) another branch whose output is jumped to directly again. A= t Bitcoin utxo set sizes that will usually lead to a leaf block, which is t= hen walked down manually to find the actual terminal node, which is then up= dated, and the parent, grandparent, etc. is then marked invalid until somet= hing which was already marked invalid is hit, and it exits. Calculation of = hash values is done lazily.

=C2=A0
--94eb2c05e21a4614a8053561923b--