[bitcoin-dev] Flag day activation of segwit

[bitcoin-dev] Flag day activation of segwit

[shaolinfry]

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

I recently posted about so called "user activated soft forks" and received a lot of feedback. Much of this was how such methodologies could be applied to segwit which appears to have fallen under the miner veto category I explained in my original proposal, where there is apparently a lot of support for the proposal from the economy, but a few mining pools are vetoing the activation.

It turns out Bitcoin already used flag day activation for P2SH[[1](https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283)], a soft fork which is remarkably similar to segwit. The disadvantage of a UASF for segwit is there is an existing deployment. A UASF would require another wide upgrade cycle (from what I can see, around 80% of existing nodes have upgraded from pre-witness, to NODE_WITNESS capability[[2](http://luke.dashjr.org/programs/bitcoin/files/charts/services.html)][[3](https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/)]. While absolute node count is meaningless, the uprgrade trend from version to version seems significant.

Also it is quite clear a substantial portion of the ecosystem industry has put in time and resources into segwit adoption, in the form of upgrading wallet code, updating libraries and various other integration work that requires significant time and money. Further more, others have built systems that rely on segwit, having put significant engineering resources into developing systems that require segwit - such as several lightning network system. This is much more significant social proof than running a node.

The delayed activation of segwit is also holding back a raft protocol of innovations such as MAST, Covenants, Schnorr signature schemes and signature aggregation and other script innovations of which, much of the development work is already done.

A better option would be to release code that causes the existing segwit deployment to activate without requiring a completely new deployment nor subject to hash power veto. This could be achieved if the economic majority agree to run code that rejects non-signalling segwit blocks. Then from the perspective of all existing witness nodes, miners trigger the BIP9 activation. Such a rule could come into effect 4-6 weeks before the BIP9 timeout. If a large part of the economic majority publicly say that they will adopt this new client, miners will have to signal bip9 segwit activation in order for their blocks to be valid.

I have drafted a BIP proposal so the community may discuss https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full text below).

References:
[1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
[2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html
[3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/

Proposal text:

<pre> BIP: bip-segwit-flagday Title: Flag day activation for segwit deployment Author: Shaolin Fry <shaolinfry@protonmail.ch> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???? Status: Draft Type: Informational Created: 2017-03-12 License: BSD-3-Clause CC0-1.0 </pre> ==Abstract== This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit". ==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== Cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017. ==Specification== All times are specified according to median past time. This BIP will be activate between midnight October 1st 2017 (epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not activated before epoch time 1538352000. This BIP will cease to be active when the existing segwit deployment activates. 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. === Reference implementation === <pre> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclusive if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) { if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYMENT_SEGWIT)) != 0) { return state.DoS(2, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit"); } } </pre> ==Backwards Compatibility== This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017. ==Rationale== Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues By orphaning non-signalling blocks during the last month of 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://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation]. ==Copyright== This document is placed in the public domain.

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

Re: [bitcoin-dev] Flag day activation of segwit

[David Vorick]

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

It has taken almost 6 months for SegWit adoption to get to where it is
today. I don't think it will take that long to reach similar adoption for
UASF SegWit, but conservatively we want to give it at least that much time.

It's really important to stress here that a UASF will split and become the
minority chain if a majority of the transaction accepting nodes on the
network do not agree to strictly follow the UASF and outright reject blocks
that do not signal for SegWit at the designated date.

Before setting a flag day, I think we should get written cooperation
agreements from the largest economic players in Bitcoin. This would include:

Bitfinex
Bitflyer
BitGo
BitPay
Bitstamp
Blockchain.info
Blockcypher
Coinbase
Huobi
Kraken
Gemeni
OkCoin
Poloniex

(feel free to discuss this list)

100% cooperation is not necessary, but close to 100% cooperation is
strongly desired. It should be noted that their cooperation is only
required because they are sufficiently powerful to threaten the success of
a UASF, particularly because many of these entities hold users bitcoins.

Once a convincing majority is on-board, I suggest we release a UASF patch
that activates a full year after release. This is because a UASF is a big
gamble that requires a large majority of the economy has upgraded.

Though that is a very long time, SegWit can always be activated early with
miner cooperation.

------

As an extra note, if the UASF triggers with majority economy support and
the miners resist, a minority block reward chain may be the longest chain
for a while. However, when the majority block reward chain does catch up,
the minority reward chain will be entirely obliterated, eliminating all
block rewards, all transaction history, and making a ton of money vanish
all at once.

This makes it very dangerous for an exchange, payment processor, online
wallet, or miner to oppose the UASF if there is significant momentum behind
it. This gives the UASF a powerful snowball effect once a few major parties
(or the majority of tiny full nodes) have decided to commit to the UASF.

On the other hand, failure means a permanent coin split, so it is still
necessary to exercise caution that exceeds the caution of a normal soft
fork.

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

Re: [bitcoin-dev] Flag day activation of segwit

[shaolinfry]

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

Before setting a flag day, I think we should get written cooperation agreements from the largest economic players in Bitcoin. This would include:

There isn't a flag day to set. If the major economic organs like exchanges run the BIP, non-signalling miners simply wont get paid (starting October 1st) and their blocks will be rejected. Miners will have the choice to signal, or find something else profitable to mine. In turn, this will trigger the existing segwit deployment for everyone who has already upgraded to segwit compatible node software (currently Bitcoin Core 0.13.1, 0.13.2, 0.14.0, Bitcoin Knots 0.13.1+, and bcoin) regardless of whether they run this BIP or not.

But yes, it goes without saying that this BIP would need to have buy-in from major economic organs, especially fiat egress points, before being deployed. Failing that, a second deployment of segwit with a flag day, or preferably using the bip-uaversionbits-strong BIP9/flagday hybrid would be required.

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

Re: [bitcoin-dev] Flag day activation of segwit

[Luke Dashjr]

On Sunday, March 12, 2017 3:50:27 PM shaolinfry via bitcoin-dev wrote:
> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017
> inclusive if (pindex->GetMedianTimePast() >= 1538352000 &&
> pindex->GetMedianTimePast() <= 1510704000 &&
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
>     if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>     VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params,
>     Consensus::DEPLOYMENT_SEGWIT)) != 0) {
>         return state.DoS(2, error("ConnectBlock(): relayed block must
>         signal for segwit, please upgrade"), REJECT_INVALID,
>         "bad-no-segwit");
>     }
> }

