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 90F00259 for ; Tue, 28 Feb 2017 23:24:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com [209.85.128.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 344B0139 for ; Tue, 28 Feb 2017 23:24:30 +0000 (UTC) Received: by mail-wr0-f175.google.com with SMTP id u108so18971448wrb.3 for ; Tue, 28 Feb 2017 15:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2VqlDuUbaL6ciAwgrEGvbxmQ7Og0G0hCa8zY7Ni1u08=; b=MR3kFdBLdOMqKIgEmTRNLueW+Ng4fTHtgL/ugF8bqmCwY78kLrOxrQtuPp+XXIS101 eBAvOTZEGCJybT49zVW0bzlCPe7ok/LjnQ5rehRdxOpC4IqwvAgCymDTbGGZWCZFXrjs Kyfkj6x9aR4jlWyLe7Z6fZzsCoO3vn5xtWYz2M2WjYkBg1rFPN3WcNCQd2d3CyBHJpmo zf+m4wjL19dHxp9Ky2pxgm5Sjd76gyxzcKPuql8VO82Oe7hNJZrhWeXh36nSn97aBs+z cWZdEEa4yNFcgqSRZpjiRRygL+6zx/JKzN4WbmknPT9AceQ5af4Wy85rEl45RIkaBWd9 UjYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2VqlDuUbaL6ciAwgrEGvbxmQ7Og0G0hCa8zY7Ni1u08=; b=F+i/BO5efb0M4xc0Jd8DKqKni5bFFS7raDy4Zt6j2uxkMUPso6U3t/TpFcvPYZdzSV G4T83zMaGMFcHEupptYrLuPrBehMnia4GxQZJ5OLAC86F5daSZYHHPAkxkviIF6iAK50 z2cq+1O/9V/cpBN8J5e2TCdGoqY/lTtJYzjnGW0DlxJem6wjelGCKrdpHsYGmZ0phhMT cxEqaiI0135i+fTsT/lswRDBgfOv39cqYfQ/wmz5cpVFy4apFd/Vz1n2MBkFdoC04EGm taJGyIpUCPbUCp6EA7xTeGPrejRJYQV6tblsf76hAo6UilQg18HmxL3KV6MaPBMlQQI9 D/mw== X-Gm-Message-State: AMke39nYcxB3q2xTx+wAZR8CFZB8eCCZ8bLAbXsyyebGDuwE+SxEwHlhRK8DGr64xMR14/4KWvyJ57Tpg26ILQ== X-Received: by 10.223.136.82 with SMTP id e18mr4358235wre.28.1488324268768; Tue, 28 Feb 2017 15:24:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.153.212 with HTTP; Tue, 28 Feb 2017 15:24:28 -0800 (PST) Received: by 10.80.153.212 with HTTP; Tue, 28 Feb 2017 15:24:28 -0800 (PST) In-Reply-To: References: <20170223235105.GA28497@savin.petertodd.org> <20170224010943.GA29218@savin.petertodd.org> <20170224025811.GA31911@savin.petertodd.org> <20170224031531.GA32118@savin.petertodd.org> <20170224043613.GA32502@savin.petertodd.org> <20170225041202.GA11152@savin.petertodd.org> From: Pieter Wuille Date: Tue, 28 Feb 2017 15:24:28 -0800 Message-ID: To: Bitcoin Dev , Bram Cohen Content-Type: multipart/alternative; boundary=001a1146060e59d0fe05499f7f61 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] A Better MMR Definition 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: Tue, 28 Feb 2017 23:24:31 -0000 --001a1146060e59d0fe05499f7f61 Content-Type: text/plain; charset=UTF-8 On Feb 28, 2017 15:10, "Bram Cohen via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: On Tue, Feb 28, 2017 at 8:43 AM, G. Andrew Stone wrote: > > But since transactions' prevouts are not specified by [block height, tx > index, output index] or by TXO index, I don't understand how an insertion > ordered TXO tree can result in efficient lookups. Can you help me > understand this? > You have to have a lookup table going from prevouts to txo index. Lookups on that are relatively fast because looking up things in a hashtable is a single cache miss, while looking up things in a tree is logarithmic cache misses. I'm wondering if there is some confusion here. Yes, someone needs to have a lookup table from prevouts to TXO tree positions. But because an insertion-ordered TXO tree does not rebalance, that table can be maintained by wallets or service providers for just their own coins, instead of by every full node and miner individually for everyone's coins. In the simplest committed TXO model, full nodes simply maintain the TXO root hash, and every transaction/block comes with a proof that its inputs are in the TXO tree, and the necessary information to update the root after spending the inputs and adding the outputs. -- Pieter --001a1146060e59d0fe05499f7f61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Feb 28, 2017 15:10, "Bram Cohen via bitcoin-dev" <= ;bitcoin-dev@lists= .linuxfoundation.org> wrote:
On Tue, Feb 28, 2017 at 8:43 AM, G. Andrew= Stone <g.andrew.stone@gmail.com> wrote:

But since t= ransactions' prevouts are not specified by [block height, tx index, out= put index] or by TXO index, I don't understand how an insertion ordered= TXO tree can result in efficient lookups.=C2=A0 Can you help me understand= this?

You have= to have a lookup table going from prevouts to txo index. Lookups on that a= re relatively fast because looking up things in a hashtable is a single cac= he miss, while looking up things in a tree is logarithmic cache misses.

I'm wondering if there is some confusion here.
Yes, someone needs to have a loo= kup table from prevouts to TXO tree positions. But because an insertion-ord= ered TXO tree does not rebalance, that table can be maintained by wallets o= r service providers for just their own coins, instead of by every full node= and miner individually for everyone's coins.
In the simplest committed TXO model, full nodes s= imply maintain the TXO root hash, and every transaction/block comes with a = proof that its inputs are in the TXO tree, and the necessary information to= update the root after spending the inputs and adding the outputs.

--=C2=A0
= Pieter

--001a1146060e59d0fe05499f7f61--