This may be a semantic issue. I meant that it's not a hard-fork of the bitcoin protocol, which I'm taking to mean the way in which we all *expected* every version of the Satoshi client to behave: the rules which we have documented informally on the wiki, this mailing list, and in code comments, etc. I'm just trying to prevent protocol-creep.

Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules which all verifying implementations must adhere to. I'm suggesting that we instead change the old codebase to do what we expected it to do all along (what 0.8 does and what every other verifying implementation does), and through miner collusion buy ourselves enough time for people to update their own installations.

I know there's people here who will jump in saying that the bitcoin protocol is the behavior of the Satoshi client, period. But which Satoshi client? 0.7 or 0.8? How do you resolve that without being arbitrary? And regardless, we are moving very quickly towards a multi-client future. This problem is very clearly a *bug* in the old codebase. So let's be forward thinking and do what we would do in any other situation: fix the bug, responsibly notify people and give them time to react, then move on. Let's not codify the bug in the protocol.

Mark



On Wed, Mar 13, 2013 at 10:58 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
On Wed, Mar 13, 2013 at 10:41:29AM -0700, Mark Friedenbach wrote:
> 4) At some point in the future once we've crossed an acceptable adoption
> threshold, the miners remove the above patch in a coordinated way.
>
> Does that not get us past this crisis without a hard-fork?

This is a hardfork: it means some nodes will have to accept blocks they formerly considered invalid.

--
Pieter