I don't think this is actually BIP 9 compatible. Once activated, the bit loses 
its meaning and should not be set. So you need to check that it hasn't locked-
in already...

Also, IMO this should tolerate as many as 5% minus one non-signalling blocks.

Disclaimer: This are technical suggestions, and do not imply endorsement of 
the idea.

Luke

Re: [bitcoin-dev] Flag day activation of segwit

[Nick ODell]

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

The problem with modifying Bitcoin to work around community norms is that
it's a two-way street. Other people can do it too.

Let me propose a counter-fork, or a "Double UASF." This is also a BIP9
fork, and it uses, say, bit 2. starttime is 1489449600, and the end time is
1506812400. It enforces every rule that UASF enforces, plus one additional
rule. If 60% of blocks in any retargeting period signal for Double UASF,
any descendant block that creates or spends a segregated witness output is
invalid.

Double UASF signaling never coincides with UASF signaling, because the
signaling periods don't overlap. Full nodes happily validate the chain,
because Double UASF doesn't break any rules; it just adds new ones. Miners
who adopt Double UASF don't need to understand segwit, because all segwit
transactions are banned. Miners don't need to commit to a wtxid structure,
either. Per BIP 141, "If all transactions in a block do not have witness
data, the commitment is optional." Segwit is activated, but useless. Miners
who *do* adopt segwit will lose money, as their blocks are orphaned.

Thanks,
--Nick

