From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id ED482C0881 for ; Sat, 11 Jan 2020 00:54:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id E964E86C59 for ; Sat, 11 Jan 2020 00:54:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBxu6ZcY1hdP for ; Sat, 11 Jan 2020 00:54:20 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 9A4DB86C56 for ; Sat, 11 Jan 2020 00:54:20 +0000 (UTC) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00B0sIKs005752 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 10 Jan 2020 19:54:19 -0500 Received: by mail-io1-f54.google.com with SMTP id k24so4008702ioc.4 for ; Fri, 10 Jan 2020 16:54:19 -0800 (PST) X-Gm-Message-State: APjAAAVmLdk3G3d5Pu73kBgoFIH33R8EryNUswRW6uruoh2kJI44HdiK AbDe1nY1607vFkkjnszSFXm2znfXl5YD+2FP4W0= X-Google-Smtp-Source: APXvYqy2b1KCaXwMRIJvwNFqtNLhkaPmI7rCZiTdwfUZjynS3bih+Rdu8X2zrYZFPfoO/2j2I9E/p8MyWxMb41H2aqg= X-Received: by 2002:a02:c906:: with SMTP id t6mr5500047jao.75.1578704058008; Fri, 10 Jan 2020 16:54:18 -0800 (PST) MIME-Version: 1.0 References: <4a132f8a-22e3-8e31-e338-bed9ef46d2ef@mattcorallo.com> <202001102337.53397.luke@dashjr.org> In-Reply-To: <202001102337.53397.luke@dashjr.org> From: Jeremy Date: Fri, 10 Jan 2020 16:54:06 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000955473059bd2aeab" Subject: Re: [bitcoin-dev] Modern Soft Fork Activation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 00:54:22 -0000 --000000000000955473059bd2aeab Content-Type: text/plain; charset="UTF-8" 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 --000000000000955473059bd2aeab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 prop= osed a while back. https://www.youtube.com/watch?v=3DJ1CP7qbnpqA&= feature=3Dyoutu.be

It has some interesting properties around the = 5 properties you've mentioned.
<= br>
1) Avoid activating in the face o= f 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 init= iation, statistically improbable/impossible for even earlier adoption.
<= /div>

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

Diffi= culty adjustments make the missing spork'd block "go away" ov= er time, the additional difficulty of *not activating* a rejected spork fil= ls in as an additional PoW.

<= /div>

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

Miners choose to activate or build on activating blo= cks.

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 thei= r money where there mouth is" on what the community wants.

--000000000000955473059bd2aeab--