📅 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
Luke-Jr [ARCHIVE] /
npub1dt…u7wrs
2023-06-07 11:38:52
in reply to nevent1q…kgcq
Author Public Key
npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrsPublished at
2023-06-07 11:38:52Event JSON
{
"id": "cce16b660ea698c707bc2eaa1f5697070261dcdcb1fe522722c402ff55c8f781",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686137932,
"kind": 1,
"tags": [
[
"e",
"02fd249c82d4dd10181a617a5dadf9d8b2d27a405e04f833fafa551fe0bc94b8",
"",
"root"
],
[
"e",
"a1db76920ecd416aa22e607d6f5989ee2b04470b4127601743b7a71ac440b80b",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2013-03-13\n📝 Original message:On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote:\n\u003e Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules\n\u003e which all verifying implementations must adhere to. I'm suggesting that we\n\u003e instead change the old codebase to do what we expected it to do all along\n\u003e (what 0.8 does and what every other verifying implementation does), and\n\u003e through miner collusion buy ourselves enough time for people to update\n\u003e their own installations.\n\nCuriously enough, at least MtGox's custom implementation stuck with the \ncanonical blockchain despite 0.8's accidental rule change.\n\n\u003e I know there's people here who will jump in saying that the bitcoin\n\u003e protocol is the behavior of the Satoshi client, period. But which Satoshi\n\u003e client? 0.7 or 0.8? How do you resolve that without being arbitrary? And\n\u003e regardless, we are moving very quickly towards a multi-client future. This\n\u003e problem is very clearly a *bug* in the old codebase. So let's be forward\n\u003e thinking and do what we would do in any other situation: fix the bug,\n\u003e responsibly notify people and give them time to react, then move on. Let's\n\u003e not codify the bug in the protocol.\n\nNo, if any other client released diverged from the consensus of all \npast/existing clients, we would do the same thing: call it a formerly unknown \nprotocol rule, that this new client has a bug implementing, and be done with \nit.\n\nThe only reason this particular issue needs special treatment is because the \nimplications of the new rule mean that we're up against a hard limit in the \nprotocol today rather than 2 years from now.\n\nLuke",
"sig": "6a3acb0824aaf257fb10183d1b884957e47070f8b892384d8d56a2714b9795eac68e82352323f0e33d84d4ce6da6e2e4d9450dbd9abb892bbcfb1e3ced4e4eaf"
}