From: Jeremy <jlrubin@mit•edu>
To: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] And Then What? Defining a Complete Process for Upgrades
Date: Thu, 22 Apr 2021 15:41:56 -0700 [thread overview]
Message-ID: <CAD5xwhg+tzjsz9fSoSxKV4oqgemr5p2ETaf-7vzQW+rg6Q_GFg@mail.gmail.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 6830 bytes --]
This letter is particularly aimed at addressing Rusty Russell's quest for a
development process that respects all groups in a balance of powers.
However, in the spirit of open discussion, I'm sending it directly to the
list.
This proposal is aimed to be compatible with Taproot's ST, and I hope will
help us form some rough consensus around what we try next. Some of the
concepts here are synthesized from what I've seen discussed, but I haven't
included citations of anyone's specific ideas as I'm not sure of the exact
provenance -- I won't claim to have invented this per se, I'm trying to
capture the zeitgeist of what anyone might think to be the process if
pressed to draw it out. Lemme know how I did.
The specific parameters are up for debate, but I'm trying to make sure I've
captured the relevant state transitions.
In this diagram time flows left-to-right, and transitions happen at the
beginning, end, or middle of a block of time. It should be relatively clear
when things happen, but if not, please ask to clarify.
[image: Activation.png]
Clarifications:
- ST: Speedy trial, whereby > T% signals on a block activate the rule
- neg-ST: Speedy Trial, whereby >X% signals on a block Reject the rule
- neg-ST and ST at the same time on different bits: 11 or 00 are "abstain"
votes and are discarded. only 10 or 01 are counted. The purpose of
simultaneous bits is to allow both earlier lock in and to permit early
failure, rather than just one or the other.
- PoW Fork: If a new rule is active, but there is insufficient hashrate,
the rule must be abandoned or PoW must be changed to minimize disruption.
In order to minimize disruption, a node will consider an alternative PoW
chain if < 1/4 of the typical hash rate is seen for a day. Alternative PoW
is defined as SHA-256 10,000 layers, and starts at low difficulty. This is
selected to be maximally similar to Bitcoin's existing PoW, but
sufficiently different to obviate extant ASICS. A node will consider the
new PoW to be equal in value to the old PoW, and will select between the
two based on most-work. Work can be either within a single chain. The new
PoW should have a difficulty adjustment every day for the first month, at
which point, it will relax to every 2 weeks. The details of this should be
described in a separate BIP.
- PoW Fork Lockin: PoW fork is only *required* once the new rule is active.
Thus it's not required in the case of mandatory signalling to force the
signalling contemporaneously, but it can be used to commit to forking the
PoW at some time in the future. It may make sense to not activate the new
rule till the new PoW is active. The game theory of this should be studied
carefully, it is my opinion that the safest option is to PoW fork during
signalling as otherwise miners may protest progress at all.
- Changes: Any time the underlying activation proposal is changed, the
process is restarted. E.g., suppose taproot is rejected because Quantum
Scaries, and we hash the key. The process restarts from the beginning.
Restarts can only occur during quieting periods.
- Quieting Period 1: In the first quieting period, if reached, the "Bitcoin
Core Community" can release the next step, or change the BIP. I left out
failing in this period as a change or a redeployment should always be
attempted.
- Quieting Period 2: In the second quieting period, the outcome is either
to reject the change entirely or to agree to force it. The "Bitcoin Core
Community" may also prepare the release at this stage, and sign, but should
re-label the client as "Bitcoin Community's <Feature> Forcing Client". A
release labeled "Bitcoin Core" may also be made without mandatory
signalling and without forced activation can also be made, such a client
should have (depending on if the flag day is to use signalling) either
ability to activate in response to signalling or a hidden
<feature>activeathash parameter to allow clients to enable the feature
post-hoc of the activating block.
- Forced Signalling: It's unclear to me the merit of forced signalling
being 90% of 2016 blocks v.s. 90% of 100 blocks. A shorter forced signaling
assuages certain concerns around lost hashrate -- 1 day of disruption is a
lot better than 2 weeks.
- Timeline: As spec'd above, this whole process takes about 2 years worst
case. ST1 0 months; Quieting 1 at 3 months; ST2 at 6 months; Quieting 2 at
9 months, final attempt at 1 year. The Forcing client period should
probably be 1 yr till active. This is *a bit* slower than the "BIP8
LOT=True UASF Client", but I think not so much slower that it's unworkable.
The most contentious part of this I intuit to be the PoW Fork -- please,
let's avoid discussing the mechanic of how to most safely accomplish this.
The main point of including it in this diagram is to emphasize that if you
commit to being on a minority chain with because of a rule activation with,
say, 5% hashrate, you would experience very tangible disruption. In theory,
every fork upgrade (even signalled) entails such a risk, but we assume some
level of miner honesty (unfortunately!) that they never signal falsely.
This may be a bad assumption with mandatory signalling. The alternative is
to permit hard forks in our diagram, and allow users to downgrade their
client and deactivate this rule. Since this can lead to loss of funds, we
do not consider this a safe option, and it is a hardfork as well so is
technically compatible with the "PoW fork" branch.
Questions I have:
1) What state transitions are missing from this diagram? Are there other
paths that should be included?
2) Is it ever feasible to make a change to the upgrade and not restart the
whole process?
3) How long should all of the periods be? Can the 1st 2 ST's be 3 month?
Should we make the second one 6 month? Does it depend on previous signalled
hashrate?
4) Do we ever adjust signalling thresholds?
5) Does forced signalling need to be 2016 blocks?
6) In the second ST should the min active height be allowed to be within
signalling time if > 3 mo?
7) Under what circumstances would we *want* to skip the second ST period
and directly signal? What would we lose by committing to not skipping it,
ever (6 months?).
8) I purposefully left the purple edge from ST2 bit 2 to Quieting 2: in
theory, this edge is not there because it is overruled by the neg-ST
failing to fail. Under what circumstances might we give this precedence
over neg-ST? E.g., signalling activate < 50%?
9) How much parameter flexibility do we have during Quieting periods?
Should we be fixed beforehand?
10) who wants to write the software for any of this... *noses*
11) do we need to hard-code the PoW fork ahead of time? Or can it just be
"prepared" as an alt binary in case of emergency?
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
[-- Attachment #1.2: Type: text/html, Size: 12497 bytes --]
[-- Attachment #2: Activation.png --]
[-- Type: image/png, Size: 81125 bytes --]
next reply other threads:[~2021-04-22 22:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-22 22:41 Jeremy [this message]
2021-04-23 0:06 ` Keagan McClelland
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=CAD5xwhg+tzjsz9fSoSxKV4oqgemr5p2ETaf-7vzQW+rg6Q_GFg@mail.gmail.com \
--to=jlrubin@mit$(echo .)edu \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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