[bitcoin-dev] Modern Soft Fork Activation

Jeremy jlrubin at mit.edu
Sat Jan 11 00:54:06 UTC 2020


It's not at a "directly implementable policy state", but I think you might
be interested in checking out the spork protocol upgrade model I proposed a
while back. https://www.youtube.com/watch?v=J1CP7qbnpqA&feature=youtu.be

It has some interesting properties around the 5 properties you've mentioned.

1) Avoid activating in the face of significant, reasonable, and directed
objection. Period.

Up to miners to orphan spork-activating blocks.

2) Avoid activating within a timeframe which does not make high
node-level-adoption likely.

Mandatory minimum flag day for Spork initiation, statistically
improbable/impossible for even earlier adoption.

3) Don't (needlessly) lose hashpower to un-upgraded miners.

Difficulty adjustments make the missing spork'd block "go away" over time,
the additional difficulty of *not activating* a rejected spork fills in as
an additional PoW.


4) Use hashpower enforcement to de-risk the upgrade process, wherever
possible.

Miners choose to activate or build on activating blocks.

5) Follow the will of the community, irrespective of individuals or
unreasoned objection, but without ever overruling any reasonable
objection.

Honest signalling makes people be forced to "put their money where there
mouth is" on what the community wants.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200110/fd51faa2/attachment.html>


More information about the bitcoin-dev mailing list