public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo.com>
To: jl2012@xbt.hk, bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A roadmap to a better header format and bigger block size
Date: Tue, 9 Feb 2016 22:15:15 +0000	[thread overview]
Message-ID: <56BA64F3.2060900@mattcorallo.com> (raw)
In-Reply-To: <239b01d16344$717712d0$54653870$@xbt.hk>

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
> 


  parent reply	other threads:[~2016-02-09 22:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-09 14:16 [bitcoin-dev] A roadmap to a better header format and bigger block size jl2012
2016-02-09 15:53 ` Ricardo Filipe
2016-02-09 22:15 ` Matt Corallo [this message]
2016-02-10  4:26   ` jl2012

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=56BA64F3.2060900@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jl2012@xbt.hk \
    /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