From: Jeremy <jlrubin@mit•edu>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Modern Soft Fork Activation
Date: Fri, 10 Jan 2020 16:54:06 -0800 [thread overview]
Message-ID: <CAD5xwhjMNtzsEgC515Q3ddy1=K=iMNt-r3CXpg_ctXzWjtNb8g@mail.gmail.com> (raw)
In-Reply-To: <202001102337.53397.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]
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>
[-- Attachment #2: Type: text/html, Size: 4099 bytes --]
next prev parent reply other threads:[~2020-01-11 0:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-10 21:30 Matt Corallo
2020-01-10 22:21 ` Jorge Timón
2020-01-10 22:43 ` Matt Corallo
2020-01-10 23:07 ` Jorge Timón
2020-01-10 23:37 ` Luke Dashjr
2020-01-11 0:54 ` Jeremy [this message]
2020-01-14 19:22 ` Matt Corallo
2020-01-11 14:42 ` Anthony Towns
2020-01-12 5:58 ` Luke Dashjr
2020-01-14 19:42 ` Matt Corallo
2020-01-16 3:46 ` Anthony Towns
2020-01-13 8:34 Yosef
2020-01-14 3:20 ` Anthony Towns
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='CAD5xwhjMNtzsEgC515Q3ddy1=K=iMNt-r3CXpg_ctXzWjtNb8g@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