📅 Original date posted:2015-06-20
📝 Original message:I see it as unreasonable to expect all nodes to upgrade during a hardfork.
If you are intentionally waiting for that to happen, it's possible for an
extreme minority of nodes to hold the rest of the network hostage by simply
refusing to upgrade. However you want nodes to be able to protest until it
is clear that they have lost the battle without being at risk of getting
hardforked out of the network unexpectedly.
I think it makes sense to add a second fuse. After the 95% barrier has been
crossed, a 6 week timer starts that gives the remaining 5% time to upgrade.
If they still don't upgrade, they have intentionally forked themselves from
the network and it is not something that the remaining 95% need to be
concerned with.
On Sat, Jun 20, 2015 at 1:13 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> Hello all,
>
> I've seen ideas around hard fork proposals that involve a block version
> vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
> believe this is a bad idea, independent of what the hard fork itself is.
>
> Ultimately, the purpose of a hard fork is asking the whole community to
> change their full nodes to new code. The purpose of the trigger mechanism
> is to establish when that has happened.
>
> Using a 95% threshold, implies the fork can happen when at least 5% of
> miners have not upgraded, which implies some full nodes have not (as miners
> are nodes), and in addition, means the old chain can keep growing too,
> confusing old non-miner nodes as well.
>
> Ideally, the fork should be scheduled when one is certain nodes will have
> upgraded, and the risk for a fork will be gone. If everyone has upgraded,
> no vote is necessary, and if nodes have not, it remains risky to fork them
> off.
>
> I understand that, in order to keep humans in the loop, you want an
> observable trigger mechanism, and a hashrate vote is an easy way to do
> this. But at least, use a minimum timestamp you believe to be reasonable
> for upgrade, and a 100% threshold afterwards. Anything else guarantees that
> your forking change happens *knowingly* before the risk is gone.
>
> You may argue that miners would be asked to - and have it in their best
> interest - to not actually make blocks that violate the changed rule before
> they are reasonably sure that everyone has upgraded. That is possible, but
> it does not gain you anything over just using a 100% threshold, as how
> would they be reasonably sure everyone has upgraded, while blocks creater
> by non-upgraded miners are still being created?
>
> TL;DR: use a timestamp switchover for a hard fork, or add a block voting
> threshold as a means to keep humans in the loop, but if you do, use 100% as
> threshold.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/fe7f5f4e/attachment.html>;
David Vorick [ARCHIVE] /
npub14h…9yjx0
2023-06-07 15:39:25
in reply to nevent1q…wm3s
Author Public Key
npub14h948ndawt32ps3y225sslch8344tmw8k5z0lxuxr6wq9tu6sl2qj9yjx0Published at
2023-06-07 15:39:25Event JSON
{
"id": "0b4fa80ae62094a5596287f385387e0c964c323936fcdbd11a0828f9751f407a",
"pubkey": "adcb53cdbd72e2a0c22452a9087f173c6b55edc7b504ff9b861e9c02af9a87d4",
"created_at": 1686152365,
"kind": 1,
"tags": [
[
"e",
"5e5505c6614a3f5ff0812477d38a10424e83d2730770e93e1ea2cd14483e132d",
"",
"root"
],
[
"e",
"cc3de98cfbb161f15a8cd682f9fc5b84836c00ec2de243f0fbe7529baf00d8b9",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2015-06-20\n📝 Original message:I see it as unreasonable to expect all nodes to upgrade during a hardfork.\nIf you are intentionally waiting for that to happen, it's possible for an\nextreme minority of nodes to hold the rest of the network hostage by simply\nrefusing to upgrade. However you want nodes to be able to protest until it\nis clear that they have lost the battle without being at risk of getting\nhardforked out of the network unexpectedly.\n\nI think it makes sense to add a second fuse. After the 95% barrier has been\ncrossed, a 6 week timer starts that gives the remaining 5% time to upgrade.\nIf they still don't upgrade, they have intentionally forked themselves from\nthe network and it is not something that the remaining 95% need to be\nconcerned with.\n\nOn Sat, Jun 20, 2015 at 1:13 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e\nwrote:\n\n\u003e Hello all,\n\u003e\n\u003e I've seen ideas around hard fork proposals that involve a block version\n\u003e vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I\n\u003e believe this is a bad idea, independent of what the hard fork itself is.\n\u003e\n\u003e Ultimately, the purpose of a hard fork is asking the whole community to\n\u003e change their full nodes to new code. The purpose of the trigger mechanism\n\u003e is to establish when that has happened.\n\u003e\n\u003e Using a 95% threshold, implies the fork can happen when at least 5% of\n\u003e miners have not upgraded, which implies some full nodes have not (as miners\n\u003e are nodes), and in addition, means the old chain can keep growing too,\n\u003e confusing old non-miner nodes as well.\n\u003e\n\u003e Ideally, the fork should be scheduled when one is certain nodes will have\n\u003e upgraded, and the risk for a fork will be gone. If everyone has upgraded,\n\u003e no vote is necessary, and if nodes have not, it remains risky to fork them\n\u003e off.\n\u003e\n\u003e I understand that, in order to keep humans in the loop, you want an\n\u003e observable trigger mechanism, and a hashrate vote is an easy way to do\n\u003e this. But at least, use a minimum timestamp you believe to be reasonable\n\u003e for upgrade, and a 100% threshold afterwards. Anything else guarantees that\n\u003e your forking change happens *knowingly* before the risk is gone.\n\u003e\n\u003e You may argue that miners would be asked to - and have it in their best\n\u003e interest - to not actually make blocks that violate the changed rule before\n\u003e they are reasonably sure that everyone has upgraded. That is possible, but\n\u003e it does not gain you anything over just using a 100% threshold, as how\n\u003e would they be reasonably sure everyone has upgraded, while blocks creater\n\u003e by non-upgraded miners are still being created?\n\u003e\n\u003e TL;DR: use a timestamp switchover for a hard fork, or add a block voting\n\u003e threshold as a means to keep humans in the loop, but if you do, use 100% as\n\u003e threshold.\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/fe7f5f4e/attachment.html\u003e",
"sig": "09b0fcccc21e5102369854da20d8ccbc9922378fad392c73ee23b3379b983dc38fcac94536b8db37dc19c5f613fbe67ab315637c67196f4f672c9f9088f411cd"
}