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 mentione
I think BIP 9 is a proven failure, and flag day softforks have their own
problems:
A) There is no way to unambiguously say "the rules for this chain are
". It leaves the chain in a kind of "quantum state" where the rules
could be one thing, or could be another. Until the new rules are violated,
I see how your approach doesn't lose goal 3 while "mine" does.
Regarding goal 4, I don't think any of the approaches loses it. "Use
hashpower enforcement to de-risk the upgrade process, wherever
possible".
Well, in the case of activation while there's "many" non upgrade
miners, they simply can't he
I went back and forth with a few folks on this one. I think the fact that we
lose goals 3/4 very explicitly in order to nudge miners seems like a poor trade
off. I’ll note that your point 2 here seems a bit disconnected to me. If you
want to fork yourself off the network, you can do it in easier
Well, bip9 doesn't only fall apart in case of unreasonable objection,
it also fails simply with miners' apathy.
Anyway, your proposed plan should take care of that case too, I think.
Overall sounds good to me.
Regarding bip8-like activation, luke-jr suggested that instead of
simply activating on d
There are a series of soft-fork designs which have recently been making
good progress towards implementation and future adoption. However, for
various reasons, activation methods therefor have gotten limited
discussion. I'd like to reopen that discussion here.
It is likely worth revisiting the goa
