public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ben Woosley <ben.woosley@gmail.com>
To: Michael Folkson <michaelfolkson@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Announcing a new standard for soft fork activation
Date: Thu, 1 Apr 2021 11:05:28 -0700	[thread overview]
Message-ID: <CAC5gnOyeg78ASZmQiDJMf2v8p50OqSBBH_FUSs79qaDVLR5Teg@mail.gmail.com> (raw)
In-Reply-To: <CAFvNmHSO1qBv2Lm4uHq82oEx5nxayKRsyP3Vx6BNfHJiOaztPQ@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2021-04-01 18:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01 14:58 [bitcoin-dev] Announcing a new standard for soft fork activation Michael Folkson
2021-04-01 18:05 ` Ben Woosley [this message]
2021-04-05 22:36 ` Erik Aronesty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAC5gnOyeg78ASZmQiDJMf2v8p50OqSBBH_FUSs79qaDVLR5Teg@mail.gmail.com \
    --to=ben.woosley@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=michaelfolkson@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox