public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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 [bitcoin-dev] Modern Soft Fork Activation 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.edu \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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