On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I recently posted about so called "user activated soft forks" and received
> a lot of feedback. Much of this was how such methodologies could be applied
> to segwit which appears to have fallen under the miner veto category I
> explained in my original proposal, where there is apparently a lot of
> support for the proposal from the economy, but a few mining pools are
> vetoing the activation.
>
> It turns out Bitcoin already used flag day activation for P2SH[1
> <https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283>],
> a soft fork which is remarkably similar to segwit. The disadvantage of a
> UASF for segwit is there is an existing deployment. A UASF would require
> another wide upgrade cycle (from what I can see, around 80% of existing
> nodes have upgraded from pre-witness, to NODE_WITNESS capability[2
> <http://luke.dashjr.org/programs/bitcoin/files/charts/services.html>][3
> <https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/>].
> While absolute node count is meaningless, the uprgrade trend from version
> to version seems significant.
>
> Also it is quite clear a substantial portion of the ecosystem industry has
> put in time and resources into segwit adoption, in the form of upgrading
> wallet code, updating libraries and various other integration work that
> requires significant time and money. Further more, others have built
> systems that rely on segwit, having put significant engineering resources
> into developing systems that require segwit - such as several lightning
> network system. This is much more significant social proof than running a
> node.
>
> The delayed activation of segwit is also holding back a raft protocol of
> innovations such as MAST, Covenants, Schnorr signature schemes and
> signature aggregation and other script innovations of which, much of the
> development work is already done.
>
> A better option would be to release code that causes the existing segwit
> deployment to activate without requiring a completely new deployment nor
> subject to hash power veto. This could be achieved if the economic majority
> agree to run code that rejects non-signalling segwit blocks. Then from the
> perspective of all existing witness nodes, miners trigger the BIP9
> activation. Such a rule could come into effect 4-6 weeks before the BIP9
> timeout. If a large part of the economic majority publicly say that they
> will adopt this new client, miners will have to signal bip9 segwit
> activation in order for their blocks to be valid.
>
> I have drafted a BIP proposal so the community may discuss
> https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full
> text below).
>
> References:
> [1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/
> src/main.cpp#L1281-L1283
> [2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html
> [3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/
> evidence_of_widespread_segwit_support_near50_of/
>
> Proposal text:
>
> <pre>
>   BIP: bip-segwit-flagday
>   Title: Flag day activation for segwit deployment
>   Author: Shaolin Fry <shaolinfry@protonmail.ch>
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
>   Status: Draft
>   Type: Informational
>   Created: 2017-03-12
>   License: BSD-3-Clause
>            CC0-1.0
> </pre>
>
> ==Abstract==
>
> This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit".
>
> ==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==
>
> Cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017.
>
> ==Specification==
>
> All times are specified according to median past time.
>
> This BIP will be activate between midnight October 1st 2017 (epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not activated before epoch time 1538352000. This BIP will cease to be active when the existing segwit deployment activates.
>
> 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.
>
> === Reference implementation ===
>
> <pre>
> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclusive
> if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
>     if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYMENT_SEGWIT)) != 0) {
>         return state.DoS(2, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>     }
> }
> </pre>
>
> ==Backwards Compatibility==
>
> This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017.
>
> ==Rationale==
>
> Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues
>
> By orphaning non-signalling blocks during the last month of 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://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation].
>
> ==Copyright==
>
> This document is placed in the public domain.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

Re: [bitcoin-dev] Flag day activation of segwit

[David Vorick]

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

That's simply a 51% attack choosing to censor transactions. We could do
that today, ban all transactions that aren't approved by the PBoC.

You respond to that with a PoW hardfork, or by finding some way to prop up
/ subsidize non-censorship miners.

On Mar 13, 2017 5:59 AM, "Nick ODell via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The problem with modifying Bitcoin to work around community norms is that
> it's a two-way street. Other people can do it too.
>
> Let me propose a counter-fork, or a "Double UASF." This is also a BIP9
> fork, and it uses, say, bit 2. starttime is 1489449600, and the end time is
> 1506812400. It enforces every rule that UASF enforces, plus one additional
> rule. If 60% of blocks in any retargeting period signal for Double UASF,
> any descendant block that creates or spends a segregated witness output is
> invalid.
>
> Double UASF signaling never coincides with UASF signaling, because the
> signaling periods don't overlap. Full nodes happily validate the chain,
> because Double UASF doesn't break any rules; it just adds new ones. Miners
> who adopt Double UASF don't need to understand segwit, because all segwit
> transactions are banned. Miners don't need to commit to a wtxid structure,
> either. Per BIP 141, "If all transactions in a block do not have witness
> data, the commitment is optional." Segwit is activated, but useless. Miners
> who *do* adopt segwit will lose money, as their blocks are orphaned.
>
> Thanks,
> --Nick
>
> On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I recently posted about so called "user activated soft forks" and
>> received a lot of feedback. Much of this was how such methodologies could
>> be applied to segwit which appears to have fallen under the miner veto
>> category I explained in my original proposal, where there is apparently a
>> lot of support for the proposal from the economy, but a few mining pools
>> are vetoing the activation.
>>
>> It turns out Bitcoin already used flag day activation for P2SH[1
>> <https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283>],
>> a soft fork which is remarkably similar to segwit. The disadvantage of a
>> UASF for segwit is there is an existing deployment. A UASF would require
>> another wide upgrade cycle (from what I can see, around 80% of existing
>> nodes have upgraded from pre-witness, to NODE_WITNESS capability[2
>> <http://luke.dashjr.org/programs/bitcoin/files/charts/services.html>][3
>> <https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/>].
>> While absolute node count is meaningless, the uprgrade trend from version
>> to version seems significant.
>>
>> Also it is quite clear a substantial portion of the ecosystem industry
>> has put in time and resources into segwit adoption, in the form of
>> upgrading wallet code, updating libraries and various other integration
>> work that requires significant time and money. Further more, others have
>> built systems that rely on segwit, having put significant engineering
>> resources into developing systems that require segwit - such as several
>> lightning network system. This is much more significant social proof than
>> running a node.
>>
>> The delayed activation of segwit is also holding back a raft protocol of
>> innovations such as MAST, Covenants, Schnorr signature schemes and
>> signature aggregation and other script innovations of which, much of the
>> development work is already done.
>>
>> A better option would be to release code that causes the existing segwit
>> deployment to activate without requiring a completely new deployment nor
>> subject to hash power veto. This could be achieved if the economic majority
>> agree to run code that rejects non-signalling segwit blocks. Then from the
>> perspective of all existing witness nodes, miners trigger the BIP9
>> activation. Such a rule could come into effect 4-6 weeks before the BIP9
>> timeout. If a large part of the economic majority publicly say that they
>> will adopt this new client, miners will have to signal bip9 segwit
>> activation in order for their blocks to be valid.
>>
>> I have drafted a BIP proposal so the community may discuss
>> https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full
>> text below).
>>
>> References:
>> [1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/
>> main.cpp#L1281-L1283
>> [2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html
>> [3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/eviden
>> ce_of_widespread_segwit_support_near50_of/
>>
>> Proposal text:
>>
>> <pre>
>>   BIP: bip-segwit-flagday
>>   Title: Flag day activation for segwit deployment
>>   Author: Shaolin Fry <shaolinfry@protonmail.ch>
>>   Comments-Summary: No comments yet.
>>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
>>   Status: Draft
>>   Type: Informational
>>   Created: 2017-03-12
>>   License: BSD-3-Clause
>>            CC0-1.0
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit".
>>
>> ==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==
>>
>> Cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017.
>>
>> ==Specification==
>>
>> All times are specified according to median past time.
>>
>> This BIP will be activate between midnight October 1st 2017 (epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not activated before epoch time 1538352000. This BIP will cease to be active when the existing segwit deployment activates.
>>
>> 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.
>>
>> === Reference implementation ===
>>
>> <pre>
>> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclusive
>> if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
>>     if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYMENT_SEGWIT)) != 0) {
>>         return state.DoS(2, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>>     }
>> }
>> </pre>
>>
>> ==Backwards Compatibility==
>>
>> This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017.
>>
>> ==Rationale==
>>
>> Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues
>>
>> By orphaning non-signalling blocks during the last month of 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://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation].
>>
>> ==Copyright==
>>
>> This document is placed in the public domain.
>>
>>
>>
>>
>> _______________________________________________
>> 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: 17779 bytes --]

Re: [bitcoin-dev] Flag day activation of segwit

[shaolinfry]

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

From: luke@dashjr.org
On Sunday, March 12, 2017 3:50:27 PM shaolinfry via bitcoin-dev wrote:
> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017
> inclusive if (pindex->GetMedianTimePast() >= 1538352000 &&
> pindex->GetMedianTimePast() <= 1510704000 &&
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
> if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params,
> Consensus::DEPLOYMENT_SEGWIT)) != 0) {
> return state.DoS(2, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID,
> "bad-no-segwit");
> }
> }

