Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
Yes, 75% seems fine - given that there is a already a wide deployment of segwit enforcing nodes This implementation is 100% compatible with a "UASF movement" since, if triggered, it essentially turns all supporting miners into equivalent BIP148 enforcers. This should allay any fears that this would subvert a UASF. The proposed "agreement" which was reached without input from the development community also apparently requires that a hard fork be locked in on the same bit (bit 4). Ideally, such a 2MB increase should be scheduled using BIP103-esqe logic: Gradually increasing from 1MB to 2MB over the course of at least a couple years, beginning 6 months from lock-in. This will give developers ample time to evaluate and react to network impacts. On Wed, May 24, 2017 at 12:02 PM, Wang Chun via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I think we should go for 75%, same Litecoin. As I have said before, 95% > threshold is too high even for unconventional soft forks. > > > 在 2017年5月24日，04:58，Andrew Chow via bitcoin-dev linuxfoundation.org> 写道： > > > > Ah. I see now. It wasn't very clear to me that that is what will happen. > > > > Also, shouldn't the timeout date be set for before the BIP141 timeout? > > Otherwise this could lock in but not have enough time for Segwit to be > > locked in. > > > > > >> On 5/23/2017 4:42 PM, James Hilliard wrote: > >> That is incorrect, it is compatible with the current segwit > >> implementation because it triggers a mandatory signalling period that > >> will activate segwit on existing nodes. > >> > >> On Tue, May 23, 2017 at 4:39 PM, Andrew Chow via bitcoin-dev > >> wrote: > >>> Hi James, > >>> > >>> From what I understand, this proposal is incompatible with the current > >>> segwit implementation with regards to the NODE_WITNESS service bit. I > >>> believe it could cause network partitioning if the service bit is not > >>> changed. > >>> > >>> Andrew > >>> > >>> > On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrote: > I would like to propose an implementation that accomplishes the first > part of the Barry Silbert proposal independently from the second: > > "Activate Segregated Witness at an 80% threshold, signaling at bit 4" > in a way that > > 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. > > By activating segwit immediately and separately from any HF we can > scale quickly without risking a rushed combined segwit+HF that would > almost certainly cause widespread issues. > > Draft proposal: > https://github.com/jameshilliard/bips/blob/bip- > segsignal/bip-segsignal.mediawiki > > Proposal text: > > BIP: segsignal > Layer: Consensus (soft fork) > Title: Reduced signalling threshold activation of existing segwit > deployment > Author: James Hilliard > Status: Draft > Type: Standards Track > Created: 2017-05-22 > License: BSD-3-Clause > CC0-1.0 > > > ==Abstract== > > This document specifies a method to activate the existing BIP9 segwit > deployment with a majority hashpower less than 95%. > > ==Definitions== > > "existing segwit deployment" refer to the BIP9 "segwit" deployment > using bit 1, between November 15th 2016 and November 15th 2017 to > activate BIP141, BIP143 and BIP147. > > ==Motivation== > > Segwit increases the blocksize, fixes transaction malleability, and > makes scripting easier to upgrade as well as bringing many other > [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits]. > > This BIP provides a way for a simple majority of miners to coordinate > activation of the existing segwit deployment with less than 95% > hashpower. For a number of reasons a complete redeployment of segwit > is difficulty to do until the existing deployment expires. This is due > to 0.13.1+ having many segwit related features active already, > including all the P2P components, the new network service flag, the > witness-tx and block messages, compact blocks v2 and preferential > peering. A redeployment of segwit will need to redefine all these > things and doing so before expiry would greatly complicate testing. > > ==Specification== > > 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. > > ==Deployment== > > This BIP will be deployed by a "version bits" with an 80%(this can be > adjusted if desired) activation threshold BIP9 with the name > "segsignal"
Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
I would be fine with that, since segwit is widely deployed on the
network already a lower activation threshold should be safe.
On Wed, May 24, 2017 at 12:02 PM, Wang Chun <1240...@gmail.com> wrote:
> I think we should go for 75%, same Litecoin. As I have said before, 95%
> threshold is too high even for unconventional soft forks.
>
>> 在 2017年5月24日，04:58，Andrew Chow via bitcoin-dev
>> 写道：
>>
>> Ah. I see now. It wasn't very clear to me that that is what will happen.
>>
>> Also, shouldn't the timeout date be set for before the BIP141 timeout?
>> Otherwise this could lock in but not have enough time for Segwit to be
>> locked in.
>>
>>
>>> On 5/23/2017 4:42 PM, James Hilliard wrote:
>>> That is incorrect, it is compatible with the current segwit
>>> implementation because it triggers a mandatory signalling period that
>>> will activate segwit on existing nodes.
>>>
>>> On Tue, May 23, 2017 at 4:39 PM, Andrew Chow via bitcoin-dev
>>> wrote:
Hi James,
From what I understand, this proposal is incompatible with the current
segwit implementation with regards to the NODE_WITNESS service bit. I
believe it could cause network partitioning if the service bit is not
changed.
Andrew
> On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrote:
> I would like to propose an implementation that accomplishes the first
> part of the Barry Silbert proposal independently from the second:
>
> "Activate Segregated Witness at an 80% threshold, signaling at bit 4"
> in a way that
>
> 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.
>
> By activating segwit immediately and separately from any HF we can
> scale quickly without risking a rushed combined segwit+HF that would
> almost certainly cause widespread issues.
>
> Draft proposal:
> https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>
> Proposal text:
>
> BIP: segsignal
> Layer: Consensus (soft fork)
> Title: Reduced signalling threshold activation of existing segwit
> deployment
> Author: James Hilliard
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
>
>
> ==Abstract==
>
> This document specifies a method to activate the existing BIP9 segwit
> deployment with a majority hashpower less than 95%.
>
> ==Definitions==
>
> "existing segwit deployment" refer to the BIP9 "segwit" deployment
> using bit 1, between November 15th 2016 and November 15th 2017 to
> activate BIP141, BIP143 and BIP147.
>
> ==Motivation==
>
> Segwit increases the blocksize, fixes transaction malleability, and
> makes scripting easier to upgrade as well as bringing many other
> [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower. For a number of reasons a complete redeployment of segwit
> is difficulty to do until the existing deployment expires. This is due
> to 0.13.1+ having many segwit related features active already,
> including all the P2P components, the new network service flag, the
> witness-tx and block messages, compact blocks v2 and preferential
> peering. A redeployment of segwit will need to redefine all these
> things and doing so before expiry would greatly complicate testing.
>
> ==Specification==
>
> 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.
>
> ==Deployment==
>
> This BIP will be deployed by a "version bits" with an 80%(this can be
> adjusted if desired) activation threshold BIP9 with the name
> "segsignal" and using bit 4.
>
> This BIP will have 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.
>
> === Reference implementation ===
>
>
> // Check if Segregated Witness is Locked In
> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
> Consensus::Params& params)
> {
>LOCK(cs_main);
>return (VersionBitsState(pindexPrev, params,
> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
> THRESHOLD_LOCKED_IN);
> }
>
> // SEGSIGNAL mandatory segwit signalling.
> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> Conse
Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
I think we should go for 75%, same Litecoin. As I have said before, 95%
threshold is too high even for unconventional soft forks.
> 在 2017年5月24日，04:58，Andrew Chow via bitcoin-dev
> 写道：
>
> Ah. I see now. It wasn't very clear to me that that is what will happen.
>
> Also, shouldn't the timeout date be set for before the BIP141 timeout?
> Otherwise this could lock in but not have enough time for Segwit to be
> locked in.
>
>
>> On 5/23/2017 4:42 PM, James Hilliard wrote:
>> That is incorrect, it is compatible with the current segwit
>> implementation because it triggers a mandatory signalling period that
>> will activate segwit on existing nodes.
>>
>> On Tue, May 23, 2017 at 4:39 PM, Andrew Chow via bitcoin-dev
>> wrote:
>>> Hi James,
>>>
>>> From what I understand, this proposal is incompatible with the current
>>> segwit implementation with regards to the NODE_WITNESS service bit. I
>>> believe it could cause network partitioning if the service bit is not
>>> changed.
>>>
>>> Andrew
>>>
>>>
On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrote:
I would like to propose an implementation that accomplishes the first
part of the Barry Silbert proposal independently from the second:
"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
in a way that
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.
By activating segwit immediately and separately from any HF we can
scale quickly without risking a rushed combined segwit+HF that would
almost certainly cause widespread issues.
Draft proposal:
https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
Proposal text:
BIP: segsignal
Layer: Consensus (soft fork)
Title: Reduced signalling threshold activation of existing segwit
deployment
Author: James Hilliard
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-3-Clause
CC0-1.0
==Abstract==
This document specifies a method to activate the existing BIP9 segwit
deployment with a majority hashpower less than 95%.
==Definitions==
"existing segwit deployment" refer to the BIP9 "segwit" deployment
using bit 1, between November 15th 2016 and November 15th 2017 to
activate BIP141, BIP143 and BIP147.
==Motivation==
Segwit increases the blocksize, fixes transaction malleability, and
makes scripting easier to upgrade as well as bringing many other
[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
This BIP provides a way for a simple majority of miners to coordinate
activation of the existing segwit deployment with less than 95%
hashpower. For a number of reasons a complete redeployment of segwit
is difficulty to do until the existing deployment expires. This is due
to 0.13.1+ having many segwit related features active already,
including all the P2P components, the new network service flag, the
witness-tx and block messages, compact blocks v2 and preferential
peering. A redeployment of segwit will need to redefine all these
things and doing so before expiry would greatly complicate testing.
==Specification==
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.
==Deployment==
This BIP will be deployed by a "version bits" with an 80%(this can be
adjusted if desired) activation threshold BIP9 with the name
"segsignal" and using bit 4.
This BIP will have 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.
=== Reference implementation ===
// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
Consensus::Params& params)
{
LOCK(cs_main);
return (VersionBitsState(pindexPrev, params,
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
THRESHOLD_LOCKED_IN);
}
// SEGSIGNAL mandatory segwit signalling.
if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
&&
!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
// Segwit is not locked in
!IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
and is not active.
{
b
Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
Ah. I see now. It wasn't very clear to me that that is what will happen.
Also, shouldn't the timeout date be set for before the BIP141 timeout?
Otherwise this could lock in but not have enough time for Segwit to be
locked in.
On 5/23/2017 4:42 PM, James Hilliard wrote:
> That is incorrect, it is compatible with the current segwit
> implementation because it triggers a mandatory signalling period that
> will activate segwit on existing nodes.
>
> On Tue, May 23, 2017 at 4:39 PM, Andrew Chow via bitcoin-dev
> wrote:
>> Hi James,
>>
>> From what I understand, this proposal is incompatible with the current
>> segwit implementation with regards to the NODE_WITNESS service bit. I
>> believe it could cause network partitioning if the service bit is not
>> changed.
>>
>> Andrew
>>
>>
>> On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrote:
>>> I would like to propose an implementation that accomplishes the first
>>> part of the Barry Silbert proposal independently from the second:
>>>
>>> "Activate Segregated Witness at an 80% threshold, signaling at bit 4"
>>> in a way that
>>>
>>> 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.
>>>
>>> By activating segwit immediately and separately from any HF we can
>>> scale quickly without risking a rushed combined segwit+HF that would
>>> almost certainly cause widespread issues.
>>>
>>> Draft proposal:
>>> https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>>>
>>> Proposal text:
>>>
>>> BIP: segsignal
>>> Layer: Consensus (soft fork)
>>> Title: Reduced signalling threshold activation of existing segwit
>>> deployment
>>> Author: James Hilliard
>>> Status: Draft
>>> Type: Standards Track
>>> Created: 2017-05-22
>>> License: BSD-3-Clause
>>>CC0-1.0
>>>
>>>
>>> ==Abstract==
>>>
>>> This document specifies a method to activate the existing BIP9 segwit
>>> deployment with a majority hashpower less than 95%.
>>>
>>> ==Definitions==
>>>
>>> "existing segwit deployment" refer to the BIP9 "segwit" deployment
>>> using bit 1, between November 15th 2016 and November 15th 2017 to
>>> activate BIP141, BIP143 and BIP147.
>>>
>>> ==Motivation==
>>>
>>> Segwit increases the blocksize, fixes transaction malleability, and
>>> makes scripting easier to upgrade as well as bringing many other
>>> [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>>>
>>> This BIP provides a way for a simple majority of miners to coordinate
>>> activation of the existing segwit deployment with less than 95%
>>> hashpower. For a number of reasons a complete redeployment of segwit
>>> is difficulty to do until the existing deployment expires. This is due
>>> to 0.13.1+ having many segwit related features active already,
>>> including all the P2P components, the new network service flag, the
>>> witness-tx and block messages, compact blocks v2 and preferential
>>> peering. A redeployment of segwit will need to redefine all these
>>> things and doing so before expiry would greatly complicate testing.
>>>
>>> ==Specification==
>>>
>>> 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.
>>>
>>> ==Deployment==
>>>
>>> This BIP will be deployed by a "version bits" with an 80%(this can be
>>> adjusted if desired) activation threshold BIP9 with the name
>>> "segsignal" and using bit 4.
>>>
>>> This BIP will have 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.
>>>
>>> === Reference implementation ===
>>>
>>>
>>> // Check if Segregated Witness is Locked In
>>> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>>> Consensus::Params& params)
>>> {
>>> LOCK(cs_main);
>>> return (VersionBitsState(pindexPrev, params,
>>> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>>> THRESHOLD_LOCKED_IN);
>>> }
>>>
>>> // SEGSIGNAL mandatory segwit signalling.
>>> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>>> Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
>>> &&
>>> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>>> // Segwit is not locked in
>>> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>>> and is not active.
>>> {
>>> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>>> VERSIONBITS_TOP_BITS;
>>> bool fSegbit = (pindex->nVersion &
>>> VersionBitsMask(chainparams.GetConsensus(),
>>> Consensus::DEPLOYMENT_SEGWIT)) != 0;
>>> if (!(fVersionBits && fSegbit)) {
>>> return state.DoS(0, error("ConnectBlock(): relayed block must
Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
That is incorrect, it is compatible with the current segwit
implementation because it triggers a mandatory signalling period that
will activate segwit on existing nodes.
On Tue, May 23, 2017 at 4:39 PM, Andrew Chow via bitcoin-dev
wrote:
> Hi James,
>
> From what I understand, this proposal is incompatible with the current
> segwit implementation with regards to the NODE_WITNESS service bit. I
> believe it could cause network partitioning if the service bit is not
> changed.
>
> Andrew
>
>
> On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrote:
>> I would like to propose an implementation that accomplishes the first
>> part of the Barry Silbert proposal independently from the second:
>>
>> "Activate Segregated Witness at an 80% threshold, signaling at bit 4"
>> in a way that
>>
>> 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.
>>
>> By activating segwit immediately and separately from any HF we can
>> scale quickly without risking a rushed combined segwit+HF that would
>> almost certainly cause widespread issues.
>>
>> Draft proposal:
>> https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>>
>> Proposal text:
>>
>> BIP: segsignal
>> Layer: Consensus (soft fork)
>> Title: Reduced signalling threshold activation of existing segwit
>> deployment
>> Author: James Hilliard
>> Status: Draft
>> Type: Standards Track
>> Created: 2017-05-22
>> License: BSD-3-Clause
>>CC0-1.0
>>
>>
>> ==Abstract==
>>
>> This document specifies a method to activate the existing BIP9 segwit
>> deployment with a majority hashpower less than 95%.
>>
>> ==Definitions==
>>
>> "existing segwit deployment" refer to the BIP9 "segwit" deployment
>> using bit 1, between November 15th 2016 and November 15th 2017 to
>> activate BIP141, BIP143 and BIP147.
>>
>> ==Motivation==
>>
>> Segwit increases the blocksize, fixes transaction malleability, and
>> makes scripting easier to upgrade as well as bringing many other
>> [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>>
>> This BIP provides a way for a simple majority of miners to coordinate
>> activation of the existing segwit deployment with less than 95%
>> hashpower. For a number of reasons a complete redeployment of segwit
>> is difficulty to do until the existing deployment expires. This is due
>> to 0.13.1+ having many segwit related features active already,
>> including all the P2P components, the new network service flag, the
>> witness-tx and block messages, compact blocks v2 and preferential
>> peering. A redeployment of segwit will need to redefine all these
>> things and doing so before expiry would greatly complicate testing.
>>
>> ==Specification==
>>
>> 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.
>>
>> ==Deployment==
>>
>> This BIP will be deployed by a "version bits" with an 80%(this can be
>> adjusted if desired) activation threshold BIP9 with the name
>> "segsignal" and using bit 4.
>>
>> This BIP will have 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.
>>
>> === Reference implementation ===
>>
>>
>> // Check if Segregated Witness is Locked In
>> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>> Consensus::Params& params)
>> {
>> LOCK(cs_main);
>> return (VersionBitsState(pindexPrev, params,
>> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>> THRESHOLD_LOCKED_IN);
>> }
>>
>> // SEGSIGNAL mandatory segwit signalling.
>> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>> Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
>> &&
>> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>> // Segwit is not locked in
>> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>> and is not active.
>> {
>> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>> VERSIONBITS_TOP_BITS;
>> bool fSegbit = (pindex->nVersion &
>> VersionBitsMask(chainparams.GetConsensus(),
>> Consensus::DEPLOYMENT_SEGWIT)) != 0;
>> if (!(fVersionBits && fSegbit)) {
>> return state.DoS(0, error("ConnectBlock(): relayed block must
>> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>> }
>> }
>>
>>
>> https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1
>>
>> ==Backwards Compatibility==
>>
>> This deployment is compatible with the existing "segwit" bit 1
>> deployment scheduled between midnight November 15th, 2016 and midnight
>> November 15th, 2017. Miners will need t
Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
Hi James,
>From what I understand, this proposal is incompatible with the current
segwit implementation with regards to the NODE_WITNESS service bit. I
believe it could cause network partitioning if the service bit is not
changed.
Andrew
On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrote:
> I would like to propose an implementation that accomplishes the first
> part of the Barry Silbert proposal independently from the second:
>
> "Activate Segregated Witness at an 80% threshold, signaling at bit 4"
> in a way that
>
> 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.
>
> By activating segwit immediately and separately from any HF we can
> scale quickly without risking a rushed combined segwit+HF that would
> almost certainly cause widespread issues.
>
> Draft proposal:
> https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>
> Proposal text:
>
> BIP: segsignal
> Layer: Consensus (soft fork)
> Title: Reduced signalling threshold activation of existing segwit deployment
> Author: James Hilliard
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
>CC0-1.0
>
>
> ==Abstract==
>
> This document specifies a method to activate the existing BIP9 segwit
> deployment with a majority hashpower less than 95%.
>
> ==Definitions==
>
> "existing segwit deployment" refer to the BIP9 "segwit" deployment
> using bit 1, between November 15th 2016 and November 15th 2017 to
> activate BIP141, BIP143 and BIP147.
>
> ==Motivation==
>
> Segwit increases the blocksize, fixes transaction malleability, and
> makes scripting easier to upgrade as well as bringing many other
> [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower. For a number of reasons a complete redeployment of segwit
> is difficulty to do until the existing deployment expires. This is due
> to 0.13.1+ having many segwit related features active already,
> including all the P2P components, the new network service flag, the
> witness-tx and block messages, compact blocks v2 and preferential
> peering. A redeployment of segwit will need to redefine all these
> things and doing so before expiry would greatly complicate testing.
>
> ==Specification==
>
> 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.
>
> ==Deployment==
>
> This BIP will be deployed by a "version bits" with an 80%(this can be
> adjusted if desired) activation threshold BIP9 with the name
> "segsignal" and using bit 4.
>
> This BIP will have 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.
>
> === Reference implementation ===
>
>
> // Check if Segregated Witness is Locked In
> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
> Consensus::Params& params)
> {
> LOCK(cs_main);
> return (VersionBitsState(pindexPrev, params,
> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
> THRESHOLD_LOCKED_IN);
> }
>
> // SEGSIGNAL mandatory segwit signalling.
> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
> &&
> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> // Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
> and is not active.
> {
> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS;
> bool fSegbit = (pindex->nVersion &
> VersionBitsMask(chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGWIT)) != 0;
> if (!(fVersionBits && fSegbit)) {
> return state.DoS(0, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> }
> }
>
>
> https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1
>
> ==Backwards Compatibility==
>
> This deployment is compatible with the existing "segwit" bit 1
> deployment scheduled between midnight November 15th, 2016 and midnight
> November 15th, 2017. Miners will need to upgrade their nodes to
> support segsignal otherwise they may build on top of an invalid block.
> While this bip is active users should either upgrade to segsignal or
> wait for additional confirmations when accepting payments.
>
> ==Rationale==
>
> Historically we have used IsSuperMajority() to activate soft forks
> such as BIP66 which has a mandatory signalling requireme
Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
On Tue, May 23, 2017 at 5:51 AM, Kekcoin wrote: > I think there may be merit to this idea, allowing for political compromise > without sacrificing the technological integrity of Bitcoin. There are a few > mechanical problems I see with it, though. > > 1. It should change its activation logic from BIP9-style to BIP8-style with > a flagday of August 1. This to maintain backwards compatibility with the > current deployment of BIP148 nodes. This proposal seems to be a measure to > prevent a chainsplit, so it must make sure to avoid triggering one. That can be done as a separate proposal, it's not mutually exclusive to this one for those who intend to run BIP148. > > 2. This should be for miners only; non-miners should not enforce this. It > severely weakens the block-signalling activation mechanism in several ways > (lowered threshold, short deployment timeframe, no "locked in" delay before > activation) and by doing so opens up attack vectors for > consensus-partitioning attacks using malicious false signalling. For > non-miners that seek to take their fate into their own hands, enforcing > BIP148 is enough. I disagree that it should be only run by miners, enforcement of segsignal mandatory signalling by economic nodes strongly discourages any false signaling. > > 3. Even for miners this is more risky than usual; only 31% of hashrate is > required to false-signal the activation to fork-off honest miners. This > attack vector is magnified by the lack of "locked in" delay that would allow > laggards to upgrade before activation. I suggest adding in at least a 1-week > lock-in period (given the shorter timeframes 2 weeks may eat up too much of > the available voting time before the brick wall of BIP148 activation on > August 1). Those who can should still upgrade for segsignal, the more that upgrade ahead of activation the more secure it is. Those who don't upgrade would want to wait for more confirmations anyways. I didn't think a lock in period was all that good an idea here due to the fairly short deployment timeline. > > Under the assumption that this is indeed compatible with the terms of the > Silbert agreement, we can presume the involved miners are willing to trust > eachother more than usual so such a short lock-in period should be > acceptable. > > ---- Original Message > Subject: [bitcoin-dev] Reduced signalling threshold activation of existing > segwit deployment > Local Time: May 23, 2017 1:40 AM > UTC Time: May 22, 2017 10:40 PM > From: bitcoin-dev@lists.linuxfoundation.org > To: Bitcoin Dev > > I would like to propose an implementation that accomplishes the first > part of the Barry Silbert proposal independently from the second: > > "Activate Segregated Witness at an 80% threshold, signaling at bit 4" > in a way that > > 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. > > By activating segwit immediately and separately from any HF we can > scale quickly without risking a rushed combined segwit+HF that would > almost certainly cause widespread issues. > > Draft proposal: > https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki > > Proposal text: > > BIP: segsignal > Layer: Consensus (soft fork) > Title: Reduced signalling threshold activation of existing segwit deployment > Author: James Hilliard > Status: Draft > Type: Standards Track > Created: 2017-05-22 > License: BSD-3-Clause > CC0-1.0 > > > ==Abstract== > > This document specifies a method to activate the existing BIP9 segwit > deployment with a majority hashpower less than 95%. > > ==Definitions== > > "existing segwit deployment" refer to the BIP9 "segwit" deployment > using bit 1, between November 15th 2016 and November 15th 2017 to > activate BIP141, BIP143 and BIP147. > > ==Motivation== > > Segwit increases the blocksize, fixes transaction malleability, and > makes scripting easier to upgrade as well as bringing many other > [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits]. > > This BIP provides a way for a simple majority of miners to coordinate > activation of the existing segwit deployment with less than 95% > hashpower. For a number of reasons a complete redeployment of segwit > is difficulty to do until the existing deployment expires. This is due > to 0.13.1+ having many segwit related features active already, > including all the P2P components, the new network service flag, the > witness-tx and block messages, compact blocks v2 and preferential > peering. A redeployment of segw
Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
I think there may be merit to this idea, allowing for political compromise
without sacrificing the technological integrity of Bitcoin. There are a few
mechanical problems I see with it, though.
1. It should change its activation logic from BIP9-style to BIP8-style with a
flagday of August 1. This to maintain backwards compatibility with the current
deployment of BIP148 nodes. This proposal seems to be a measure to prevent a
chainsplit, so it must make sure to avoid triggering one.
2. This should be for miners only; non-miners should not enforce this. It
severely weakens the block-signalling activation mechanism in several ways
(lowered threshold, short deployment timeframe, no "locked in" delay before
activation) and by doing so opens up attack vectors for consensus-partitioning
attacks using malicious false signalling. For non-miners that seek to take
their fate into their own hands, enforcing BIP148 is enough.
3. Even for miners this is more risky than usual; only 31% of hashrate is
required to false-signal the activation to fork-off honest miners. This attack
vector is magnified by the lack of "locked in" delay that would allow laggards
to upgrade before activation. I suggest adding in at least a 1-week lock-in
period (given the shorter timeframes 2 weeks may eat up too much of the
available voting time before the brick wall of BIP148 activation on August 1).
Under the assumption that this is indeed compatible with the terms of the
Silbert agreement, we can presume the involved miners are willing to trust
eachother more than usual so such a short lock-in period should be acceptable.
Original Message ----
Subject: [bitcoin-dev] Reduced signalling threshold activation of existing
segwit deployment
Local Time: May 23, 2017 1:40 AM
UTC Time: May 22, 2017 10:40 PM
From: bitcoin-dev@lists.linuxfoundation.org
To: Bitcoin Dev
I would like to propose an implementation that accomplishes the first
part of the Barry Silbert proposal independently from the second:
"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
in a way that
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.
By activating segwit immediately and separately from any HF we can
scale quickly without risking a rushed combined segwit+HF that would
almost certainly cause widespread issues.
Draft proposal:
https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
Proposal text:
BIP: segsignal
Layer: Consensus (soft fork)
Title: Reduced signalling threshold activation of existing segwit deployment
Author: James Hilliard
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-3-Clause
CC0-1.0
==Abstract==
This document specifies a method to activate the existing BIP9 segwit
deployment with a majority hashpower less than 95%.
==Definitions==
"existing segwit deployment" refer to the BIP9 "segwit" deployment
using bit 1, between November 15th 2016 and November 15th 2017 to
activate BIP141, BIP143 and BIP147.
==Motivation==
Segwit increases the blocksize, fixes transaction malleability, and
makes scripting easier to upgrade as well as bringing many other
[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
This BIP provides a way for a simple majority of miners to coordinate
activation of the existing segwit deployment with less than 95%
hashpower. For a number of reasons a complete redeployment of segwit
is difficulty to do until the existing deployment expires. This is due
to 0.13.1+ having many segwit related features active already,
including all the P2P components, the new network service flag, the
witness-tx and block messages, compact blocks v2 and preferential
peering. A redeployment of segwit will need to redefine all these
things and doing so before expiry would greatly complicate testing.
==Specification==
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.
==Deployment==
This BIP will be deployed by a "version bits" with an 80%(this can be
adjusted if desired) activation threshold BIP9 with the name
"segsignal" and using bit 4.
This BIP will have 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.
=== Reference implementation ===
// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
Consensus::Params& params)
{
LOCK(cs_main);
return (VersionBitsState(pindexPrev, params,
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
THRESHOLD_LOCKED_IN);
Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
Seems like it would work fine. But why would we expect 80pct to signal for
the exact same implementation - when we can't get 40pct.
It will be contingent on some HF code that allows him to continue using
asicboost, or is too aggressive, or some other unreasonable request.
On May 22, 2017 6:43 PM, "Matt Corallo via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Given the overwhelming support for SegWit across the ecosystem of
businesses and users, this seems reasonable to me.
On May 22, 2017 6:40:13 PM EDT, James Hilliard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>I would like to propose an implementation that accomplishes the first
>part of the Barry Silbert proposal independently from the second:
>
>"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
>in a way that
>
>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.
>
>By activating segwit immediately and separately from any HF we can
>scale quickly without risking a rushed combined segwit+HF that would
>almost certainly cause widespread issues.
>
>Draft proposal:
>https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.
mediawiki
>
>Proposal text:
>
> BIP: segsignal
> Layer: Consensus (soft fork)
>Title: Reduced signalling threshold activation of existing segwit
>deployment
> Author: James Hilliard
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
>
>
>==Abstract==
>
>This document specifies a method to activate the existing BIP9 segwit
>deployment with a majority hashpower less than 95%.
>
>==Definitions==
>
>"existing segwit deployment" refer to the BIP9 "segwit" deployment
>using bit 1, between November 15th 2016 and November 15th 2017 to
>activate BIP141, BIP143 and BIP147.
>
>==Motivation==
>
>Segwit increases the blocksize, fixes transaction malleability, and
>makes scripting easier to upgrade as well as bringing many other
>[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>
>This BIP provides a way for a simple majority of miners to coordinate
>activation of the existing segwit deployment with less than 95%
>hashpower. For a number of reasons a complete redeployment of segwit
>is difficulty to do until the existing deployment expires. This is due
>to 0.13.1+ having many segwit related features active already,
>including all the P2P components, the new network service flag, the
>witness-tx and block messages, compact blocks v2 and preferential
>peering. A redeployment of segwit will need to redefine all these
>things and doing so before expiry would greatly complicate testing.
>
>==Specification==
>
>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.
>
>==Deployment==
>
>This BIP will be deployed by a "version bits" with an 80%(this can be
>adjusted if desired) activation threshold BIP9 with the name
>"segsignal" and using bit 4.
>
>This BIP will have 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.
>
>=== Reference implementation ===
>
>
>// Check if Segregated Witness is Locked In
>bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>Consensus::Params& params)
>{
>LOCK(cs_main);
>return (VersionBitsState(pindexPrev, params,
>Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>THRESHOLD_LOCKED_IN);
>}
>
>// SEGSIGNAL mandatory segwit signalling.
>if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
>&&
> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>// Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>and is not active.
>{
>bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>VERSIONBITS_TOP_BITS;
>bool fSegbit = (pindex->nVersion &
>VersionBitsMask(chainparams.GetConsensus(),
>Consensus::DEPLOYMENT_SEGWIT)) != 0;
>if (!(fVersionBits && fSegbit)) {
>return state.DoS(0, error("ConnectBlock(): relayed block must
>signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>}
>}
>
>
>https://github.com/bitcoin/bitcoin/compare/0.14...
jameshilliard:segsignal-v0.14.1
>
>==Backwards Compatibility==
>
>This deployment is compatible with the existing "segwit" bit 1
>deployment scheduled between midnight November 15th, 2016 and midnight
>November 15th, 2017. Miners will need to upgrade their nodes to
>support segsignal otherwise they may build on top of an invalid block.
>While this bip is active users should either upgrade to seg
Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
Given the overwhelming support for SegWit across the ecosystem of businesses
and users, this seems reasonable to me.
On May 22, 2017 6:40:13 PM EDT, James Hilliard via bitcoin-dev
wrote:
>I would like to propose an implementation that accomplishes the first
>part of the Barry Silbert proposal independently from the second:
>
>"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
>in a way that
>
>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.
>
>By activating segwit immediately and separately from any HF we can
>scale quickly without risking a rushed combined segwit+HF that would
>almost certainly cause widespread issues.
>
>Draft proposal:
>https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>
>Proposal text:
>
> BIP: segsignal
> Layer: Consensus (soft fork)
>Title: Reduced signalling threshold activation of existing segwit
>deployment
> Author: James Hilliard
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
>
>
>==Abstract==
>
>This document specifies a method to activate the existing BIP9 segwit
>deployment with a majority hashpower less than 95%.
>
>==Definitions==
>
>"existing segwit deployment" refer to the BIP9 "segwit" deployment
>using bit 1, between November 15th 2016 and November 15th 2017 to
>activate BIP141, BIP143 and BIP147.
>
>==Motivation==
>
>Segwit increases the blocksize, fixes transaction malleability, and
>makes scripting easier to upgrade as well as bringing many other
>[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>
>This BIP provides a way for a simple majority of miners to coordinate
>activation of the existing segwit deployment with less than 95%
>hashpower. For a number of reasons a complete redeployment of segwit
>is difficulty to do until the existing deployment expires. This is due
>to 0.13.1+ having many segwit related features active already,
>including all the P2P components, the new network service flag, the
>witness-tx and block messages, compact blocks v2 and preferential
>peering. A redeployment of segwit will need to redefine all these
>things and doing so before expiry would greatly complicate testing.
>
>==Specification==
>
>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.
>
>==Deployment==
>
>This BIP will be deployed by a "version bits" with an 80%(this can be
>adjusted if desired) activation threshold BIP9 with the name
>"segsignal" and using bit 4.
>
>This BIP will have 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.
>
>=== Reference implementation ===
>
>
>// Check if Segregated Witness is Locked In
>bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>Consensus::Params& params)
>{
>LOCK(cs_main);
>return (VersionBitsState(pindexPrev, params,
>Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>THRESHOLD_LOCKED_IN);
>}
>
>// SEGSIGNAL mandatory segwit signalling.
>if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
>&&
> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>// Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>and is not active.
>{
>bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>VERSIONBITS_TOP_BITS;
>bool fSegbit = (pindex->nVersion &
>VersionBitsMask(chainparams.GetConsensus(),
>Consensus::DEPLOYMENT_SEGWIT)) != 0;
>if (!(fVersionBits && fSegbit)) {
>return state.DoS(0, error("ConnectBlock(): relayed block must
>signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>}
>}
>
>
>https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1
>
>==Backwards Compatibility==
>
>This deployment is compatible with the existing "segwit" bit 1
>deployment scheduled between midnight November 15th, 2016 and midnight
>November 15th, 2017. Miners will need to upgrade their nodes to
>support segsignal otherwise they may build on top of an invalid block.
>While this bip is active users should either upgrade to segsignal or
>wait for additional confirmations when accepting payments.
>
>==Rationale==
>
>Historically we have used IsSuperMajority() to activate soft forks
>such as BIP66 which has a mandatory signalling requirement for miners
>once activated, this ensures that miners are aware of new rules being
>enforced. This technique can be leveraged to lower the signalling
>threshold of a soft fork while it is in the process of bei
[bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
I would like to propose an implementation that accomplishes the first
part of the Barry Silbert proposal independently from the second:
"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
in a way that
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.
By activating segwit immediately and separately from any HF we can
scale quickly without risking a rushed combined segwit+HF that would
almost certainly cause widespread issues.
Draft proposal:
https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
Proposal text:
BIP: segsignal
Layer: Consensus (soft fork)
Title: Reduced signalling threshold activation of existing segwit deployment
Author: James Hilliard
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-3-Clause
CC0-1.0
==Abstract==
This document specifies a method to activate the existing BIP9 segwit
deployment with a majority hashpower less than 95%.
==Definitions==
"existing segwit deployment" refer to the BIP9 "segwit" deployment
using bit 1, between November 15th 2016 and November 15th 2017 to
activate BIP141, BIP143 and BIP147.
==Motivation==
Segwit increases the blocksize, fixes transaction malleability, and
makes scripting easier to upgrade as well as bringing many other
[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
This BIP provides a way for a simple majority of miners to coordinate
activation of the existing segwit deployment with less than 95%
hashpower. For a number of reasons a complete redeployment of segwit
is difficulty to do until the existing deployment expires. This is due
to 0.13.1+ having many segwit related features active already,
including all the P2P components, the new network service flag, the
witness-tx and block messages, compact blocks v2 and preferential
peering. A redeployment of segwit will need to redefine all these
things and doing so before expiry would greatly complicate testing.
==Specification==
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.
==Deployment==
This BIP will be deployed by a "version bits" with an 80%(this can be
adjusted if desired) activation threshold BIP9 with the name
"segsignal" and using bit 4.
This BIP will have 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.
=== Reference implementation ===
// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
Consensus::Params& params)
{
LOCK(cs_main);
return (VersionBitsState(pindexPrev, params,
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
THRESHOLD_LOCKED_IN);
}
// SEGSIGNAL mandatory segwit signalling.
if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
&&
!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
// Segwit is not locked in
!IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
and is not active.
{
bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
VERSIONBITS_TOP_BITS;
bool fSegbit = (pindex->nVersion &
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) != 0;
if (!(fVersionBits && fSegbit)) {
return state.DoS(0, error("ConnectBlock(): relayed block must
signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
}
}
https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1
==Backwards Compatibility==
This deployment is compatible with the existing "segwit" bit 1
deployment scheduled between midnight November 15th, 2016 and midnight
November 15th, 2017. Miners will need to upgrade their nodes to
support segsignal otherwise they may build on top of an invalid block.
While this bip is active users should either upgrade to segsignal or
wait for additional confirmations when accepting payments.
==Rationale==
Historically we have used IsSuperMajority() to activate soft forks
such as BIP66 which has a mandatory signalling requirement for miners
once activated, this ensures that miners are aware of new rules being
enforced. This technique can be leveraged to lower the signalling
threshold of a soft fork while it is in the process of being deployed
in a backwards compatible way.
By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
deployment, this BIP can cause the existing "segwit" deployment to
activate without needing to release a new deployment.
==References==
*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/
