[bitcoin-dev] A roadmap to a better header format and bigger block size

[bitcoin-dev] A roadmap to a better header format and bigger block size

[jl2012]

I would like to present a 2-3 year roadmap to a better header format and
bigger block size

Objectives:

1. Multistage rule changes to make sure everyone will have enough time to
upgrade
2. Make mining easier, without breaking existing mining hardware and the
Stratum protocol
3. Make future hardfork less disruptive (with Luke-Jr's proposal)

Stage 1 is Segregated Witness (BIP141), which will not break any existing
full or light nodes. This may happen in Q2-Q3 2016

Stage 2 is fixes that will break existing full nodes, but not light nodes:
a. Increase the MAX_BLOCK_SIZE (the exact value is not suggested in this
roadmap), potentially change the witness discount
b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
c. (optional) Move segwit's commitments to the header Merkle tree. This is
optional at this stage as it will be fixed in Stage 3 anyway
This may happen in Q1-Q2 2017

Stage 3 is fixes that will break all existing full nodes and light nodes:
a. Full nodes upgraded to Stage 2 will not need to upgrade again, as the
rules and activation logic should be included already
b. Change the header format to Luke-Jr's proposal, and move all commitments
(tx, witness, etc) to the new structure. All existing mining hardware with
Stratum protocol should work.
c. Reclaiming unused bits in header for mining. All existing mining chips
should still work. Newly designed chips should be ready for the new rule.
d. Fix the time warp attack
This may happen in 2018 to 2019

Pros:
a. Light nodes (usually less tech-savvy users) will have longer time to
upgrade
b. The stage 2 is opt-in for full nodes.
c. The stage 3 is opt-in for light nodes.

Cons:
a. The stage 2 is not opt-in for light nodes. They will blindly follow the
longest chain which they might actually don't want to
b. Non-upgraded full nodes will follow the old chain at Stage 2, which is
likely to have lower value.
c. Non-upgraded light nodes will follow the old chain at Stage 3, which is
likely to have lower value. (However, this is not a concern as no one should
be mining on the old chain at that time)

-------------------------------
An alternative roadmap would be:

Stage 2 is fixes that will break existing full nodes and light nodes.
However, they will not follow the minority chain
a. Increase the MAX_BLOCK_SIZE, potentially change the witness discount
b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
c. Change the header format to Luke-Jr's proposal, and move all commitments
(tx, witness, etc) to the new structure.
This may happen in mid 2017 or later

Stage 3 is fixes that will break all existing full nodes and light nodes. 
a. Full nodes and light nodes upgraded to Stage 2 will not need to upgrade
again, as the rules and activation logic should be included already
b. Reclaiming unused bits in header for mining. All existing mining chips
should still work.
c. Fix the time warp attack
This may happen in 2018 to 2019

Pros:
a. The stage 2 and 3 are opt-in for everyone
b. Even failing to upgrade, full nodes and light nodes won't follow the
minority chain at stage 2

Cons:
a. Non-upgraded full/light nodes will follow the old chain at Stage 3, which
is likely to have lower value. (However, this is not a concern as no one
should be mining on the old chain at that time)
b. It takes longer to implement stage 2 to give enough time for light node
users to upgrade

-------------------------------

In terms of safety, the second proposal is better. In terms of disruption,
the first proposal is less disruptive

I would also like to emphasize that it is miners' responsibility, not the
devs', to confirm that the supermajority of the community accept changes in
Stage 2 and 3.

Reference:
Matt Corallo's proposal:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.
html
Luke-Jr's proposal:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.
html

Re: [bitcoin-dev] A roadmap to a better header format and bigger block size

[Ricardo Filipe]

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

I believe i've seen Luke say this several times before, but there are
several more things that the majority of the devs agree should be in
bitcoin.
I would suggest to compile that list for your stage 3, so that you can have
an hardfork that fixes most of those things, and there should be some
repository with those changes deployed.

2016-02-09 14:16 GMT+00:00 jl2012--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> I would like to present a 2-3 year roadmap to a better header format and
> bigger block size
>
> Objectives:
>
> 1. Multistage rule changes to make sure everyone will have enough time to
> upgrade
> 2. Make mining easier, without breaking existing mining hardware and the
> Stratum protocol
> 3. Make future hardfork less disruptive (with Luke-Jr's proposal)
>
> Stage 1 is Segregated Witness (BIP141), which will not break any existing
> full or light nodes. This may happen in Q2-Q3 2016
>
> Stage 2 is fixes that will break existing full nodes, but not light nodes:
> a. Increase the MAX_BLOCK_SIZE (the exact value is not suggested in this
> roadmap), potentially change the witness discount
> b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
> c. (optional) Move segwit's commitments to the header Merkle tree. This is
> optional at this stage as it will be fixed in Stage 3 anyway
> This may happen in Q1-Q2 2017
>
> Stage 3 is fixes that will break all existing full nodes and light nodes:
> a. Full nodes upgraded to Stage 2 will not need to upgrade again, as the
> rules and activation logic should be included already
> b. Change the header format to Luke-Jr's proposal, and move all commitments
> (tx, witness, etc) to the new structure. All existing mining hardware with
> Stratum protocol should work.
> c. Reclaiming unused bits in header for mining. All existing mining chips
> should still work. Newly designed chips should be ready for the new rule.
> d. Fix the time warp attack
> This may happen in 2018 to 2019
>
> Pros:
> a. Light nodes (usually less tech-savvy users) will have longer time to
> upgrade
> b. The stage 2 is opt-in for full nodes.
> c. The stage 3 is opt-in for light nodes.
>
> Cons:
> a. The stage 2 is not opt-in for light nodes. They will blindly follow the
> longest chain which they might actually don't want to
> b. Non-upgraded full nodes will follow the old chain at Stage 2, which is
> likely to have lower value.
> c. Non-upgraded light nodes will follow the old chain at Stage 3, which is
> likely to have lower value. (However, this is not a concern as no one
> should
> be mining on the old chain at that time)
>
> -------------------------------
> An alternative roadmap would be:
>
> Stage 2 is fixes that will break existing full nodes and light nodes.
> However, they will not follow the minority chain
> a. Increase the MAX_BLOCK_SIZE, potentially change the witness discount
> b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
> c. Change the header format to Luke-Jr's proposal, and move all commitments
> (tx, witness, etc) to the new structure.
> This may happen in mid 2017 or later
>
> Stage 3 is fixes that will break all existing full nodes and light nodes.
> a. Full nodes and light nodes upgraded to Stage 2 will not need to upgrade
> again, as the rules and activation logic should be included already
> b. Reclaiming unused bits in header for mining. All existing mining chips
> should still work.
> c. Fix the time warp attack
> This may happen in 2018 to 2019
>
> Pros:
> a. The stage 2 and 3 are opt-in for everyone
> b. Even failing to upgrade, full nodes and light nodes won't follow the
> minority chain at stage 2
>
> Cons:
> a. Non-upgraded full/light nodes will follow the old chain at Stage 3,
> which
> is likely to have lower value. (However, this is not a concern as no one
> should be mining on the old chain at that time)
> b. It takes longer to implement stage 2 to give enough time for light node
> users to upgrade
>
> -------------------------------
>
> In terms of safety, the second proposal is better. In terms of disruption,
> the first proposal is less disruptive
>
> I would also like to emphasize that it is miners' responsibility, not the
> devs', to confirm that the supermajority of the community accept changes in
> Stage 2 and 3.
>
> Reference:
> Matt Corallo's proposal:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.
> html
> Luke-Jr's proposal:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.
> html
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] A roadmap to a better header format and bigger block size

[Matt Corallo]

As for your stages idea, I generally like the idea (and mentioned it may
be a good idea in my proposal), but am worried about scheduling two
hard-forks at once....Lets do our first hard-fork first with the things
we think we will need anytime in the visible future that we have
reasonable designs for now, and talk about a second one after we've seen
what did/didnt blow up with the first one.

Anyway, this generally seems reasonable - it looks like most of this
matches up with what I said more specifically in my mail yesterday, with
the addition of timewarp fixes, which we should probably add, and Luke's
header changes, which I need to spend some more time thinking about.

Matt

On 02/09/16 14:16, jl2012--- via bitcoin-dev wrote:
> I would like to present a 2-3 year roadmap to a better header format and
> bigger block size
> 
> Objectives:
> 
> 1. Multistage rule changes to make sure everyone will have enough time to
> upgrade
> 2. Make mining easier, without breaking existing mining hardware and the
> Stratum protocol
> 3. Make future hardfork less disruptive (with Luke-Jr's proposal)
> 
> Stage 1 is Segregated Witness (BIP141), which will not break any existing
> full or light nodes. This may happen in Q2-Q3 2016
> 
> Stage 2 is fixes that will break existing full nodes, but not light nodes:
> a. Increase the MAX_BLOCK_SIZE (the exact value is not suggested in this
> roadmap), potentially change the witness discount
> b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
> c. (optional) Move segwit's commitments to the header Merkle tree. This is
> optional at this stage as it will be fixed in Stage 3 anyway
> This may happen in Q1-Q2 2017
> 
> Stage 3 is fixes that will break all existing full nodes and light nodes:
> a. Full nodes upgraded to Stage 2 will not need to upgrade again, as the
> rules and activation logic should be included already
> b. Change the header format to Luke-Jr's proposal, and move all commitments
> (tx, witness, etc) to the new structure. All existing mining hardware with
> Stratum protocol should work.
> c. Reclaiming unused bits in header for mining. All existing mining chips
> should still work. Newly designed chips should be ready for the new rule.
> d. Fix the time warp attack
> This may happen in 2018 to 2019
> 
> Pros:
> a. Light nodes (usually less tech-savvy users) will have longer time to
> upgrade
> b. The stage 2 is opt-in for full nodes.
> c. The stage 3 is opt-in for light nodes.
> 
> Cons:
> a. The stage 2 is not opt-in for light nodes. They will blindly follow the
> longest chain which they might actually don't want to
> b. Non-upgraded full nodes will follow the old chain at Stage 2, which is
> likely to have lower value.
> c. Non-upgraded light nodes will follow the old chain at Stage 3, which is
> likely to have lower value. (However, this is not a concern as no one should
> be mining on the old chain at that time)
> 
> -------------------------------
> An alternative roadmap would be:
> 
> Stage 2 is fixes that will break existing full nodes and light nodes.
> However, they will not follow the minority chain
> a. Increase the MAX_BLOCK_SIZE, potentially change the witness discount
> b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
> c. Change the header format to Luke-Jr's proposal, and move all commitments
> (tx, witness, etc) to the new structure.
> This may happen in mid 2017 or later
> 
> Stage 3 is fixes that will break all existing full nodes and light nodes. 
> a. Full nodes and light nodes upgraded to Stage 2 will not need to upgrade
> again, as the rules and activation logic should be included already
> b. Reclaiming unused bits in header for mining. All existing mining chips
> should still work.
> c. Fix the time warp attack
> This may happen in 2018 to 2019
> 
> Pros:
> a. The stage 2 and 3 are opt-in for everyone
> b. Even failing to upgrade, full nodes and light nodes won't follow the
> minority chain at stage 2
> 
> Cons:
> a. Non-upgraded full/light nodes will follow the old chain at Stage 3, which
> is likely to have lower value. (However, this is not a concern as no one
> should be mining on the old chain at that time)
> b. It takes longer to implement stage 2 to give enough time for light node
> users to upgrade
> 
> -------------------------------
> 
> In terms of safety, the second proposal is better. In terms of disruption,
> the first proposal is less disruptive
> 
> I would also like to emphasize that it is miners' responsibility, not the
> devs', to confirm that the supermajority of the community accept changes in
> Stage 2 and 3.
> 
> Reference:
> Matt Corallo's proposal:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.
> html
> Luke-Jr's proposal:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.
> html
> 
> 
> 
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] A roadmap to a better header format and bigger block size

[jl2012]

I am actually suggesting 1 hardfork, not 2. However, different rules are
activated at different time to enhance safety and reduce disruption. The
advantage is people are required to upgrade once, not twice. Any clients
designed for stage 2 should also be ready for stage 3.


-----Original Message-----
From: Matt Corallo [mailto:lf-lists@mattcorallo.com] 
Sent: Wednesday, 10 February, 2016 06:15
To: jl2012@xbt.hk; bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A roadmap to a better header format and bigger
block size

As for your stages idea, I generally like the idea (and mentioned it may be
a good idea in my proposal), but am worried about scheduling two hard-forks
at once....Lets do our first hard-fork first with the things we think we
will need anytime in the visible future that we have reasonable designs for
now, and talk about a second one after we've seen what did/didnt blow up
with the first one.

Anyway, this generally seems reasonable - it looks like most of this matches
up with what I said more specifically in my mail yesterday, with the
addition of timewarp fixes, which we should probably add, and Luke's header
changes, which I need to spend some more time thinking about.

Matt