public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Date: Fri, 11 Dec 2015 17:18:48 +0100	[thread overview]
Message-ID: <CABm2gDp4+V2-Gu3XTcmRxFy_KCfxrptjhmXBxjf04Kdi5Bf+2A@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T1pLtOaGOVpVs8URAwpbb884htkrFLWtX8-2gGpS6gPWw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3387 bytes --]

  reply	other threads:[~2015-12-11 16:18 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-07 22:02 [bitcoin-dev] Capacity increases for the Bitcoin system Gregory Maxwell
2015-12-07 22:54 ` Bryan Bishop
2015-12-08  2:42 ` Anthony Towns
2015-12-08  4:58   ` Anthony Towns
2015-12-08  5:21     ` Gregory Maxwell
2015-12-08  6:54       ` Anthony Towns
2016-01-18 12:02     ` Anthony Towns
2016-01-22  9:46       ` Anthony Towns
2015-12-08 11:07 ` Wladimir J. van der Laan
2015-12-08 11:14   ` Jorge Timón
2015-12-08 15:12     ` Gavin Andresen
2015-12-08 15:55       ` Justus Ranvier
2015-12-08 17:41         ` Mark Friedenbach
2015-12-08 18:43           ` Justus Ranvier
2015-12-08 19:08           ` Tier Nolan
2015-12-08 19:31         ` Gregory Maxwell
2015-12-08 23:40         ` Jonathan Toomim
2015-12-08 23:48           ` Luke Dashjr
2015-12-09  0:54             ` Jonathan Toomim
2015-12-08 23:50           ` Jorge Timón
2015-12-09  0:56             ` Jonathan Toomim
2015-12-08 23:59       ` Gregory Maxwell
2015-12-09  0:58         ` Jorge Timón
2015-12-09  1:02           ` Jorge Timón
2015-12-09  1:09         ` Gavin Andresen
2015-12-09  1:31           ` Gregory Maxwell
2015-12-09  4:44             ` Ryan Butler
2015-12-09  6:29               ` Gregory Maxwell
2015-12-09  6:36                 ` Ryan Butler
2015-12-09  6:59                 ` Mark Friedenbach
2015-12-09  7:17                   ` Gregory Maxwell
2015-12-09  7:54                 ` Jorge Timón
2015-12-09  8:03                   ` Gregory Maxwell
2015-12-09  8:46                     ` Mark Friedenbach
2015-12-09 11:08                     ` Jorge Timón
2015-12-09 16:40                     ` Gavin Andresen
2015-12-11 16:18                       ` Jorge Timón [this message]
2015-12-11 16:43                         ` Gavin Andresen
2015-12-12  5:13                           ` digitsu
2015-12-12 15:18                             ` Mark Friedenbach
2015-12-14 11:21                               ` Jonathan Toomim
2015-12-14 12:44                                 ` Adam Back
2015-12-09  4:51             ` Anthony Towns
2015-12-09 14:51       ` Chris
     [not found]   ` <CAPWm=eUomq6SBC0ky0WSs5=_G942vigm4RmgYuq0O-yJ-vqC2A@mail.gmail.com>
     [not found]     ` <CAPg+sBig9O5+he0PWhTkX5iin14QLz5+eCCu6KfwU=DxntKYtg@mail.gmail.com>
2015-12-21  4:33       ` Pieter Wuille
2015-12-21  4:42         ` Justus Ranvier
2015-12-21  4:44         ` Alex Morcos
2015-12-21  4:50         ` Mark Friedenbach
2015-12-21  5:29           ` Douglas Roark
2015-12-21  5:21         ` Btc Drak
2015-12-21  8:07           ` Anthony Towns
2015-12-21  9:56             ` Jorge Timón
2015-12-08 23:48 ` Jonathan Toomim
2015-12-09  0:23   ` Gregory Maxwell
     [not found]   ` <CAAS2fgRP8bLWZoKR9-iJS-2RKTGQQ9NG-LpAfa2BOdcR=GuB_A@mail.gmail.com>
2015-12-09  0:40     ` Jonathan Toomim
2015-12-09 12:28 Daniele Pinna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABm2gDp4+V2-Gu3XTcmRxFy_KCfxrptjhmXBxjf04Kdi5Bf+2A@mail.gmail.com \
    --to=jtimon@jtimon.cc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gavinandresen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox