Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E1503B3F for ; Fri, 24 Feb 2017 00:49:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 466BF16A for ; Fri, 24 Feb 2017 00:49:02 +0000 (UTC) Received: by mail-it0-f44.google.com with SMTP id 203so5125121ith.0 for ; Thu, 23 Feb 2017 16:49:02 -0800 (PST) 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=hWJHSuVlsJOHeAZN5lNTJjWtaxD5YJHosiWY3mEzkuQ=; b=NyrsMdmVWAau49SJDUMamfGFn7+72eP2yNaw3oLQtLgur2ZbPlS/smE/6Vf83PMTw6 RqWiek3Pwy2dONRmo6UoiAxkfYtIzB83jbFMcoxwGcTLmJVPnbSm4+3v4Tt/UB9o5H3z 8vqsU/2Q8RnFyiw7H9MIU51qoHxj6hcJJJtyY+x4/lKXqEXrbdcUwieZOyuDX6FwSTWd Hd2Mpm23SVwjTqdrDHPECnnXt8cLL2d5kixLksL6GFDp3ONeuMb1VcWCH1FTVhzOCQTU Eq+PKuzuL70bjHJlL82mAujCRIrkruBeJqqkbF26Nw7SoJdaSaZIGNNzwCvGJCpnVzN4 eBXw== 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=hWJHSuVlsJOHeAZN5lNTJjWtaxD5YJHosiWY3mEzkuQ=; b=NuhkRE8Ct3pnv+TAse3dnRCpYw2e+MAe9piuu+ml3EXhuwCmmqerveVPRM9YPy4El5 DnyTrH5S4NanjeKrZq1u4Q2DhuqTyo1yS88MLACVWN8knPupSRSxZ1Xtoxt+VLny5ncV 4z4f/3pn2QAnhW5bnodZRKdcn2tNm+BToH8r9koGzxgchJLDXsrdTN2oQ1gPWFTHoRBG tL6y4e7hc3kIpUGXHRVreZiJK7olFVYVoJHDWl9d7F6G7gPO3/P5+l2fwxKipEP4KJEo bGg5z1Y5CHEPYfPJ0YXA1Gdsju3UVg1nR8cjOa9wOS3y1o6wSRDV9EUmeD/LkS4ZH8V4 EYwA== X-Gm-Message-State: AMke39k5W0xdw7e4o3J3L1f03rgtA7hOsbjBtEQ814d/o0A9d/Shm8cUscfhxYdUZbMoTmd9Z1BJuSlXrEHQVtT6 X-Received: by 10.107.34.10 with SMTP id i10mr457631ioi.41.1487897341557; Thu, 23 Feb 2017 16:49:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.73.150 with HTTP; Thu, 23 Feb 2017 16:49:01 -0800 (PST) In-Reply-To: <20170223235105.GA28497@savin.petertodd.org> References: <20170223011506.GC905@savin.petertodd.org> <20170223235105.GA28497@savin.petertodd.org> From: Bram Cohen Date: Thu, 23 Feb 2017 16:49:01 -0800 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary=001a1140ec6881991505493c182f X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM 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] 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: Fri, 24 Feb 2017 00:49:03 -0000 --001a1140ec6881991505493c182f Content-Type: text/plain; charset=UTF-8 On Thu, Feb 23, 2017 at 3:51 PM, Peter Todd wrote: > On Thu, Feb 23, 2017 at 03:13:43PM -0800, Bram Cohen wrote: > > > > I can't speak to MMRs (they look a bit redundant with the actual > blockchain > > history to my eye) but circling back to utxo commitments, the benefits > are > > In what way do you see MMRs as redundant? > You can readily prove something is in the TXO or STXO set using the actual blockchain, and the proofs will be nice and compact because even light nodes are expected to already have all the historical headers. What you can't do with MMRs or the blockchain is make a compact proof that something is still in the utxo set, which is the whole point of utxo commitments. It's totally reasonable for full nodes to independently update and recalculate the utxo set as part of their validation process. The same can't be done for a balanced version of the txo set because it's too big. Relying on proofs as a crutch for using the full txo set would badly exacerbate the already extant problem of miners doing spv mining, and increase the bandwidth a full validating node had to use by a multiple. This whole conversation is badly sidetracked. If people have comments on my merkle set I'd like to engage further with them, but mmrs need to be argued independently on their own merits before being used as a counterpoint to utxo commitments. --001a1140ec6881991505493c182f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 23, 2017 at 3:51 PM, Peter Todd <pete@petertodd.org> wrote:
On Thu, Feb 23,= 2017 at 03:13:43PM -0800, Bram Cohen wrote:
>
> I can't speak to MMRs (they look a bit redundant with the actual b= lockchain
> history to my eye) but circling back to utxo commitments, the benefits= are

In what way do you see MMRs as redundant?

<= /div>
You can readily prove something is in the TXO or STXO set using t= he actual blockchain, and the proofs will be nice and compact because even = light nodes are expected to already have all the historical headers.
<= div>
What you can't do with MMRs or the blockchain is mak= e a compact proof that something is still in the utxo set, which is the who= le point of utxo commitments.

It's totally rea= sonable for full nodes to independently update and recalculate the utxo set= as part of their validation process. The same can't be done for a bala= nced version of the txo set because it's too big. Relying on proofs as = a crutch for using the full txo set would badly exacerbate the already exta= nt problem of miners doing spv mining, and increase the bandwidth a full va= lidating node had to use by a multiple.

This whole= conversation is badly sidetracked. If people have comments on my merkle se= t I'd like to engage further with them, but mmrs need to be argued inde= pendently on their own merits before being used as a counterpoint to utxo c= ommitments.

--001a1140ec6881991505493c182f--