📅 Original date posted:2013-03-13
📝 Original message:I hear consensus that at some point we need a hardfork (== creating blocks that will not be accepted by <0.7 clients).
Miners generate block, hence they are the ones who should filter themselves though some consensus.
> But we cannot just drop support for old nodes. It is completely unreasonable to put the
> _majority_ of the network on a fork, without even as much as a discussion about it.
> "Oh, you didn't get the memo? The rules implemented in your client are outdated." - that
> is not how Bitcoin works: the network defines the rules.
Consensus was rapidly reached a day ago: To ensure the majority (all of?) the network could accept the blocks mined, and not just 0.8. This was the right decision! Too many was dependent on <=0.7
So, the question is not if, but when to do a hardfork. We need to define and monitor the % of nodes running different versions (preferably a weighted average - some nodes, like e.g. blockchain.info & mtgox serve many...). Once there was the rowit bitcoinstatus page - do we have another resource for this ?
Then the second question is how to ensure we don't create a fork again? Pieter (and others?) are of the opinion that we should mimic a 0.7 lock-object-starvation-reject-rule. I don't like this for three reasons:
1. I find it hard to ensure we have actually coined the bug precisely
2. I expect that similar issues will happen again
3. The current issue was between two versions, but in the future it could be between two implementations - then trying implement or even to coordinate strange rules becomes very unlikely.
Hence the scheme for "considerate mining" - it is the only scheme that guarantees 100% that no block are released that will not be accepted by a supermajority of the install base.
Another nice thing about it - it requires no development :)
So simply run in serial in front of all considerate miners nodes of different versions until a certain threshold of the install base is reached.
/M
Michael Gronager [ARCHIVE] /
npub1nc…gw452
2023-06-07 11:39:54
in reply to nevent1q…kc99
Author Public Key
npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452Seen on
wss://relay.nostr.bandPublished at
2023-06-07 11:39:54Event JSON
{
"id": "555d4fa5105ffeff068e57b22465b7c4a80eae5efd3e829225d48558cd66ea98",
"pubkey": "9e3c76fd7eb862ca37f150391debc7baa4f8423eaa3f894c476a7d4360de9a02",
"created_at": 1686137994,
"kind": 1,
"tags": [
[
"e",
"ea3422d0a063fab11de8957903941e8279220a37fb8d6878b562ce9554cc2fa5",
"",
"root"
],
[
"e",
"43d422dd9c5c4db35bcaf9c69a27fa1e86c6ce81de34e96c915fbe381c39c702",
"",
"reply"
],
[
"p",
"5570d204bda7735652416863ba13b26e8065a443c269cdcedef82e8107dc93a7"
]
],
"content": "📅 Original date posted:2013-03-13\n📝 Original message:I hear consensus that at some point we need a hardfork (== creating blocks that will not be accepted by \u003c0.7 clients).\n\nMiners generate block, hence they are the ones who should filter themselves though some consensus. \n\n\n\u003e But we cannot just drop support for old nodes. It is completely unreasonable to put the\n\u003e _majority_ of the network on a fork, without even as much as a discussion about it.\n\u003e \"Oh, you didn't get the memo? The rules implemented in your client are outdated.\" - that\n\u003e is not how Bitcoin works: the network defines the rules.\n\nConsensus was rapidly reached a day ago: To ensure the majority (all of?) the network could accept the blocks mined, and not just 0.8. This was the right decision! Too many was dependent on \u003c=0.7\n\nSo, the question is not if, but when to do a hardfork. We need to define and monitor the % of nodes running different versions (preferably a weighted average - some nodes, like e.g. blockchain.info \u0026 mtgox serve many...). Once there was the rowit bitcoinstatus page - do we have another resource for this ?\n\nThen the second question is how to ensure we don't create a fork again? Pieter (and others?) are of the opinion that we should mimic a 0.7 lock-object-starvation-reject-rule. I don't like this for three reasons:\n1. I find it hard to ensure we have actually coined the bug precisely\n2. I expect that similar issues will happen again\n3. The current issue was between two versions, but in the future it could be between two implementations - then trying implement or even to coordinate strange rules becomes very unlikely.\n\nHence the scheme for \"considerate mining\" - it is the only scheme that guarantees 100% that no block are released that will not be accepted by a supermajority of the install base.\n\nAnother nice thing about it - it requires no development :)\n\nSo simply run in serial in front of all considerate miners nodes of different versions until a certain threshold of the install base is reached.\n\n/M",
"sig": "1e9953ead737eace935bc82117203f9ccce2d85aefdd81471b35817f9a08bb0bc918be274c2720393c3c4852de42fbf4b4b2fc034f63ebaf3cedcb8ae73752ce"
}