The exact numbers (95% vs. 75% etc) don't need to be completely specified to start working on an implementation. What really matters for now is defining the states and trigger mechanisms. I'd rather we not argue over the optimal values for supermajority requirement at this point. On September 16, 2015 5:03:43 PM EDT, "Jorge Timón via bitcoin-dev" wrote: >I understand your proposal, but I don't see what it accomplishes >compared >to applying the new rule from the start (in your own blocks) and wait >for >95% for consensus activation (which is my preference and it's much >simpler >to implement). >What are the disadvantages of my approach? What are the advantages of >yours? >On Sep 16, 2015 4:57 PM, "Tier Nolan via bitcoin-dev" < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> >> On Wed, Sep 16, 2015 at 9:54 PM, Jorge Timón >wrote: >> >>> >>> On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> > At 75%, if someone sets the bit, then they should be creating >valid >>> blocks (under the rule). >>> >>> You shouldn't rely on that, some may start applying the restrictions >in >>> their own blocks at 0% and others only at 90%. Until it becomes a >consensus >>> rule it is just part of the standard policy (and we shouldn't rely >on nodes >>> following the standard policy). >>> >> >> It would be a consensus rule. If >75% of the blocks in the last 2016 >> window have the bit set, then reject all blocks that have the bit set >and >> fail to meet the rule. >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Sent from my Android device with K-9 Mail. Please excuse my brevity.