Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D3918C7D for ; Fri, 11 Dec 2015 16:43:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 116DF143 for ; Fri, 11 Dec 2015 16:43:42 +0000 (UTC) Received: by lfcy184 with SMTP id y184so9588627lfc.1 for ; Fri, 11 Dec 2015 08:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WUTnchFJ4t2jFQHBFqUTYkBjL+cNyVIQEHclIz8XW5E=; b=pNdvJww783XtMh1Z9y/PMu58hngLl4pofdJ15XvdgZSwxkQhlYPyDHHvTZYOHR1sv7 aVthZ7q63omaMpoVUc3iiTsGCSo7W5G2yw9Gwus94//y8FVYBXQjCmh4kwdqwPp38ijA q0MDTWXhEx3TBMMlgJsKi4iNopPVbYyr5UwwVjVipFdD1+RyLxYY+p8Y771OrWh7s1x/ eqfhTLdjJQmILVWBBKpDwVJRjit/ZRkG6ICJwf0pmsGgAUuWIbQkHuQ1YhgnJZ37VKvy RRh9vZ2oFLzs3tg+C4AyWeuyWIdrciG5UpbGraNIzOxkK1sgFHB/BY7T+ejNjeIwWYCY f7Qg== MIME-Version: 1.0 X-Received: by 10.25.137.7 with SMTP id l7mr6790493lfd.63.1449852220491; Fri, 11 Dec 2015 08:43:40 -0800 (PST) Received: by 10.25.25.78 with HTTP; Fri, 11 Dec 2015 08:43:40 -0800 (PST) In-Reply-To: References: <20151208110752.GA31180@amethyst.visucore.com> Date: Fri, 11 Dec 2015 11:43:40 -0500 Message-ID: From: Gavin Andresen To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= , Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113fc260945be40526a20679 X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, URIBL_BLACK 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] Capacity increases for the Bitcoin system. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 16:43:42 -0000 --001a113fc260945be40526a20679 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 11, 2015 at 11:18 AM, Jorge Tim=C3=B3n wrote= : > This is basically what I meant by > > struct hashRootStruct > { > uint256 hashMerkleRoot; > uint256 hashWitnessesRoot; > uint256 hashextendedHeader; > } > > but my design doesn't calculate other_root as it appears in your tree (is > not necessary). > > It is necessary to maintain compatibility with SPV nodes/wallets. Any code that just checks merkle paths up into the block header would have to change if the structure of the merkle tree changed to be three-headed at the top. If it remains a binary tree, then it doesn't need to change at all-- the code that produces the merkle paths will just send a path that is one step deeper. Plus, it's just weird to have a merkle tree that isn't a binary tree..... --=20 -- Gavin Andresen --001a113fc260945be40526a20679 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 11, 2015 at 11:18 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:

This is basica= lly what I meant by

struct hashRootStruct
{
uint256 hashMerkleRoot;
uint256 hashWitnessesRoot;
uint256 hashextendedHeader;
}

but my design doesn't calculate other_root as it = appears in your tree (is not necessary).

It is necessary to maintain compatibi= lity with SPV nodes/wallets.

Any code that just checks merkle paths up into the b= lock header would have to change if the structure of the merkle tree change= d to be three-headed at the top.

=
If it remains a binary tree, then it doesn't= need to change at all-- the code that produces the merkle paths will just = send a path that is one step deeper.

Plus, it's just weird to have a merkle t= ree that isn't a binary tree.....

<= /div>
--
--Gavin Andresen
--001a113fc260945be40526a20679--