I don't think this is actually BIP 9 compatible. Once activated, the bit loses
its meaning and should not be set. So you need to check that it hasn't locked-
in already...

I believe that is handled.

time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()

Signalling is only required from October 1st until the BIP9 timeout, or, until segwit is activated. The bit becomes free after activation/timeout as per BIP9. Also, the default behaviour of BIP9 in Bitcoin Core is to signal through the LOCKED_IN period - it would be trivial to add a condition to not require mandatory signalling during LOCKED_IN but since miners signal by default during this period, I figured I would leave it.

I thought about 5% tolerance. but I don't think it makes sense since miners will already have plenty of warning this is coming up and the intent of the mandatory signalling period is quite clear. It also seems a bit weird to say "it's mandatory but not for 5%". If miners are required to signal, they need to signal. It also adds unnecessary complexity to an otherwise simple patch.

That said, I have no strong feelings either way on both counts, but I chose to present the simplest option first.

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

Re: [bitcoin-dev] Flag day activation of segwit

[shaolinfry]

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

Fundamentally, what you have described is not a UASF, it is a miner attack on other miners. 51% of hash power has always been able to collude to orphan blocks that contain transactions they have blacklisted (a censorship soft fork). This is clearly a miner attack which would escalate pretty rapidly into a PoW change if sustained for any time.

