Luke-Jr [ARCHIVE] on Nostr: 📅 Original date posted:2013-03-13 📝 Original message:On Wednesday, March 13, ...
📅 Original date posted:2013-03-13
📝 Original message:On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote:
> 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.
Curiously enough, at least MtGox's custom implementation stuck with the
canonical blockchain despite 0.8's accidental rule change.
> 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.
No, if any other client released diverged from the consensus of all
past/existing clients, we would do the same thing: call it a formerly unknown
protocol rule, that this new client has a bug implementing, and be done with
it.
The only reason this particular issue needs special treatment is because the
implications of the new rule mean that we're up against a hard limit in the
protocol today rather than 2 years from now.
Luke
📝 Original message:On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote:
> 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.
Curiously enough, at least MtGox's custom implementation stuck with the
canonical blockchain despite 0.8's accidental rule change.
> 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.
No, if any other client released diverged from the consensus of all
past/existing clients, we would do the same thing: call it a formerly unknown
protocol rule, that this new client has a bug implementing, and be done with
it.
The only reason this particular issue needs special treatment is because the
implications of the new rule mean that we're up against a hard limit in the
protocol today rather than 2 years from now.
Luke