Announcing a new standard for soft fork activation

Announcing a new standard for soft fork activation
2021-04-01 18:05 ` Ben Woosley
  2021-04-05 22:36 ` Erik Aronesty
  
From: Michael Folkson @ 2021-04-01 14:58 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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

There have been a vast number of proposals for soft fork activation in
recent months and it is important that all these important ideas don’t go
to waste. Hence I propose a new standard for soft fork activation
incorporating all the ideas into one standard. I appreciate this standard
has come too late for Taproot activation but it should be ready for any
future soft forks. It is a multi phase, multi year standard. No soft fork
can activate unless and until it has successfully passed through all of the
different 14 phases. This will demonstrate Bitcoin’s ultimate conservatism.

Phase 1) Let’s See What Happens - BIP 8 (false, 0.25 years). The shortest
phase just to whet appetites.

Phase 2) Start now, improve later - BIP 8(false, 1 year) A confusing name,
it starts but it doesn't improve later

Phase 3) BIP 9 equivalent - BIP 8(false, 1 year)

Phase 4) Gently discourage apathy - BIP 8(true, 1 year) Forced signaling at
the end of this phase but obviously there are still many phases before the
soft fork can actually activate.

Phase 5) BIP 91 (1 year). As a nod to our SegWit history we have a BIP 91
activation phase.

Phase 6) BIP 148 (1 year). Some people disagree that BIP 91 activated
SegWit so we do a BIP 148 activation phase to keep those people happy.
Again forced signaling doesn’t actually mean activation. There are still
many more phases to pass through.

Phase 7) Speedy Trial (using block height, 0.5 years) on mainnet

Phase 8) Speedy Trial (using MTP, 0.5 years) on mainnet

Phase 9) Speedy Trial on the default signet (0.5 years)

Phase 10) Speedy Trial on a combination of three different custom signets
in parallel (0.5 years)

Phase 11) Speedy Trial on testnet and a custom signet in parallel (0.5
years)

Phase 12) Modern Soft Fork Activation (3.5 years) This is the longest phase
of the soft fork activation standard. It is itself multi phase and multi
year so this can be considered a nested activation phase within this
standard.

Phase 13) UASF BIP 8 (LOT=true, 1 year). Forced miner signaling at the end
of this phase but ultimately the soft fork doesn’t yet activate as there is
one final additional phase the activation must pass through. This gives
Samson the opportunity to sell some hats. We are close now. The natives are
getting restless.

Phase 14) Second flag day (1 year) We don’t want those pesky users actually
activating a soft fork on their own so an additional flag day is added just
so we can tell users that we prevented a chain split.

Assuming a soft fork activation has successfully passed through all these
14 phases it should activate. It will take a minimum of 13 years. However,
if it fails during any one of these phases it has to start from Phase 1
again. We should take Bitcoin’s conservatism very seriously. If a soft fork
activation can’t pass successfully through all these phases it shouldn’t
activate. Ultimately we don’t really mind what is in the soft fork (any
idiot can design consensus changes and write secure bug free C++ code) that
is very much secondary in importance to *how* the soft fork is activated.
The activation design absolutely must be conservative.

I expect this rigorous standard for soft fork activation will get a BIP
number. If you are going to propose a future soft fork I recommend you plan
for activation in approximately 13 years from the point the soft fork code
is merged into Core.

I am happy to settle the soft fork activation question once and for all for
the community. I expect in time my contribution will be recognized in the
annals of history with Satoshi Nakamoto and Hal Finney.

Addendum: Although all future soft forks will ultimately use this standard,
this standard is copyrighted. Every time it is used royalties must be paid
into this quantum secure Bitcoin vanity address 1quantumsecureaddress


-- 
Michael Folkson
Email: michaelfolkson@gmail•com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

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

 permalink raw reply	[|nested]