Miners have always retained the ability to include whatever valid transactions they like. If they don't like P2SH or segwit, they don't have to include them in their blocks. There is a clear difference between opting out of transaction selection vs miners attacking other miners to prevent their voluntary participation in mining valid transactions.

Of course, anything is possible, but game theory and incentives seem to suggest that any tantrums would be at most, short lived, if lived at all. Mining is an extraordinarily expensive endeavour, which is the basis of the strong assumption of Bitcoin that PoW/revenue incentives will keep miners honest. If that assumption is broken, Bitcoin has bigger problems.


-------- Original Message --------
Subject: Re: [bitcoin-dev] Flag day activation of segwit
From: nickodell



The problem with modifying Bitcoin to work around community norms is that it's a two-way street. Other people can do it too.

Let me propose a counter-fork, or a "Double UASF." This is also a BIP9 fork, and it uses, say, bit 2. starttime is 1489449600, and the end time is 1506812400. It enforces every rule that UASF enforces, plus one additional rule. If 60% of blocks in any retargeting period signal for Double UASF, any descendant block that creates or spends a segregated witness output is invalid.

Double UASF signaling never coincides with UASF signaling, because the signaling periods don't overlap. Full nodes happily validate the chain, because Double UASF doesn't break any rules; it just adds new ones. Miners who adopt Double UASF don't need to understand segwit, because all segwit transactions are banned. Miners don't need to commit to a wtxid structure, either. Per BIP 141, "If all transactions in a block do not have witness data, the commitment is optional." Segwit is activated, but useless. Miners who *do* adopt segwit will lose money, as their blocks are orphaned.

