Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CF63ED0E for ; Fri, 11 Dec 2015 16:18:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0BC6F143 for ; Fri, 11 Dec 2015 16:18:49 +0000 (UTC) Received: by vkha189 with SMTP id a189so118562789vkh.2 for ; Fri, 11 Dec 2015 08:18:49 -0800 (PST) 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 :cc:content-type; bh=F/pOk1gam2+89c2y3/rBZdpzqdhOXQmnH+RXZnkjnaU=; b=qQVEsDgNq/VPVohMCooCMBO34C8FmPHZHkdr21nqWRZ6pLieg6ItcMMUCHc/kCCzwN xKb1aKQ6a07ZDN3lOgAgIe84/FMgJwi6u1Srd8mcnJPVepiTROdNXAjjaUEoxVJLTS/i zd7OaJccSd0qYMon/3O2fG6dmayfDmIe0lkLrJeEbMvyO9VBsTxk9I0kUAl7+msLvmO5 fTlC0LhXQBSynoBIVHbFvNNWne+QUohz27n153+Zxo3GBEh6I8wvhaSDAj5BaF+5e8CI XglYDe1fTOqjaiuDuGhqiJIoJ1kHB42nb6Wd9c/NSCZqZ7G6cG0LG53IzR70g9XU4wsf 9R+Q== 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:cc:content-type; bh=F/pOk1gam2+89c2y3/rBZdpzqdhOXQmnH+RXZnkjnaU=; b=gJGlY2UoDTWeG0VbjPEA+gTeiTyXrfcjoz5ApP+KqF2Q/Oc1D8lx/zTXUbc0nVXnL+ b5w5DECGSHZZlXHQYjbk/9+uEecY0JsbWEfG99YZjCI7C1z7yx/6+xl0IDLBcdFPrQ5t RslEdfZI6+RiKMOcCdSnMtK/z/HKqXyPWOJHMVHGH1hXNWISngXcbLbnL7kYmqcArfmp 4XOEE8tSyd6P3N5kR7jKK9lZ2pDUF+tF6bPztBbNJfNCXC/zrOAq5BlqeF8K+rvNbO02 7pP4iXaR04hDp1VHG7lgje8wMKEsPoYRaKNZWLAN4X3ZD6K0DHbZakjyxYMkB44UVWoi u9MA== X-Gm-Message-State: ALoCoQlaDapb9xzaG6dyzB5hONPxpTyr3V4dPriBr6SB/N29d6/QwskPzlzIHd9RZRgwJ1OCf6KsQ9Omz6U1Oh+yq9+h/6ke9A== MIME-Version: 1.0 X-Received: by 10.31.140.199 with SMTP id o190mr14959567vkd.63.1449850729241; Fri, 11 Dec 2015 08:18:49 -0800 (PST) Received: by 10.31.236.70 with HTTP; Fri, 11 Dec 2015 08:18:48 -0800 (PST) Received: by 10.31.236.70 with HTTP; Fri, 11 Dec 2015 08:18:48 -0800 (PST) In-Reply-To: References: <20151208110752.GA31180@amethyst.visucore.com> Date: Fri, 11 Dec 2015 17:18:48 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a11425b20b1b19c0526a1adad 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 Dev 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:18:50 -0000 --001a11425b20b1b19c0526a1adad Content-Type: text/plain; charset=UTF-8 On Dec 9, 2015 5:40 PM, "Gavin Andresen" wrote: > > On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> I think it would be logical to do as part of a hardfork that moved >> commitments generally; e.g. a better position for merged mining (such >> a hardfork was suggested in 2010 as something that could be done if >> merged mining was used), room for commitments to additional block >> back-references for compact SPV proofs, and/or UTXO set commitments. >> Part of the reason to not do it now is that the requirements for the >> other things that would be there are not yet well defined. For these >> other applications, the additional overhead is actually fairly >> meaningful; unlike the fraud proofs. > > > So just design ahead for those future uses. Make the merkle tree: > > > root_in_block_header > / \ > tx_data_root other_root > / \ > segwitness_root reserved_for_future_use_root 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). Since stop requiring bip34 (height in coinbase) is also a hardfork (and a trivial one) I suggested to move it at the same time. But thinking more about it, since BIP34 also elegantly solves BIP30, I would keep the height in the coinbase (even if we move it to the extented header tree as well for convenience). That should be able to include future consensus-enforced commitments (extra back-refs for compact proofs, txo/utxo commitments, etc) or non-consensus data (merged mining data, miner-published data). Greg Maxwell suggested to move those later and I answered fair enough. But thinking more about it, if the extra commitments field is extensible, we don't need to move anything now, and therefore we don't need for those designs (extra back-refs for compact proofs, txo/utxo commitments, etc) to be ready to deploy a hardfork segregated witness: you just need to make sure that your format is extensible via softfork in the future. I'm therefore back to the "let's better deploy segregated witness as a hardfork" position. The change required to the softfork segregated witnesses implementation would be relatively small. Another option would be to deploy both parts (sw and the movement from the coinbase to the extra header) at the same time but with different activation conditions, for example: - For sw: deploy as soon as possible with bip9. - For the hardfork codebase to extra header movement: 1 year grace + bip9 for later miner upgrade confirmation. --001a11425b20b1b19c0526a1adad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 9, 2015 5:40 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
> On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:
>>
>> I think it would be logical to do as part of a hardfork that moved=
>> commitments generally; e.g. a better position for merged mining (s= uch
>> a hardfork was suggested in 2010 as something that could be done i= f
>> merged mining was used), room for commitments to additional block<= br> >> back-references for compact SPV proofs, and/or UTXO set commitment= s.
>> Part of the reason to not do it now is that the requirements for t= he
>> other things that would be there are not yet well defined. For the= se
>> other applications, the additional overhead is actually fairly
>> meaningful; unlike the fraud proofs.
>
>
> So just design ahead for those future uses. Make the merkle tree:
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0root_in_block_header > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0/ =C2=A0 =C2=A0 =C2=A0\
> =C2=A0 tx_data_root =C2=A0 =C2=A0 =C2=A0other_root
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ =C2=A0 =C2=A0 =C2=A0 \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 segwitness_root =C2=A0 =C2=A0 reserved_for= _future_use_root

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).

Since stop requiring bip34 (height in coinbase) is also a ha= rdfork (and a trivial one) I suggested to move it at the same time. But thi= nking more about it, since BIP34 also elegantly solves BIP30, I would keep = the height in the coinbase (even if we move it to the extented header tree = as well for convenience).
That should be able to include future consensus-enforced commitments (extra= back-refs for compact proofs, txo/utxo commitments, etc) or non-consensus = data (merged mining data, miner-published data).
Greg Maxwell suggested to move those later and I answered fair enough. But = thinking more about it, if the extra commitments field is extensible, we do= n't need to move anything now, and therefore we don't need for thos= e=C2=A0 designs (extra back-refs for compact proofs, txo/utxo commitments, = etc) to be ready to deploy a hardfork segregated witness: you just need to = make sure that your format is extensible via softfork in the future.

I'm therefore back to the "let's better deploy = segregated witness as a hardfork" position.
The change required to the softfork segregated witnesses implementation wou= ld be relatively small.

Another option would be to deploy both parts (sw and the mov= ement from the coinbase to the extra header) at the same time but with diff= erent activation conditions, for example:

- For sw: deploy as soon as possible with bip9.
- For the hardfork codebase to extra header movement: 1 year grace + bip9 f= or later miner upgrade confirmation.

--001a11425b20b1b19c0526a1adad--