2021-04-01 14:58 [bitcoin-dev] Announcing a new standard for soft fork activation Michael Folkson

  2021-04-05 22:36 ` Erik Aronesty
  
From: Ben Woosley @ 2021-04-01 18:05 UTC (permalink / raw)
  To: Michael Folkson, Bitcoin Protocol Discussion

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

Hear hear, a true work of genius. Who's looking for Satoshi? I think we've
found him!

On Thu, Apr 1, 2021 at 8:15 AM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> There have been a vast number of proposals for soft fork activation in
> recent months and it is important that all these important ideas don’t go
> to waste. Hence I propose a new standard for soft fork activation
> incorporating all the ideas into one standard. I appreciate this standard
> has come too late for Taproot activation but it should be ready for any
> future soft forks. It is a multi phase, multi year standard. No soft fork
> can activate unless and until it has successfully passed through all of the
> different 14 phases. This will demonstrate Bitcoin’s ultimate conservatism.
>
> Phase 1) Let’s See What Happens - BIP 8 (false, 0.25 years). The shortest
> phase just to whet appetites.
>
> Phase 2) Start now, improve later - BIP 8(false, 1 year) A confusing name,
> it starts but it doesn't improve later
>
> Phase 3) BIP 9 equivalent - BIP 8(false, 1 year)
>
> Phase 4) Gently discourage apathy - BIP 8(true, 1 year) Forced signaling
> at the end of this phase but obviously there are still many phases before
> the soft fork can actually activate.
>
> Phase 5) BIP 91 (1 year). As a nod to our SegWit history we have a BIP 91
> activation phase.
>
> Phase 6) BIP 148 (1 year). Some people disagree that BIP 91 activated
> SegWit so we do a BIP 148 activation phase to keep those people happy.
> Again forced signaling doesn’t actually mean activation. There are still
> many more phases to pass through.
>
> Phase 7) Speedy Trial (using block height, 0.5 years) on mainnet
>
> Phase 8) Speedy Trial (using MTP, 0.5 years) on mainnet
>
> Phase 9) Speedy Trial on the default signet (0.5 years)
>
> Phase 10) Speedy Trial on a combination of three different custom signets
> in parallel (0.5 years)
>
> Phase 11) Speedy Trial on testnet and a custom signet in parallel (0.5
> years)
>
> Phase 12) Modern Soft Fork Activation (3.5 years) This is the longest
> phase of the soft fork activation standard. It is itself multi phase and
> multi year so this can be considered a nested activation phase within this
> standard.
>
> Phase 13) UASF BIP 8 (LOT=true, 1 year). Forced miner signaling at the end
> of this phase but ultimately the soft fork doesn’t yet activate as there is
> one final additional phase the activation must pass through. This gives
> Samson the opportunity to sell some hats. We are close now. The natives are
> getting restless.
>
> Phase 14) Second flag day (1 year) We don’t want those pesky users
> actually activating a soft fork on their own so an additional flag day is
> added just so we can tell users that we prevented a chain split.
>
> Assuming a soft fork activation has successfully passed through all these
> 14 phases it should activate. It will take a minimum of 13 years. However,
> if it fails during any one of these phases it has to start from Phase 1
> again. We should take Bitcoin’s conservatism very seriously. If a soft fork
> activation can’t pass successfully through all these phases it shouldn’t
> activate. Ultimately we don’t really mind what is in the soft fork (any
> idiot can design consensus changes and write secure bug free C++ code) that
> is very much secondary in importance to *how* the soft fork is activated.
> The activation design absolutely must be conservative.
>
> I expect this rigorous standard for soft fork activation will get a BIP
> number. If you are going to propose a future soft fork I recommend you plan
> for activation in approximately 13 years from the point the soft fork code
> is merged into Core.
>
> I am happy to settle the soft fork activation question once and for all
> for the community. I expect in time my contribution will be recognized in
> the annals of history with Satoshi Nakamoto and Hal Finney.
>
> Addendum: Although all future soft forks will ultimately use this
> standard, this standard is copyrighted. Every time it is used royalties
> must be paid into this quantum secure Bitcoin vanity address
> 1quantumsecureaddress
>
>
> --
> Michael Folkson
> Email: michaelfolkson@gmail•com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

 permalink raw reply	[|nested]
2021-04-01 14:58 [bitcoin-dev] Announcing a new standard for soft fork activation Michael Folkson
  2021-04-01 18:05 ` Ben Woosley

  
From: Erik Aronesty @ 2021-04-05 22:36 UTC (permalink / raw)
  To: Michael Folkson, Bitcoin Protocol Discussion

