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 5F11C360 for ; Wed, 18 May 2016 11:15:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com [209.85.213.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CC4781B4 for ; Wed, 18 May 2016 11:15:00 +0000 (UTC) Received: by mail-vk0-f48.google.com with SMTP id f66so56493234vkh.2 for ; Wed, 18 May 2016 04:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=TvVCn8Km/J8464W3I2pQJYa6E9m1Ceh8pJHdu7BX2Bc=; b=s9aecJs1eaHGFWV2a6qOWhEwm2v+xXeiDzeo2wFmEvtsBOb9fxV4h1JGLL1Yee7oR/ br5Ouirl4J20u9SOAjzqhpxTWCAg0q6pM9e9q0qIOz+kNFlinZBRru2kjMmijPdw/Rm1 FJGl/8uLtyod4DPrNWZ4zrWA5VYd8OKMMruuJeEdUcCGeectg6EnEq8kBr002mCROBwO aXs99iSBexklQIxDmZ60pgjCEx/gWc4gWOQQ4Em9cUB2Dq7kJX+U5nK8xLaHPnZZoA0D lCqKKFbMFRwD/dcYkp+gGmzjVqvyI2SvqwSDyPYBhLQgrSrVuZnIcEEDjq/gSBcR7XWH a2Mw== 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:date :message-id:subject:from:to; bh=TvVCn8Km/J8464W3I2pQJYa6E9m1Ceh8pJHdu7BX2Bc=; b=G16Cq8A/Q9rGs610RQ/XLms7rmeLDi+ViIqgPKWNQ+k7kChGyttwvSCo8auD5DDCDT VrBwn0p9N+HqTw5brSKd3j/2Wq6pPMLVr1WJT/CxyPu11cseRNtmq1n1ATtF5Rd1xshr JoQH/4YUzKi3CZov7GU6eXYlA3kufmMqFETDqye5+Pa77RiOfZ8lCvhlPQMuE51c1KYI ft1BS82fDhKlkCRGa0R6kbp6hUN5GBzI17fjjWY5Hnn1DDRNJP2qEfzC3UpdCr8GQF2j 8pjx4WQn1fkxCURKI2ybX9disSPfn4uzwUyWJ8gbLYSoyVi4BEJ5M/6hnds4V6nrLuYR u9Lw== X-Gm-Message-State: AOPr4FVhhfuWMU/lqwDW4GbsJrWgd/u8JG+bdfNthk8/HCf2KuptX0Q2sfwYq2AVanebTJ43cuOQT/s6B4EACQ== MIME-Version: 1.0 X-Received: by 10.159.40.99 with SMTP id c90mr3650263uac.85.1463570099779; Wed, 18 May 2016 04:14:59 -0700 (PDT) Received: by 10.31.141.73 with HTTP; Wed, 18 May 2016 04:14:59 -0700 (PDT) Received: by 10.31.141.73 with HTTP; Wed, 18 May 2016 04:14:59 -0700 (PDT) In-Reply-To: References: <20160517132311.GA21656@fedora-21-dvm> Date: Wed, 18 May 2016 13:14:59 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Bitcoin Dev , Peter Todd Content-Type: multipart/alternative; boundary=94eb2c048618e6d3d605331bf7eb 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 Subject: Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments 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: Wed, 18 May 2016 11:15:01 -0000 --94eb2c048618e6d3d605331bf7eb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On May 17, 2016 15:23, "Peter Todd via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > # TXO Commitments > > Specifically TXO commitments proposes a Merkle Mountain Range=C2=B9 (MMR)= , a > type of deterministic, indexable, insertion ordered merkle tree, which allows > new items to be cheaply appended to the tree with minimal storage requirements, > just log2(n) "mountain tips". Once an output is added to the TXO MMR it i= s > never removed; if an output is spent its status is updated in place. Both the > state of a specific item in the MMR, as well the validity of changes to items > in the MMR, can be proven with log2(n) sized proofs consisting of a merkle path > to the tip of the tree. How expensive it is to update a leaf from this tree from unspent to spent? Wouldn't it be better to have both an append-only TXO and an append-only STXO (with all spent outputs, not only the latest ones like in your "STXO")= ? --94eb2c048618e6d3d605331bf7eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On May 17, 2016 15:23, "Peter Todd via bitcoin-dev" <bitcoin-dev@lists.linuxfo= undation.org> wrote:
> # TXO Commitments
>

> Specifically TXO commitments proposes a Merkle Mountain= Range=C2=B9 (MMR), a
> type of deterministic, indexable, insertion ordered merkle tree, which= allows
> new items to be cheaply appended to the tree with minimal storage requ= irements,
> just log2(n) "mountain tips". Once an output is added to the= TXO MMR it is
> never removed; if an output is spent its status is updated in place. B= oth the
> state of a specific item in the MMR, as well the validity of changes t= o items
> in the MMR, can be proven with log2(n) sized proofs consisting of a me= rkle path
> to the tip of the tree.

How expensive it is to update a leaf from this tree from uns= pent to spent?

Wouldn't it be better to have both an append-only TXO an= d an append-only STXO (with all spent outputs, not only the latest ones lik= e in your "STXO")?

--94eb2c048618e6d3d605331bf7eb--