Thanks,
--Nick



On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

I recently posted about so called "user activated soft forks" and received a lot of feedback. Much of this was how such methodologies could be applied to segwit which appears to have fallen under the miner veto category I explained in my original proposal, where there is apparently a lot of support for the proposal from the economy, but a few mining pools are vetoing the activation.

It turns out Bitcoin already used flag day activation for P2SH[[1](https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283)], a soft fork which is remarkably similar to segwit. The disadvantage of a UASF for segwit is there is an existing deployment. A UASF would require another wide upgrade cycle (from what I can see, around 80% of existing nodes have upgraded from pre-witness, to NODE_WITNESS capability[[2](http://luke.dashjr.org/programs/bitcoin/files/charts/services.html)][[3](https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/)]. While absolute node count is meaningless, the uprgrade trend from version to version seems significant.

Also it is quite clear a substantial portion of the ecosystem industry has put in time and resources into segwit adoption, in the form of upgrading wallet code, updating libraries and various other integration work that requires significant time and money. Further more, others have built systems that rely on segwit, having put significant engineering resources into developing systems that require segwit - such as several lightning network system. This is much more significant social proof than running a node.

The delayed activation of segwit is also holding back a raft protocol of innovations such as MAST, Covenants, Schnorr signature schemes and signature aggregation and other script innovations of which, much of the development work is already done.

A better option would be to release code that causes the existing segwit deployment to activate without requiring a completely new deployment nor subject to hash power veto. This could be achieved if the economic majority agree to run code that rejects non-signalling segwit blocks. Then from the perspective of all existing witness nodes, miners trigger the BIP9 activation. Such a rule could come into effect 4-6 weeks before the BIP9 timeout. If a large part of the economic majority publicly say that they will adopt this new client, miners will have to signal bip9 segwit activation in order for their blocks to be valid.

I have drafted a BIP proposal so the community may discuss https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full text below).

References:
[1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
[2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html
[3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/

Proposal text:

<pre> BIP: bip-segwit-flagday Title: Flag day activation for segwit deployment Author: Shaolin Fry <shaolinfry@protonmail.ch> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???? Status: Draft Type: Informational Created: 2017-03-12 License: BSD-3-Clause CC0-1.0 </pre> ==Abstract== This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit". ==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== Cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017. ==Specification== All times are specified according to median past time. This BIP will be activate between midnight October 1st 2017 (epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not activated before epoch time 1538352000. This BIP will cease to be active when the existing segwit deployment activates. 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. === Reference implementation === <pre> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclusive if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) { if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYMENT_SEGWIT)) != 0) { return state.DoS(2, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit"); } } </pre> ==Backwards Compatibility== This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017. ==Rationale== Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues By orphaning non-signalling blocks during the last month of 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://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation]. ==Copyright== This document is placed in the public domain.




_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] Flag day activation of segwit

[Nick ODell]

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

>time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()
This has a different start time from the first post.
>if (pindex->GetMedianTimePast() >= 1538352000 &&
pindex->GetMedianTimePast() <= 1510704000 ...

Thanks,
--Nick

On Mon, Mar 13, 2017 at 4:36 AM, shaolinfry via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> From: luke@dashjr.org
> On Sunday, March 12, 2017 3:50:27 PM shaolinfry via bitcoin-dev wrote:
> > // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017
> > inclusive if (pindex->GetMedianTimePast() >= 1538352000 &&
> > pindex->GetMedianTimePast() <= 1510704000 &&
> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
> > if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> > VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params,
> > Consensus::DEPLOYMENT_SEGWIT)) != 0) {
> > return state.DoS(2, error("ConnectBlock(): relayed block must
> > signal for segwit, please upgrade"), REJECT_INVALID,
> > "bad-no-segwit");
> > }
> > }
>
> I don't think this is actually BIP 9 compatible. Once activated, the bit
> loses
> its meaning and should not be set. So you need to check that it hasn't
> locked-
> in already...
>
>
> I believe that is handled.
>
> time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()
>
> Signalling is only required from October 1st until the BIP9 timeout, or,
> until segwit is activated. The bit becomes free after activation/timeout as
> per BIP9. Also, the default behaviour of BIP9 in Bitcoin Core is to signal
> through the LOCKED_IN period - it would be trivial to add a condition to
> not require mandatory signalling during LOCKED_IN but since miners signal
> by default during this period, I figured I would leave it.
>
> I thought about 5% tolerance. but I don't think it makes sense since
> miners will already have plenty of warning this is coming up and the intent
> of the mandatory signalling period is quite clear. It also seems a bit
> weird to say "it's mandatory but not for 5%". If miners are required to
> signal, they need to signal. It also adds unnecessary complexity to an
> otherwise simple patch.
>
> That said, I have no strong feelings either way on both counts, but I
> chose to present the simplest option first.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

Re: [bitcoin-dev] Flag day activation of segwit

[praxeology_guy]

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

"Activation of segwit is defined by BIP9. After 15 Nov 2016 and before 15 Nov 2017 UTC, if in a full retarget cycle at least 1916 out of 2016 blocks is signaling readiness, segwit will be activated in the retarget cycle after the next one"

Just change BIP9 and the code to say "if in a full retarget cycle at least 1 out of 2016 blocks" and call it done. Or something very similar to this that effectively does the exact same thing. :) Wasting too much time on this. 15 Nov 2017 is plenty of time to be ready for SegWit, and if a participant is not ready by then they are either unreasonably lazy, a manipulator, or manipluted, and we don't need them.

If non-upgrading miners refuse to build on segwit blocks, or build on malicious invalid segwit blocks, then so be it. We fork. We have spent enough time trying to convince people who don't think for themselves... if they are still manipulated now then its time for us to give up on helping them see the light and instead let them learn the hard way.

Cheers,
Praxeology Guy

-------- Original Message --------
Subject: Re: [bitcoin-dev] Flag day activation of segwit
Local Time: March 13, 2017 5:18 PM
UTC Time: March 13, 2017 10:18 PM
From: bitcoin-dev@lists.linuxfoundation.org
To: shaolinfry <shaolinfry@protonmail.ch>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>

>time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()
This has a different start time from the first post.
>if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 ...

Thanks,
--Nick

On Mon, Mar 13, 2017 at 4:36 AM, shaolinfry via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
From: luke@dashjr.org
On Sunday, March 12, 2017 3:50:27 PM shaolinfry via bitcoin-dev wrote:
> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017
> inclusive if (pindex->GetMedianTimePast() >= 1538352000 &&
> pindex->GetMedianTimePast() <= 1510704000 &&
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
> if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params,
> Consensus::DEPLOYMENT_SEGWIT)) != 0) {
> return state.DoS(2, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID,
> "bad-no-segwit");
> }
> }

I don't think this is actually BIP 9 compatible. Once activated, the bit loses
its meaning and should not be set. So you need to check that it hasn't locked-
in already...

I believe that is handled.

time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()

Signalling is only required from October 1st until the BIP9 timeout, or, until segwit is activated. The bit becomes free after activation/timeout as per BIP9. Also, the default behaviour of BIP9 in Bitcoin Core is to signal through the LOCKED_IN period - it would be trivial to add a condition to not require mandatory signalling during LOCKED_IN but since miners signal by default during this period, I figured I would leave it.

I thought about 5% tolerance. but I don't think it makes sense since miners will already have plenty of warning this is coming up and the intent of the mandatory signalling period is quite clear. It also seems a bit weird to say "it's mandatory but not for 5%". If miners are required to signal, they need to signal. It also adds unnecessary complexity to an otherwise simple patch.

That said, I have no strong feelings either way on both counts, but I chose to present the simplest option first.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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