this satire points out the "bikeshedding" problem, or the "law of triviality".
a problem is discussed in proportion to the number of people who feel
qualified to talk about them.
few users are experts at the cryptography, and even fewer are experts
at c++, cryptography and possibly game theory
therefore the number of people who feel qualified to analyze or
discuss the proposed changes are few  (schorr sigs are hopefully the
least controversial)
whereas the mechanism for activation is relatively easy to understand

schnorr:  improved signature scheme, can reduce tx size (ACK)
mast: reduces tx size and improve privacy of of complex contracts (ACK)
taproot: mast... but it looks like p2pkh (ACK)
activation:   bikeshedding not necessary now.

On Thu, Apr 1, 2021 at 11:15 AM Michael Folkson via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> There have been a vast number of proposals for soft fork activation in recent months and it is important that all these important ideas don’t go to waste. Hence I propose a new standard for soft fork activation incorporating all the ideas into one standard. I appreciate this standard has come too late for Taproot activation but it should be ready for any future soft forks. It is a multi phase, multi year standard. No soft fork can activate unless and until it has successfully passed through all of the different 14 phases. This will demonstrate Bitcoin’s ultimate conservatism.
>
> Phase 1) Let’s See What Happens - BIP 8 (false, 0.25 years). The shortest phase just to whet appetites.
>
> Phase 2) Start now, improve later - BIP 8(false, 1 year) A confusing name, it starts but it doesn't improve later
>
> Phase 3) BIP 9 equivalent - BIP 8(false, 1 year)
>
> Phase 4) Gently discourage apathy - BIP 8(true, 1 year) Forced signaling at the end of this phase but obviously there are still many phases before the soft fork can actually activate.
>
> Phase 5) BIP 91 (1 year). As a nod to our SegWit history we have a BIP 91 activation phase.
>
> Phase 6) BIP 148 (1 year). Some people disagree that BIP 91 activated SegWit so we do a BIP 148 activation phase to keep those people happy. Again forced signaling doesn’t actually mean activation. There are still many more phases to pass through.
>
> Phase 7) Speedy Trial (using block height, 0.5 years) on mainnet
>
> Phase 8) Speedy Trial (using MTP, 0.5 years) on mainnet
>
> Phase 9) Speedy Trial on the default signet (0.5 years)
>
> Phase 10) Speedy Trial on a combination of three different custom signets in parallel (0.5 years)
>
> Phase 11) Speedy Trial on testnet and a custom signet in parallel (0.5 years)
>
> Phase 12) Modern Soft Fork Activation (3.5 years) This is the longest phase of the soft fork activation standard. It is itself multi phase and multi year so this can be considered a nested activation phase within this standard.
>
> Phase 13) UASF BIP 8 (LOT=true, 1 year). Forced miner signaling at the end of this phase but ultimately the soft fork doesn’t yet activate as there is one final additional phase the activation must pass through. This gives Samson the opportunity to sell some hats. We are close now. The natives are getting restless.
>
> Phase 14) Second flag day (1 year) We don’t want those pesky users actually activating a soft fork on their own so an additional flag day is added just so we can tell users that we prevented a chain split.
>
> Assuming a soft fork activation has successfully passed through all these 14 phases it should activate. It will take a minimum of 13 years. However, if it fails during any one of these phases it has to start from Phase 1 again. We should take Bitcoin’s conservatism very seriously. If a soft fork activation can’t pass successfully through all these phases it shouldn’t activate. Ultimately we don’t really mind what is in the soft fork (any idiot can design consensus changes and write secure bug free C++ code) that is very much secondary in importance to *how* the soft fork is activated. The activation design absolutely must be conservative.
>
> I expect this rigorous standard for soft fork activation will get a BIP number. If you are going to propose a future soft fork I recommend you plan for activation in approximately 13 years from the point the soft fork code is merged into Core.
>
> I am happy to settle the soft fork activation question once and for all for the community. I expect in time my contribution will be recognized in the annals of history with Satoshi Nakamoto and Hal Finney.
>
> Addendum: Although all future soft forks will ultimately use this standard, this standard is copyrighted. Every time it is used royalties must be paid into this quantum secure Bitcoin vanity address 1quantumsecureaddress
>
>
> --
> Michael Folkson
> Email: michaelfolkson@gmail•com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


 permalink raw reply	[|nested]