📅 Original date posted:2013-03-13
📝 Original message:On Wed, Mar 13, 2013 at 11:27 AM, Mark Friedenbach <mark at monetize.io> wrote:
> 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
In our common language a hardfork is a rule difference that can cause
irreconcilable failure in consensus; it's not some political change or
some change in the user's understanding or something fuzzy like that.
Please don't creep the definitions... but arguments over definitions
are silly. If you really object to calling the causes consensus
failure thing something else okay, then suggest a name, but whatever
its called thats what we're talking about here.
Your proposal of having a hardfork but only on the mining nodes has
coordination problems. What happens if we don't know how to contact a
majority of the hashpower to get them to turn off their special
validation code? This is especially a concern because it's not
unlikely that in a few months there may be solo miners with tens of
TH/s... already we have a single party with nearly a majority, though
at the moment they happen to be mining on the largest couple pools.
Far better to have this special code just triggered on a deadline,
which can be widely advertised as "you must upgrade to 0.7.4 or >0.8.1
before this time" and then all switch at once... and then we
demonstrate the viability of a general mechanism that doesn't depend
on poor miner decentralization.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 11:38:48
in reply to nevent1q…x56g
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetSeen on
wss://relay.nostr.bandPublished at
2023-06-07 11:38:48Event JSON
{
"id": "a1db76920ecd416aa22e607d6f5989ee2b04470b4127601743b7a71ac440b80b",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686137928,
"kind": 1,
"tags": [
[
"e",
"02fd249c82d4dd10181a617a5dadf9d8b2d27a405e04f833fafa551fe0bc94b8",
"",
"root"
],
[
"e",
"6af0e3a20dffea4fa2e797ba6518257df8d3e1cc2a63cbe66a011aae0512d0c3",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2013-03-13\n📝 Original message:On Wed, Mar 13, 2013 at 11:27 AM, Mark Friedenbach \u003cmark at monetize.io\u003e wrote:\n\u003e This may be a semantic issue. I meant that it's not a hard-fork of the\n\u003e bitcoin protocol, which I'm taking to mean the way in which we all\n\u003e *expected* every version of the Satoshi client to behave: the rules which we\n\nIn our common language a hardfork is a rule difference that can cause\nirreconcilable failure in consensus; it's not some political change or\nsome change in the user's understanding or something fuzzy like that.\nPlease don't creep the definitions... but arguments over definitions\nare silly. If you really object to calling the causes consensus\nfailure thing something else okay, then suggest a name, but whatever\nits called thats what we're talking about here.\n\nYour proposal of having a hardfork but only on the mining nodes has\ncoordination problems. What happens if we don't know how to contact a\nmajority of the hashpower to get them to turn off their special\nvalidation code? This is especially a concern because it's not\nunlikely that in a few months there may be solo miners with tens of\nTH/s... already we have a single party with nearly a majority, though\nat the moment they happen to be mining on the largest couple pools.\n\nFar better to have this special code just triggered on a deadline,\nwhich can be widely advertised as \"you must upgrade to 0.7.4 or \u003e0.8.1\nbefore this time\" and then all switch at once... and then we\ndemonstrate the viability of a general mechanism that doesn't depend\non poor miner decentralization.",
"sig": "2e6533317858407733d3b5728690fb980af50a8f31358f3363574a8a34c20ac8a0f5e9033f58a7e0ef2b860bfbfe56c113bfa29c9dfb908586157d4258c7dbd1"
}