* [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
@ 2017-05-29 1:18 CalvinRechner
2017-05-29 10:19 ` James Hilliard
2017-05-29 23:49 ` Oliver Petruzel
0 siblings, 2 replies; 8+ messages in thread
From: CalvinRechner @ 2017-05-29 1:18 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 8467 bytes --]
This proposal is written under the assumption that the signatories to the Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms of the agreement, and intend to enact the updates described therein. As such, criticisms pertaining to the chosen deployment timeline or hard fork upgrade path should be treated as out-of-scope during the initial discussion of this proposal.
Because it includes the activation of a hard fork for which community consensus does not yet exist, this proposal is not likely to be merged into Bitcoin Core in the immediate future, and must instead be maintained and reviewed in a separate downstream repository. However, it is written with the intent to remain cleanly compatible with future network updates and changes, to allow for the option of a straightforward upstream merge if community consensus for the proposal is successfully achieved in the following months.
<pre>
BIP: ?
Layer: Consensus
Title: Compatibility-oriented omnibus proposal
Author: Calvin Rechner <calvinrechner@protonmail•com>
Comments-Summary: No comments yet.
Comments-URI: ?
Status: Draft
Type: Standards Track
Created: 2017-05-28
License: PD
</pre>
===Abstract===
This document describes a virtuous combination of James Hilliard’s “Reduced signalling threshold activation of existing segwit deployment”[2], Shaolin Fry’s “Mandatory activation of segwit deployment”[3], Sergio Demian Lerner’s “Segwit2Mb”[4] proposal, Luke Dashjr’s “Post-segwit 2 MB block size hardfork”[5], and hard fork safety mechanisms from Johnson Lau’s “Spoonnet”[6][7] into a single omnibus proposal and patchset.
===Motivation===
The Consensus 2017 Scaling Agreement[1] stipulated the following commitments:
• Activate Segregated Witness at an 80% threshold, signaling at bit 4
• Activate a 2 MB hard fork within six months
This proposal seeks to fulfill these criteria while retaining maximum compatibility with existing deployment approaches, thereby minimizing the risks of a destructive chain split. Additionally, subsequent indications of implied criteria and expectations of the Agreement[8][9] are satisfied.
The proposed hard fork incorporates a legacy witness discount and 2MB blocksize limit along with the enactment of Spoonnet-derived protectionary measures, to ensure the safest possible fork activation within the constraints of the requirements outlined in the Scaling Agreement.
===Rationale===
To the extent possible, this represents an effort at a best-of-all-worlds proposal, intended to provide a common foundation from which all mutually-inclusive goals can be achieved while risks are minimized.
The individual constituent proposals include the following respective rationales:
James Hilliard’s “Reduced signalling threshold activation of existing segwit deployment”[2] explains:
> The goal here is to minimize chain split risk and network disruption while maximizing backwards compatibility and still providing for rapid activation of segwit at the 80% threshold using bit 4.
Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included to:
> cause the existing "segwit" deployment to activate without needing to release a new deployment.
Both of the aforementioned activation options (“fast-activation” and “flag-day activation”) serve to prevent unnecessary delays in the network upgrade process, addressing a common criticism of the Scaling Agreement and providing an opportunity for cooperation and unity instead.
Sergio Demian Lerner’s “Segwit2Mb”[4] proposal explains the reasoning behind linking SegWit’s activation with that of a later hard fork block size increase:
> Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB block size hard-fork activated ONLY if segwit activates (95% of miners signaling ... to re-unite the Bitcoin community and avoid a cryptocurrency split.
Luke Dashjr’s “Post-segwit 2 MB block size hardfork”[5] suggestions are included to reduce the marginal risks that such an increase in the block size might introduce:
> if the community wishes to adopt (by unanimous consensus) a 2 MB block size hardfork, this is probably the best way to do it right now... Legacy Bitcoin transactions are given the witness discount, and a block size limit of 2 MB is imposed.
Johnson Lau’s anti-replay and network version updates[6][7] are included as general hard fork safety measures:
> In a blockchain split, however, since both forks share the same historical ledger, replay attack would be possible, unless some precautions are taken.
===Copyright===
This document is placed in the public domain.
===Specification===
###Proposal Signaling###
The string “COOP” is included anywhere in the txn-input (scriptSig) of the coinbase-txn to signal compatibility and support.
###Soft Fork###
Fast-activation (segsignal): deployed by a "version bits" with an 80% activation threshold BIP9 with the name "segsignal" and using bit 4... [with a] start time of midnight June 1st, 2017 (epoch time 1496275200) and timeout on midnight November 15th 2017 (epoch time 1510704000). This BIP will cease to be active when segwit is locked-in.[2]
Flag-day activation (BIP148): While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected... This BIP will be active between midnight August 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not locked-in or activated before epoch time 1501545600. This BIP will cease to be active when segwit is locked-in. While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected.[3]
###Hard Fork###
The hard fork deployment is scheduled to occur 6 months after SegWit activates:
(HardForkHeight = SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280)
For blocks equal to or higher than HardForkHeight, Luke-Jr’s legacy witness discount and 2MB limit are enacted, along with the following Spoonnet-based improvements[6][7]:
* A "hardfork signalling block" is a block with the sign bit of header nVersion is set [Clearly invalid for old nodes; easy opt-out for light wallets]
* If the median-time-past of the past 11 blocks is smaller than the HardForkHeight... a hardfork signalling block is invalid.
* Child of a hardfork signalling block MUST also be a hardfork signalling block
* Hardfork network version bit is 0x02000000. A tx is invalid if the highest nVersion byte is not zero, and the network version bit is not set.
===Deployment===
Deployment of the “fast-activation” soft fork is exactly identical to Hilliard’s segsignal proposal[2]. Deployment of the “flag-day” soft fork is exactly identical to Fry’s BIP148 proposal[3]. HardForkHeight is defined as 26280 blocks after SegWit is set to ACTIVE. All blocks with height greater than or equal to this value must adhere to the consensus rules of the 2MB hard fork.
===Backwards compatibility===
This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017.
To prevent the risk of building on top of invalid blocks, miners should upgrade their nodes to support segsignal as well as BIP148.
The intent of this proposal is to maintain full legacy consensus compatibility for users up until the HardForkHeight block height, after which backwards compatibility is waived as enforcement of the hard fork consensus ruleset begins.
===References===
[1] https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.html
[3] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921.html
[5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014399.html
[6] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
[7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013473.html
[8] https://twitter.com/sysmannet/status/867124645279006720
[9] https://twitter.com/JihanWu/status/867139046786465792
[-- Attachment #2: Type: text/html, Size: 11108 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
2017-05-29 1:18 [bitcoin-dev] Compatibility-Oriented Omnibus Proposal CalvinRechner
@ 2017-05-29 10:19 ` James Hilliard
2017-05-29 22:52 ` Erik Aronesty
2017-05-29 23:49 ` Oliver Petruzel
1 sibling, 1 reply; 8+ messages in thread
From: James Hilliard @ 2017-05-29 10:19 UTC (permalink / raw)
To: CalvinRechner; +Cc: bitcoin-dev
For the reasons listed
here(https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki#Motivation)
you should have it so that the HF can not lock in unless the existing
BIP141 segwit deployment is activated.
The biggest issue is that a safe HF is very unlikely to be able to be
coded and tested within 6 months.
On Sun, May 28, 2017 at 8:18 PM, CalvinRechner via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> This proposal is written under the assumption that the signatories to the
> Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms of
> the agreement, and intend to enact the updates described therein. As such,
> criticisms pertaining to the chosen deployment timeline or hard fork upgrade
> path should be treated as out-of-scope during the initial discussion of this
> proposal.
>
> Because it includes the activation of a hard fork for which community
> consensus does not yet exist, this proposal is not likely to be merged into
> Bitcoin Core in the immediate future, and must instead be maintained and
> reviewed in a separate downstream repository. However, it is written with
> the intent to remain cleanly compatible with future network updates and
> changes, to allow for the option of a straightforward upstream merge if
> community consensus for the proposal is successfully achieved in the
> following months.
>
>
> <pre>
> BIP: ?
> Layer: Consensus
> Title: Compatibility-oriented omnibus proposal
> Author: Calvin Rechner <calvinrechner@protonmail•com>
> Comments-Summary: No comments yet.
> Comments-URI: ?
> Status: Draft
> Type: Standards Track
> Created: 2017-05-28
> License: PD
> </pre>
>
>
> ===Abstract===
>
> This document describes a virtuous combination of James Hilliard’s “Reduced
> signalling threshold activation of existing segwit deployment”[2], Shaolin
> Fry’s “Mandatory activation of segwit deployment”[3], Sergio Demian Lerner’s
> “Segwit2Mb”[4] proposal, Luke Dashjr’s “Post-segwit 2 MB block size
> hardfork”[5], and hard fork safety mechanisms from Johnson Lau’s
> “Spoonnet”[6][7] into a single omnibus proposal and patchset.
>
>
> ===Motivation===
>
> The Consensus 2017 Scaling Agreement[1] stipulated the following
> commitments:
>
> • Activate Segregated Witness at an 80% threshold, signaling at bit 4
> • Activate a 2 MB hard fork within six months
>
> This proposal seeks to fulfill these criteria while retaining maximum
> compatibility with existing deployment approaches, thereby minimizing the
> risks of a destructive chain split. Additionally, subsequent indications of
> implied criteria and expectations of the Agreement[8][9] are satisfied.
>
> The proposed hard fork incorporates a legacy witness discount and 2MB
> blocksize limit along with the enactment of Spoonnet-derived protectionary
> measures, to ensure the safest possible fork activation within the
> constraints of the requirements outlined in the Scaling Agreement.
>
>
> ===Rationale===
>
> To the extent possible, this represents an effort at a best-of-all-worlds
> proposal, intended to provide a common foundation from which all
> mutually-inclusive goals can be achieved while risks are minimized.
>
> The individual constituent proposals include the following respective
> rationales:
>
> James Hilliard’s “Reduced signalling threshold activation of existing segwit
> deployment”[2] explains:
>
>> The goal here is to minimize chain split risk and network disruption while
>> maximizing backwards compatibility and still providing for rapid activation
>> of segwit at the 80% threshold using bit 4.
>
> Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included to:
>
>> cause the existing "segwit" deployment to activate without needing to
>> release a new deployment.
>
> Both of the aforementioned activation options (“fast-activation” and
> “flag-day activation”) serve to prevent unnecessary delays in the network
> upgrade process, addressing a common criticism of the Scaling Agreement and
> providing an opportunity for cooperation and unity instead.
>
> Sergio Demian Lerner’s “Segwit2Mb”[4] proposal explains the reasoning behind
> linking SegWit’s activation with that of a later hard fork block size
> increase:
>
>> Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB block
>> size hard-fork activated ONLY if segwit activates (95% of miners signaling
>> ... to re-unite the Bitcoin community and avoid a cryptocurrency split.
>
> Luke Dashjr’s “Post-segwit 2 MB block size hardfork”[5] suggestions are
> included to reduce the marginal risks that such an increase in the block
> size might introduce:
>
>> if the community wishes to adopt (by unanimous consensus) a 2 MB block
>> size hardfork, this is probably the best way to do it right now... Legacy
>> Bitcoin transactions are given the witness discount, and a block size limit
>> of 2 MB is imposed.
>
> Johnson Lau’s anti-replay and network version updates[6][7] are included as
> general hard fork safety measures:
>
>> In a blockchain split, however, since both forks share the same historical
>> ledger, replay attack would be possible, unless some precautions are taken.
>
>
> ===Copyright===
>
> This document is placed in the public domain.
>
>
> ===Specification===
>
> ###Proposal Signaling###
>
> The string “COOP” is included anywhere in the txn-input (scriptSig) of the
> coinbase-txn to signal compatibility and support.
>
> ###Soft Fork###
>
> Fast-activation (segsignal): deployed by a "version bits" with an 80%
> activation threshold BIP9 with the name "segsignal" and using bit 4... [with
> a] start time of midnight June 1st, 2017 (epoch time 1496275200) and timeout
> on midnight November 15th 2017 (epoch time 1510704000). This BIP will cease
> to be active when segwit is locked-in.[2]
>
> Flag-day activation (BIP148): While this BIP is active, all blocks must set
> the nVersion header top 3 bits to 001 together with bit field (1<<1)
> (according to the existing segwit deployment). Blocks that do not signal as
> required will be rejected... This BIP will be active between midnight August
> 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch time
> 1510704000) if the existing segwit deployment is not locked-in or activated
> before epoch time 1501545600. This BIP will cease to be active when segwit
> is locked-in. While this BIP is active, all blocks must set the nVersion
> header top 3 bits to 001 together with bit field (1<<1) (according to the
> existing segwit deployment). Blocks that do not signal as required will be
> rejected.[3]
>
> ###Hard Fork###
>
> The hard fork deployment is scheduled to occur 6 months after SegWit
> activates:
>
> (HardForkHeight = SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280)
>
> For blocks equal to or higher than HardForkHeight, Luke-Jr’s legacy witness
> discount and 2MB limit are enacted, along with the following Spoonnet-based
> improvements[6][7]:
>
> * A "hardfork signalling block" is a block with the sign bit of header
> nVersion is set [Clearly invalid for old nodes; easy opt-out for light
> wallets]
>
> * If the median-time-past of the past 11 blocks is smaller than the
> HardForkHeight... a hardfork signalling block is invalid.
>
> * Child of a hardfork signalling block MUST also be a hardfork signalling
> block
>
> * Hardfork network version bit is 0x02000000. A tx is invalid if the highest
> nVersion byte is not zero, and the network version bit is not set.
>
>
> ===Deployment===
>
> Deployment of the “fast-activation” soft fork is exactly identical to
> Hilliard’s segsignal proposal[2]. Deployment of the “flag-day” soft fork is
> exactly identical to Fry’s BIP148 proposal[3]. HardForkHeight is defined as
> 26280 blocks after SegWit is set to ACTIVE. All blocks with height greater
> than or equal to this value must adhere to the consensus rules of the 2MB
> hard fork.
>
>
> ===Backwards compatibility===
>
> This deployment is compatible with the existing "segwit" bit 1 deployment
> scheduled between midnight November 15th, 2016 and midnight November 15th,
> 2017.
>
> To prevent the risk of building on top of invalid blocks, miners should
> upgrade their nodes to support segsignal as well as BIP148.
>
> The intent of this proposal is to maintain full legacy consensus
> compatibility for users up until the HardForkHeight block height, after
> which backwards compatibility is waived as enforcement of the hard fork
> consensus ruleset begins.
>
>
> ===References===
>
> [1]
> https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.html
> [3] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014399.html
> [6]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
> [7]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013473.html
> [8] https://twitter.com/sysmannet/status/867124645279006720
> [9] https://twitter.com/JihanWu/status/867139046786465792
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
2017-05-29 10:19 ` James Hilliard
@ 2017-05-29 22:52 ` Erik Aronesty
0 siblings, 0 replies; 8+ messages in thread
From: Erik Aronesty @ 2017-05-29 22:52 UTC (permalink / raw)
To: James Hilliard; +Cc: Bitcoin Protocol Discussion, CalvinRechner
[-- Attachment #1: Type: text/plain, Size: 10725 bytes --]
I can't think of any resistance to this, but the code, on a tight timeline,
isn't going to be easy. Is anyone volunteering for this?
On May 29, 2017 6:19 AM, "James Hilliard via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> For the reasons listed
> here(https://github.com/bitcoin/bips/blob/master/bip-
> 0091.mediawiki#Motivation)
> you should have it so that the HF can not lock in unless the existing
> BIP141 segwit deployment is activated.
>
> The biggest issue is that a safe HF is very unlikely to be able to be
> coded and tested within 6 months.
>
> On Sun, May 28, 2017 at 8:18 PM, CalvinRechner via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > This proposal is written under the assumption that the signatories to the
> > Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms
> of
> > the agreement, and intend to enact the updates described therein. As
> such,
> > criticisms pertaining to the chosen deployment timeline or hard fork
> upgrade
> > path should be treated as out-of-scope during the initial discussion of
> this
> > proposal.
> >
> > Because it includes the activation of a hard fork for which community
> > consensus does not yet exist, this proposal is not likely to be merged
> into
> > Bitcoin Core in the immediate future, and must instead be maintained and
> > reviewed in a separate downstream repository. However, it is written with
> > the intent to remain cleanly compatible with future network updates and
> > changes, to allow for the option of a straightforward upstream merge if
> > community consensus for the proposal is successfully achieved in the
> > following months.
> >
> >
> > <pre>
> > BIP: ?
> > Layer: Consensus
> > Title: Compatibility-oriented omnibus proposal
> > Author: Calvin Rechner <calvinrechner@protonmail•com>
> > Comments-Summary: No comments yet.
> > Comments-URI: ?
> > Status: Draft
> > Type: Standards Track
> > Created: 2017-05-28
> > License: PD
> > </pre>
> >
> >
> > ===Abstract===
> >
> > This document describes a virtuous combination of James Hilliard’s
> “Reduced
> > signalling threshold activation of existing segwit deployment”[2],
> Shaolin
> > Fry’s “Mandatory activation of segwit deployment”[3], Sergio Demian
> Lerner’s
> > “Segwit2Mb”[4] proposal, Luke Dashjr’s “Post-segwit 2 MB block size
> > hardfork”[5], and hard fork safety mechanisms from Johnson Lau’s
> > “Spoonnet”[6][7] into a single omnibus proposal and patchset.
> >
> >
> > ===Motivation===
> >
> > The Consensus 2017 Scaling Agreement[1] stipulated the following
> > commitments:
> >
> > • Activate Segregated Witness at an 80% threshold, signaling at bit 4
> > • Activate a 2 MB hard fork within six months
> >
> > This proposal seeks to fulfill these criteria while retaining maximum
> > compatibility with existing deployment approaches, thereby minimizing the
> > risks of a destructive chain split. Additionally, subsequent indications
> of
> > implied criteria and expectations of the Agreement[8][9] are satisfied.
> >
> > The proposed hard fork incorporates a legacy witness discount and 2MB
> > blocksize limit along with the enactment of Spoonnet-derived
> protectionary
> > measures, to ensure the safest possible fork activation within the
> > constraints of the requirements outlined in the Scaling Agreement.
> >
> >
> > ===Rationale===
> >
> > To the extent possible, this represents an effort at a best-of-all-worlds
> > proposal, intended to provide a common foundation from which all
> > mutually-inclusive goals can be achieved while risks are minimized.
> >
> > The individual constituent proposals include the following respective
> > rationales:
> >
> > James Hilliard’s “Reduced signalling threshold activation of existing
> segwit
> > deployment”[2] explains:
> >
> >> The goal here is to minimize chain split risk and network disruption
> while
> >> maximizing backwards compatibility and still providing for rapid
> activation
> >> of segwit at the 80% threshold using bit 4.
> >
> > Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included
> to:
> >
> >> cause the existing "segwit" deployment to activate without needing to
> >> release a new deployment.
> >
> > Both of the aforementioned activation options (“fast-activation” and
> > “flag-day activation”) serve to prevent unnecessary delays in the network
> > upgrade process, addressing a common criticism of the Scaling Agreement
> and
> > providing an opportunity for cooperation and unity instead.
> >
> > Sergio Demian Lerner’s “Segwit2Mb”[4] proposal explains the reasoning
> behind
> > linking SegWit’s activation with that of a later hard fork block size
> > increase:
> >
> >> Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB
> block
> >> size hard-fork activated ONLY if segwit activates (95% of miners
> signaling
> >> ... to re-unite the Bitcoin community and avoid a cryptocurrency split.
> >
> > Luke Dashjr’s “Post-segwit 2 MB block size hardfork”[5] suggestions are
> > included to reduce the marginal risks that such an increase in the block
> > size might introduce:
> >
> >> if the community wishes to adopt (by unanimous consensus) a 2 MB block
> >> size hardfork, this is probably the best way to do it right now...
> Legacy
> >> Bitcoin transactions are given the witness discount, and a block size
> limit
> >> of 2 MB is imposed.
> >
> > Johnson Lau’s anti-replay and network version updates[6][7] are included
> as
> > general hard fork safety measures:
> >
> >> In a blockchain split, however, since both forks share the same
> historical
> >> ledger, replay attack would be possible, unless some precautions are
> taken.
> >
> >
> > ===Copyright===
> >
> > This document is placed in the public domain.
> >
> >
> > ===Specification===
> >
> > ###Proposal Signaling###
> >
> > The string “COOP” is included anywhere in the txn-input (scriptSig) of
> the
> > coinbase-txn to signal compatibility and support.
> >
> > ###Soft Fork###
> >
> > Fast-activation (segsignal): deployed by a "version bits" with an 80%
> > activation threshold BIP9 with the name "segsignal" and using bit 4...
> [with
> > a] start time of midnight June 1st, 2017 (epoch time 1496275200) and
> timeout
> > on midnight November 15th 2017 (epoch time 1510704000). This BIP will
> cease
> > to be active when segwit is locked-in.[2]
> >
> > Flag-day activation (BIP148): While this BIP is active, all blocks must
> set
> > the nVersion header top 3 bits to 001 together with bit field (1<<1)
> > (according to the existing segwit deployment). Blocks that do not signal
> as
> > required will be rejected... This BIP will be active between midnight
> August
> > 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch
> time
> > 1510704000) if the existing segwit deployment is not locked-in or
> activated
> > before epoch time 1501545600. This BIP will cease to be active when
> segwit
> > is locked-in. While this BIP is active, all blocks must set the nVersion
> > header top 3 bits to 001 together with bit field (1<<1) (according to the
> > existing segwit deployment). Blocks that do not signal as required will
> be
> > rejected.[3]
> >
> > ###Hard Fork###
> >
> > The hard fork deployment is scheduled to occur 6 months after SegWit
> > activates:
> >
> > (HardForkHeight = SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280)
> >
> > For blocks equal to or higher than HardForkHeight, Luke-Jr’s legacy
> witness
> > discount and 2MB limit are enacted, along with the following
> Spoonnet-based
> > improvements[6][7]:
> >
> > * A "hardfork signalling block" is a block with the sign bit of header
> > nVersion is set [Clearly invalid for old nodes; easy opt-out for light
> > wallets]
> >
> > * If the median-time-past of the past 11 blocks is smaller than the
> > HardForkHeight... a hardfork signalling block is invalid.
> >
> > * Child of a hardfork signalling block MUST also be a hardfork signalling
> > block
> >
> > * Hardfork network version bit is 0x02000000. A tx is invalid if the
> highest
> > nVersion byte is not zero, and the network version bit is not set.
> >
> >
> > ===Deployment===
> >
> > Deployment of the “fast-activation” soft fork is exactly identical to
> > Hilliard’s segsignal proposal[2]. Deployment of the “flag-day” soft fork
> is
> > exactly identical to Fry’s BIP148 proposal[3]. HardForkHeight is defined
> as
> > 26280 blocks after SegWit is set to ACTIVE. All blocks with height
> greater
> > than or equal to this value must adhere to the consensus rules of the 2MB
> > hard fork.
> >
> >
> > ===Backwards compatibility===
> >
> > This deployment is compatible with the existing "segwit" bit 1 deployment
> > scheduled between midnight November 15th, 2016 and midnight November
> 15th,
> > 2017.
> >
> > To prevent the risk of building on top of invalid blocks, miners should
> > upgrade their nodes to support segsignal as well as BIP148.
> >
> > The intent of this proposal is to maintain full legacy consensus
> > compatibility for users up until the HardForkHeight block height, after
> > which backwards compatibility is waived as enforcement of the hard fork
> > consensus ruleset begins.
> >
> >
> > ===References===
> >
> > [1]
> > https://medium.com/@DCGco/bitcoin-scaling-agreement-at-
> consensus-2017-133521fe9a77
> > [2]
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-May/014380.html
> > [3] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
> > [4]
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-March/013921.html
> > [5]
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-May/014399.html
> > [6]
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-February/013542.html
> > [7]
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-January/013473.html
> > [8] https://twitter.com/sysmannet/status/867124645279006720
> > [9] https://twitter.com/JihanWu/status/867139046786465792
> >
> >
> > _______________________________________________
> > 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
>
[-- Attachment #2: Type: text/html, Size: 13889 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
2017-05-29 1:18 [bitcoin-dev] Compatibility-Oriented Omnibus Proposal CalvinRechner
2017-05-29 10:19 ` James Hilliard
@ 2017-05-29 23:49 ` Oliver Petruzel
2017-05-30 15:51 ` Erik Aronesty
2017-05-30 22:20 ` CalvinRechner
1 sibling, 2 replies; 8+ messages in thread
From: Oliver Petruzel @ 2017-05-29 23:49 UTC (permalink / raw)
To: CalvinRechner; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
>>if the community wishes to adopt (by unanimous consensus) a 2 MB block
size hardfork, this is probably the best way to do it right now... Legacy
Bitcoin transactions are given the witness discount, and a block size limit
of 2 MB is imposed.<<
The above decision may quickly become very controversial. I don't think it's
what most users had/have in mind when they discuss a "2MB+SegWit" solution.
With the current 1MB+SegWit, testing has shown us that normal usage results
in ~2 or 2.1MB blocks.
I think most users will expect a linear increase when Base Size is
increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
With normal usage, the expected results would then be ~4 or 4.2MB blocks.
Am I missing something here, or does Luke's suggested 2MB cap completely
nullify that expected linear increase? If so, why? What's the logic behind
this decision?
I'd love to be armed with a good answer should my colleagues ask me the
same obvious question, so thank you ahead of time!
Respectfully,
Oliver Petruzel
[-- Attachment #2: Type: text/html, Size: 2554 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
2017-05-29 23:49 ` Oliver Petruzel
@ 2017-05-30 15:51 ` Erik Aronesty
2017-05-30 22:20 ` CalvinRechner
1 sibling, 0 replies; 8+ messages in thread
From: Erik Aronesty @ 2017-05-30 15:51 UTC (permalink / raw)
To: Oliver Petruzel; +Cc: Bitcoin Dev, CalvinRechner
[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]
- We now are witnessing this... COOP vs LukeJr COOP, vs BIP148 vs BIP149 vs
BIP91 ... how many are there?:
https://xkcd.com/927
- If some miners and exchanges collude to enact a rapid 2MB+Segwit hard
fork coin... and calling it "bitcoin" on major exchanges this could swiftly
fragment the network.
- If this fork fails to contain an ASICBOOST defense, then this is
essentially an example of core failing to appropriately respond to the CVE
security vulnerability in time.
- A swift BIP148 release in core seems necessary to defend against this.
I am no longer in favor of adding a BIP148 option with default "false"..
I think it should be merged in...enabled, and released ASAP to defend
against these attacks.
On Mon, May 29, 2017 at 7:49 PM, Oliver Petruzel via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> >>if the community wishes to adopt (by unanimous consensus) a 2 MB block
> size hardfork, this is probably the best way to do it right now... Legacy
> Bitcoin transactions are given the witness discount, and a block size limit
> of 2 MB is imposed.<<
>
>
> The above decision may quickly become very controversial. I don't think it's
> what most users had/have in mind when they discuss a "2MB+SegWit" solution.
>
> With the current 1MB+SegWit, testing has shown us that normal usage
> results in ~2 or 2.1MB blocks.
>
> I think most users will expect a linear increase when Base Size is
> increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
> With normal usage, the expected results would then be ~4 or 4.2MB blocks.
>
> Am I missing something here, or does Luke's suggested 2MB cap completely
> nullify that expected linear increase? If so, why? What's the logic behind
> this decision?
>
> I'd love to be armed with a good answer should my colleagues ask me the
> same obvious question, so thank you ahead of time!
>
> Respectfully,
> Oliver Petruzel
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 4254 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
2017-05-29 23:49 ` Oliver Petruzel
2017-05-30 15:51 ` Erik Aronesty
@ 2017-05-30 22:20 ` CalvinRechner
2017-06-02 20:13 ` Jared Lee Richardson
1 sibling, 1 reply; 8+ messages in thread
From: CalvinRechner @ 2017-05-30 22:20 UTC (permalink / raw)
To: Oliver Petruzel; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5702 bytes --]
In principle, there is complete flexibility when it comes to the specific consensus details of the hard fork. One common suggestion has been to phase in a gradual blocksize increase beyond the initial 2MB cap included in Luke-Jr's proposal (a la BIP103); this would certainly be a welcome inclusion in the Omnibus Proposal, provided that is what we want. The reasoning behind incorporating Luke-Jr's 2MB limit and discount-rebalancing was to satisfy the conditions of the Scaling Agreement while ensuring maximum safety, minimum code discrepancies, and minimum controversy among the community; these priorities seem imperative, considering the extreme timeline constraints we are working under and the goals of the proposal. To put it more simply, the intent of the proposal was to serve as a template for the minimum viable fork that can achieve true consensus. A gradual increase to a larger size cap, especially if it were reasonably conservative, would be wholly in accordance with the Omnibus Proposal if that is what it takes to achieve the cooperation between community, industry, and developers in this critical moment of Bitcoin's history.
The purpose of the Omnibus Proposal is singlefold: to achieve the goals of the Consensus 2017 Scaling Agreement in the most maximally-compatible way. We can minimize disruption and loss potential all around by solving these problems in a compatibility-oriented manner. It is possible to fulfill both the letter and the spirit of the Scaling Agreement, to the complete satisfaction of all involved, while preventing chain-split risks in the meantime.
There is no justification for incompatibility with existing deployment approaches, when there is the possibility to work together towards our mutual goals instead. The most rational option is to join forces and avoid any chain-split potential for as long as possible. Under the Omnibus Proposal, once SegWit is activated, the terms of the hard fork are locked in automatically, set to activate 6 months later. The proposal guarantees that a successful SegWit activation is followed by a hard fork. Beyond enforcing the hard fork rules beginning at block height HardForkHeight, the Omnibus Proposal simply represents compatibility with the existing SegWit-activation deployment approaches.
By committing to this proposal, we can ensure unity, at least for now. There do not appear to be any arguments to the contrary. Why squander this opportunity for consensus and harmony? We can leverage the momentum of several disparate movements, and perhaps enjoy some much-needed social solidarity. In a way, everyone can get what they want, and through cooperation, we avoid the risk of a costly fracture.
The Segwit2x Team has begun work on an implementation of the Consensus Scaling Agreement, their operational timeline including the publication of a BIP on June 16, 2017.[1] I call upon the developers and maintainers of this initiative to consider and honor the Omnibus Proposal, extended or modified as needed, as the guiding approach to your development effort. Almost every component of the code exists, in some form or fashion, in the various constituent proposals' reference implementations, most of which have already undergone a significant degree of peer review.
We cannot afford to delay, nor to reimplement; the launch timeline is aggressively optimistic as it is. The quickest and safest approach to achieving the goals set forth at Consensus 2017 is to leverage the existing tools and proposals for the job. We can solve our problems properly, cooperatively.
I humbly ask that Jeff Garzik, Barry Silbert, Mike Belshe, and all of the other wonderful, intelligent collaborators on this project step forward and support the cooperative, compatibility-oriented approach of the Omnibus Proposal.
This is the best way to maximize value for everyone. We have a real opportunity to collaborate and work together on the same team. The Omnibus Proposal, designed in exact accordance with a powerful industry agreement and incorporating the feedback and suggestions provided from within both the developer community and the community-at-large, stands the best chance of uniting everyone under a common front.
Please, for the love of Bitcoin, let us do our best to cooperate.
[1] https://imgur.com/a/a2oPs
Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------- Original Message --------
Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
Local Time: May 29, 2017 6:49 PM
UTC Time: May 29, 2017 11:49 PM
From: opetruzel@gmail•com
To: CalvinRechner <calvinrechner@protonmail•com>
Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
>>if the community wishes to adopt (by unanimous consensus) a 2 MB block size hardfork, this is probably the best way to do it right now... Legacy Bitcoin transactions are given the witness discount, and a block size limit of 2 MB is imposed.<<
The above decision may quickly become very controversial. I don't think it's what most users had/have in mind when they discuss a "2MB+SegWit" solution.
With the current 1MB+SegWit, testing has shown us that normal usage results in ~2 or 2.1MB blocks.
I think most users will expect a linear increase when Base Size is increased to 2000000 bytes and Total Weight is increased to 8000000 bytes. With normal usage, the expected results would then be ~4 or 4.2MB blocks.
Am I missing something here, or does Luke's suggested 2MB cap completely nullify that expected linear increase? If so, why? What's the logic behind this decision?
I'd love to be armed with a good answer should my colleagues ask me the same obvious question, so thank you ahead of time!
Respectfully,
Oliver Petruzel
[-- Attachment #2: Type: text/html, Size: 8179 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
2017-05-30 22:20 ` CalvinRechner
@ 2017-06-02 20:13 ` Jared Lee Richardson
2017-06-02 21:57 ` Sergio Demian Lerner
0 siblings, 1 reply; 8+ messages in thread
From: Jared Lee Richardson @ 2017-06-02 20:13 UTC (permalink / raw)
To: CalvinRechner; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 9474 bytes --]
> The above decision may quickly become very controversial. I don't think
it's what most users had/have in mind when they discuss a "2MB+SegWit"
solution.
> With the current 1MB+SegWit, testing has shown us that normal usage
results in ~2 or 2.1MB blocks.
> I think most users will expect a linear increase when Base Size is
increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
With normal usage, the expected results would then be ~4 or 4.2MB blocks.
I think Calvin is correct here, the secondary limit is not what people
anticipated with the segwit + 2mb agreement. It would not kill the
agreement for me, but it might for others.
What is the justification for the secondary limitation? Is there hard data
to back this? The quadratic hashing problem is frequently brought up, but
that is trivially handled with a hard 1mb transaction limit and on the
other thread there's talk/suggestions of an even lower limit. Are there
any other reasons for this limitation, and is there data to justify those
concerns? If not, this should be left out in favor of a transaction size
limit. If so, hard data would go a long way to dealing with the conversy
this will create.
> Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included
to:
> > cause the existing "segwit" deployment to activate without needing to
release a new deployment.
> Both of the aforementioned activation options (“fast-activation” and
“flag-day activation”) serve to prevent unnecessary delays in the network
upgrade process, addressing a common criticism of the Scaling Agreement and
providing an opportunity for cooperation and unity instead.
This is likely to cause more controversy and unfortunately has the tightest
timelines. Unlike the SW2mb working group's timelines, a hard-coded
timeline couldn't be changed with mutual agreement from the signers.
Given the chance of bit1 accidental activation without clear signaling for
the required bit4 2mb hard fork, I don't think the fair or acceptable
tradeoff is for flag day to require bit1 signaling only. *Flag day should
be modified to accept either bit1 signaling, OR to accept bit4 signaling IF
the 80% threshold hasn't been met.* In this way the anti-segwit working
group members are not in danger of an activated bit1 segwit without also
getting their portion of the compromise, the bit4 signaled HF. If flag day
accepts bit4 OR bit1, AND bit4 requires both bit1 and bit4 once 80% is
reached, flag day is nearly guaranteed to get its stated desire within 1750
blocks (bit4 accepted until block 800; bit4+bit1 signaled afterwards until
95%), but without the chance that the WG signers won't get what they agreed
to.
*That seems like a minor compromise for BIP148. Thoughts on this change to
flag day / BIP148?*
In addition, the aggressiveness of the timelines and the complexity of the
merged COOP proposal may require the BIP148 flag day to be pushed back. I
would think some day in September is achievable, but I'm not sure if August
1st will be.
Jared
On Tue, May 30, 2017 at 3:20 PM, CalvinRechner via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> In principle, there is complete flexibility when it comes to the specific
> consensus details of the hard fork. One common suggestion has been to phase
> in a gradual blocksize increase beyond the initial 2MB cap included in
> Luke-Jr's proposal (a la BIP103); this would certainly be a welcome
> inclusion in the Omnibus Proposal, provided that is what we want. The
> reasoning behind incorporating Luke-Jr's 2MB limit and discount-rebalancing
> was to satisfy the conditions of the Scaling Agreement while ensuring
> maximum safety, minimum code discrepancies, and minimum controversy among
> the community; these priorities seem imperative, considering the extreme
> timeline constraints we are working under and the goals of the proposal. To
> put it more simply, the intent of the proposal was to serve as a template
> for the minimum viable fork that can achieve true consensus. A gradual
> increase to a larger size cap, especially if it were reasonably
> conservative, would be wholly in accordance with the Omnibus Proposal if
> that is what it takes to achieve the cooperation between community,
> industry, and developers in this critical moment of Bitcoin's history.
>
>
> The purpose of the Omnibus Proposal is singlefold: to achieve the goals of
> the Consensus 2017 Scaling Agreement in the most maximally-compatible way.
> We can minimize disruption and loss potential all around by solving these
> problems in a compatibility-oriented manner. It is possible to fulfill both
> the letter and the spirit of the Scaling Agreement, to the complete
> satisfaction of all involved, while preventing chain-split risks in the
> meantime.
>
>
> There is no justification for incompatibility with existing deployment
> approaches, when there is the possibility to work together towards our
> mutual goals instead. The most rational option is to join forces and avoid
> any chain-split potential for as long as possible. Under the Omnibus
> Proposal, once SegWit is activated, the terms of the hard fork are locked
> in automatically, set to activate 6 months later. The proposal guarantees
> that a successful SegWit activation is followed by a hard fork. Beyond
> enforcing the hard fork rules beginning at block height HardForkHeight, the
> Omnibus Proposal simply represents compatibility with the existing
> SegWit-activation deployment approaches.
>
>
> By committing to this proposal, we can ensure unity, at least for now.
> There do not appear to be any arguments to the contrary. Why squander this
> opportunity for consensus and harmony? We can leverage the momentum of
> several disparate movements, and perhaps enjoy some much-needed social
> solidarity. In a way, everyone can get what they want, and through
> cooperation, we avoid the risk of a costly fracture.
>
>
> The Segwit2x Team has begun work on an implementation of the Consensus
> Scaling Agreement, their operational timeline including the publication of
> a BIP on June 16, 2017.[1] I call upon the developers and maintainers of
> this initiative to consider and honor the Omnibus Proposal, extended or
> modified as needed, as the guiding approach to your development effort.
> Almost every component of the code exists, in some form or fashion, in the
> various constituent proposals' reference implementations, most of which
> have already undergone a significant degree of peer review.
>
>
> We cannot afford to delay, nor to reimplement; the launch timeline is
> aggressively optimistic as it is. The quickest and safest approach to
> achieving the goals set forth at Consensus 2017 is to leverage the existing
> tools and proposals for the job. We can solve our problems properly,
> cooperatively.
>
>
> I humbly ask that Jeff Garzik, Barry Silbert, Mike Belshe, and all of the
> other wonderful, intelligent collaborators on this project step forward and
> support the cooperative, compatibility-oriented approach of the Omnibus
> Proposal.
>
>
> This is the best way to maximize value for everyone. We have a real
> opportunity to collaborate and work together on the same team. The Omnibus
> Proposal, designed in exact accordance with a powerful industry agreement
> and incorporating the feedback and suggestions provided from within both
> the developer community and the community-at-large, stands the best chance
> of uniting everyone under a common front.
>
>
> Please, for the love of Bitcoin, let us do our best to cooperate.
>
>
>
> [1] https://imgur.com/a/a2oPs
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
> Local Time: May 29, 2017 6:49 PM
> UTC Time: May 29, 2017 11:49 PM
> From: opetruzel@gmail•com
> To: CalvinRechner <calvinrechner@protonmail•com>
> Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
>
> >>if the community wishes to adopt (by unanimous consensus) a 2 MB block
> size hardfork, this is probably the best way to do it right now... Legacy
> Bitcoin transactions are given the witness discount, and a block size limit
> of 2 MB is imposed.<<
>
>
> The above decision may quickly become very controversial. I don't think it's
> what most users had/have in mind when they discuss a "2MB+SegWit" solution.
>
> With the current 1MB+SegWit, testing has shown us that normal usage
> results in ~2 or 2.1MB blocks.
>
> I think most users will expect a linear increase when Base Size is
> increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
> With normal usage, the expected results would then be ~4 or 4.2MB blocks.
>
> Am I missing something here, or does Luke's suggested 2MB cap completely
> nullify that expected linear increase? If so, why? What's the logic behind
> this decision?
>
> I'd love to be armed with a good answer should my colleagues ask me the
> same obvious question, so thank you ahead of time!
>
> Respectfully,
> Oliver Petruzel
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 12806 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
2017-06-02 20:13 ` Jared Lee Richardson
@ 2017-06-02 21:57 ` Sergio Demian Lerner
0 siblings, 0 replies; 8+ messages in thread
From: Sergio Demian Lerner @ 2017-06-02 21:57 UTC (permalink / raw)
To: Jared Lee Richardson; +Cc: Bitcoin Dev, CalvinRechner
[-- Attachment #1: Type: text/plain, Size: 10147 bytes --]
I don't see LukeJr 2MB limit to be compatible with the NY agreement. For
the rest, seems fine for me.
On Fri, Jun 2, 2017 at 4:13 PM, Jared Lee Richardson via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> > The above decision may quickly become very controversial. I don't think
> it's what most users had/have in mind when they discuss a "2MB+SegWit"
> solution.
> > With the current 1MB+SegWit, testing has shown us that normal usage
> results in ~2 or 2.1MB blocks.
> > I think most users will expect a linear increase when Base Size is
> increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
> With normal usage, the expected results would then be ~4 or 4.2MB blocks.
>
> I think Calvin is correct here, the secondary limit is not what people
> anticipated with the segwit + 2mb agreement. It would not kill the
> agreement for me, but it might for others.
>
> What is the justification for the secondary limitation? Is there hard
> data to back this? The quadratic hashing problem is frequently brought up,
> but that is trivially handled with a hard 1mb transaction limit and on the
> other thread there's talk/suggestions of an even lower limit. Are there
> any other reasons for this limitation, and is there data to justify those
> concerns? If not, this should be left out in favor of a transaction size
> limit. If so, hard data would go a long way to dealing with the conversy
> this will create.
>
>
> > Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included
> to:
> > > cause the existing "segwit" deployment to activate without needing to
> release a new deployment.
> > Both of the aforementioned activation options (“fast-activation” and
> “flag-day activation”) serve to prevent unnecessary delays in the network
> upgrade process, addressing a common criticism of the Scaling Agreement and
> providing an opportunity for cooperation and unity instead.
>
> This is likely to cause more controversy and unfortunately has the
> tightest timelines. Unlike the SW2mb working group's timelines, a
> hard-coded timeline couldn't be changed with mutual agreement from the
> signers.
>
> Given the chance of bit1 accidental activation without clear signaling for
> the required bit4 2mb hard fork, I don't think the fair or acceptable
> tradeoff is for flag day to require bit1 signaling only. *Flag day
> should be modified to accept either bit1 signaling, OR to accept bit4
> signaling IF the 80% threshold hasn't been met.* In this way the
> anti-segwit working group members are not in danger of an activated bit1
> segwit without also getting their portion of the compromise, the bit4
> signaled HF. If flag day accepts bit4 OR bit1, AND bit4 requires both bit1
> and bit4 once 80% is reached, flag day is nearly guaranteed to get its
> stated desire within 1750 blocks (bit4 accepted until block 800; bit4+bit1
> signaled afterwards until 95%), but without the chance that the WG signers
> won't get what they agreed to.
>
> *That seems like a minor compromise for BIP148. Thoughts on this change
> to flag day / BIP148?*
>
> In addition, the aggressiveness of the timelines and the complexity of the
> merged COOP proposal may require the BIP148 flag day to be pushed back. I
> would think some day in September is achievable, but I'm not sure if August
> 1st will be.
>
> Jared
>
>
> On Tue, May 30, 2017 at 3:20 PM, CalvinRechner via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> In principle, there is complete flexibility when it comes to the specific
>> consensus details of the hard fork. One common suggestion has been to phase
>> in a gradual blocksize increase beyond the initial 2MB cap included in
>> Luke-Jr's proposal (a la BIP103); this would certainly be a welcome
>> inclusion in the Omnibus Proposal, provided that is what we want. The
>> reasoning behind incorporating Luke-Jr's 2MB limit and discount-rebalancing
>> was to satisfy the conditions of the Scaling Agreement while ensuring
>> maximum safety, minimum code discrepancies, and minimum controversy among
>> the community; these priorities seem imperative, considering the extreme
>> timeline constraints we are working under and the goals of the proposal. To
>> put it more simply, the intent of the proposal was to serve as a template
>> for the minimum viable fork that can achieve true consensus. A gradual
>> increase to a larger size cap, especially if it were reasonably
>> conservative, would be wholly in accordance with the Omnibus Proposal if
>> that is what it takes to achieve the cooperation between community,
>> industry, and developers in this critical moment of Bitcoin's history.
>>
>>
>> The purpose of the Omnibus Proposal is singlefold: to achieve the goals
>> of the Consensus 2017 Scaling Agreement in the most maximally-compatible
>> way. We can minimize disruption and loss potential all around by solving
>> these problems in a compatibility-oriented manner. It is possible to
>> fulfill both the letter and the spirit of the Scaling Agreement, to the
>> complete satisfaction of all involved, while preventing chain-split risks
>> in the meantime.
>>
>>
>> There is no justification for incompatibility with existing deployment
>> approaches, when there is the possibility to work together towards our
>> mutual goals instead. The most rational option is to join forces and avoid
>> any chain-split potential for as long as possible. Under the Omnibus
>> Proposal, once SegWit is activated, the terms of the hard fork are locked
>> in automatically, set to activate 6 months later. The proposal guarantees
>> that a successful SegWit activation is followed by a hard fork. Beyond
>> enforcing the hard fork rules beginning at block height HardForkHeight, the
>> Omnibus Proposal simply represents compatibility with the existing
>> SegWit-activation deployment approaches.
>>
>>
>> By committing to this proposal, we can ensure unity, at least for now.
>> There do not appear to be any arguments to the contrary. Why squander this
>> opportunity for consensus and harmony? We can leverage the momentum of
>> several disparate movements, and perhaps enjoy some much-needed social
>> solidarity. In a way, everyone can get what they want, and through
>> cooperation, we avoid the risk of a costly fracture.
>>
>>
>> The Segwit2x Team has begun work on an implementation of the Consensus
>> Scaling Agreement, their operational timeline including the publication of
>> a BIP on June 16, 2017.[1] I call upon the developers and maintainers of
>> this initiative to consider and honor the Omnibus Proposal, extended or
>> modified as needed, as the guiding approach to your development effort.
>> Almost every component of the code exists, in some form or fashion, in the
>> various constituent proposals' reference implementations, most of which
>> have already undergone a significant degree of peer review.
>>
>>
>> We cannot afford to delay, nor to reimplement; the launch timeline is
>> aggressively optimistic as it is. The quickest and safest approach to
>> achieving the goals set forth at Consensus 2017 is to leverage the existing
>> tools and proposals for the job. We can solve our problems properly,
>> cooperatively.
>>
>>
>> I humbly ask that Jeff Garzik, Barry Silbert, Mike Belshe, and all of the
>> other wonderful, intelligent collaborators on this project step forward and
>> support the cooperative, compatibility-oriented approach of the Omnibus
>> Proposal.
>>
>>
>> This is the best way to maximize value for everyone. We have a real
>> opportunity to collaborate and work together on the same team. The Omnibus
>> Proposal, designed in exact accordance with a powerful industry agreement
>> and incorporating the feedback and suggestions provided from within both
>> the developer community and the community-at-large, stands the best chance
>> of uniting everyone under a common front.
>>
>>
>> Please, for the love of Bitcoin, let us do our best to cooperate.
>>
>>
>>
>> [1] https://imgur.com/a/a2oPs
>>
>>
>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>
>> -------- Original Message --------
>> Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
>> Local Time: May 29, 2017 6:49 PM
>> UTC Time: May 29, 2017 11:49 PM
>> From: opetruzel@gmail•com
>> To: CalvinRechner <calvinrechner@protonmail•com>
>> Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
>>
>> >>if the community wishes to adopt (by unanimous consensus) a 2 MB block
>> size hardfork, this is probably the best way to do it right now... Legacy
>> Bitcoin transactions are given the witness discount, and a block size limit
>> of 2 MB is imposed.<<
>>
>>
>> The above decision may quickly become very controversial. I don't think it's
>> what most users had/have in mind when they discuss a "2MB+SegWit" solution.
>>
>> With the current 1MB+SegWit, testing has shown us that normal usage
>> results in ~2 or 2.1MB blocks.
>>
>> I think most users will expect a linear increase when Base Size is
>> increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
>> With normal usage, the expected results would then be ~4 or 4.2MB blocks.
>>
>> Am I missing something here, or does Luke's suggested 2MB cap completely
>> nullify that expected linear increase? If so, why? What's the logic behind
>> this decision?
>>
>> I'd love to be armed with a good answer should my colleagues ask me the
>> same obvious question, so thank you ahead of time!
>>
>> Respectfully,
>> Oliver Petruzel
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
[-- Attachment #2: Type: text/html, Size: 14180 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-06-02 21:57 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-29 1:18 [bitcoin-dev] Compatibility-Oriented Omnibus Proposal CalvinRechner
2017-05-29 10:19 ` James Hilliard
2017-05-29 22:52 ` Erik Aronesty
2017-05-29 23:49 ` Oliver Petruzel
2017-05-30 15:51 ` Erik Aronesty
2017-05-30 22:20 ` CalvinRechner
2017-06-02 20:13 ` Jared Lee Richardson
2017-06-02 21:57 ` Sergio Demian Lerner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox