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 <shaolin...@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
