<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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. <a href="https://www.youtube.com/watch?v=J1CP7qbnpqA&feature=youtu.be">https://www.youtube.com/watch?v=J1CP7qbnpqA&feature=youtu.be</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">It has some interesting properties around the 5 properties you've mentioned.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">1) Avoid activating in the face of significant, reasonable, and directed<br>
objection. Period.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Up to miners to orphan spork-activating blocks.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br>
2) Avoid activating within a timeframe which does not make high<br>
node-level-adoption likely.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Mandatory minimum flag day for Spork initiation, statistically improbable/impossible for even earlier adoption.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br>
3) Don't (needlessly) lose hashpower to un-upgraded miners.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">
4) Use hashpower enforcement to de-risk the upgrade process, wherever<br>
possible. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Miners choose to activate or build on activating blocks.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">
<br>
5) Follow the will of the community, irrespective of individuals or<br>
unreasoned objection, but without ever overruling any reasonable<br>
objection.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Honest signalling makes people be forced to "put their money where there mouth is" on what the community wants.<br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">--<br><a href="https://twitter.com/JeremyRubin" target="_blank">@JeremyRubin</a><a href="https://twitter.com/JeremyRubin" target="_blank"></a></div></div></div><br></div></div>