📅 Original date posted:2015-12-30
📝 Original message:On Dec 30, 2015, at 11:00 AM, Bob McElrath via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> joe2015--- via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
>> That's the whole point. After a conventional hardfork everyone
>> needs to upgrade, but there is no way to force users to upgrade. A
>> user who is simply unaware of the fork, or disagrees with the fork,
>> uses the old client and the currency splits.
>>
>> Under this proposal old clients effectively enter "zombie" mode,
>> forcing users to upgrade.
>
> This is a very complex way to enter zombie mode.
Another way you could make non-upgraded nodes enter zombie mode is to explicitly 51% attack the minority fork.
All soft forks are controlled, coordinated, developer-sanctioned 51% attacks against nodes that do not upgrade. The generalized softfork technique is a method of performing a soft fork that completely eliminates any usefulness to non-upgraded nodes while merge-mining another block structure to provide functionality to the nodes who have upgraded and know where to look for the new data.
Soft forks are "safe" forks because you can trust the miners to censor blocks and transactions that do not conform to the new consensus rules. Since we've been relying on the trustworthiness of miners during soft forks in the past (and it only failed us once!), why not
The generalized softfork method has the advantage of being merge-mined, so miners don't have to lose any revenue while performing this 51% attack against non-upgraded nodes. But then you're stuck with all of your transactions in a merge-mined/commitment-based data structure, which is a bit awkward and ugly. But you could avoid all of that code ugliness by just convincing the miners to donate some hashrate (say, 5.1% if the IsSupermajority threshold is 95%, or you could make it dynamic to save some money) to ensuring that the minority fork never has any transactions in the chain. That way, you can replace the everlasting code ugliness with a little bit of temporary sociopolitical ugliness. Fortunately, angry people are easier to ignore than ugly code. /s
Maybe we could call this a softly enforced hard fork? It's basically a combined hard fork for the supermajority and a soft fork to make the minority chain useless.
I don't personally think that these 51% attacks are useful or necessary. This is one of the main reasons why I don't like soft forks. I find them distasteful, and think that leaving minorities free to practice their own religions and blockchain rules is a good thing. But I could see how this could address some of the objections that others have raised about the dangers of hardforks, so I'm putting it out there.
> Once a chain is seen to be 6 or more blocks ahead of my chain tip, we should
> enter "zombie mode" and refuse to mine or relay
I like this method. However, it does have the problem of being voluntary. If nodes don't upgrade to a version that has the latent zombie gene long before a fork, then it does nothing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151230/5ebf647b/attachment-0001.sig>;
Jonathan Toomim [ARCHIVE] /
npub1pl…yj0hj
2023-06-07 17:47:14
in reply to nevent1q…6tzj
Author Public Key
npub1pl6kcz00s7wgn6syh73dta0qm9sqpmtw4adv8rnm2w9fmynkw45sayj0hjPublished at
2023-06-07 17:47:14Event JSON
{
"id": "4f4df6ccc8d0dc3a09883c93b6c17aa5886761a7b390d3edb6759a350e00b4d7",
"pubkey": "0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569",
"created_at": 1686160034,
"kind": 1,
"tags": [
[
"e",
"cff63604c5ea2135194b6bb6cc24978162ba68b9dba72176ba103744f1094f89",
"",
"root"
],
[
"e",
"b9d48fd2a3337776dc46ea14ba2c6711292d1e7c64c685f3b38616da374a6739",
"",
"reply"
],
[
"p",
"a4fc2fc2bfc061e75a1b6e17dfc4b3c93b85fab2fc91001f44fd8499d672b169"
]
],
"content": "📅 Original date posted:2015-12-30\n📝 Original message:On Dec 30, 2015, at 11:00 AM, Bob McElrath via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e joe2015--- via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:\n\u003e\u003e That's the whole point. After a conventional hardfork everyone\n\u003e\u003e needs to upgrade, but there is no way to force users to upgrade. A\n\u003e\u003e user who is simply unaware of the fork, or disagrees with the fork,\n\u003e\u003e uses the old client and the currency splits.\n\u003e\u003e \n\u003e\u003e Under this proposal old clients effectively enter \"zombie\" mode,\n\u003e\u003e forcing users to upgrade.\n\u003e \n\u003e This is a very complex way to enter zombie mode.\n\n\nAnother way you could make non-upgraded nodes enter zombie mode is to explicitly 51% attack the minority fork.\n\nAll soft forks are controlled, coordinated, developer-sanctioned 51% attacks against nodes that do not upgrade. The generalized softfork technique is a method of performing a soft fork that completely eliminates any usefulness to non-upgraded nodes while merge-mining another block structure to provide functionality to the nodes who have upgraded and know where to look for the new data.\n\nSoft forks are \"safe\" forks because you can trust the miners to censor blocks and transactions that do not conform to the new consensus rules. Since we've been relying on the trustworthiness of miners during soft forks in the past (and it only failed us once!), why not\n\nThe generalized softfork method has the advantage of being merge-mined, so miners don't have to lose any revenue while performing this 51% attack against non-upgraded nodes. But then you're stuck with all of your transactions in a merge-mined/commitment-based data structure, which is a bit awkward and ugly. But you could avoid all of that code ugliness by just convincing the miners to donate some hashrate (say, 5.1% if the IsSupermajority threshold is 95%, or you could make it dynamic to save some money) to ensuring that the minority fork never has any transactions in the chain. That way, you can replace the everlasting code ugliness with a little bit of temporary sociopolitical ugliness. Fortunately, angry people are easier to ignore than ugly code. /s\n\nMaybe we could call this a softly enforced hard fork? It's basically a combined hard fork for the supermajority and a soft fork to make the minority chain useless.\n\nI don't personally think that these 51% attacks are useful or necessary. This is one of the main reasons why I don't like soft forks. I find them distasteful, and think that leaving minorities free to practice their own religions and blockchain rules is a good thing. But I could see how this could address some of the objections that others have raised about the dangers of hardforks, so I'm putting it out there.\n\n\u003e Once a chain is seen to be 6 or more blocks ahead of my chain tip, we should\n\u003e enter \"zombie mode\" and refuse to mine or relay\n\nI like this method. However, it does have the problem of being voluntary. If nodes don't upgrade to a version that has the latent zombie gene long before a fork, then it does nothing.\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151230/5ebf647b/attachment-0001.sig\u003e",
"sig": "4f795edad5402e7706e0f6d4c10a23ff95e78641ba729dc473df4440ac81140110da81dfa0a5f6d01713550756f7fefe36ecccc086ea8e40d205cec2a5f9edf2"
}