š
Original date posted:2017-04-07
š Original message:Ryan Grant,
TLDR Unless I'm missing something, your claim that a misconfiguration would result in a stop chain is wrong because BIP9 only works on soft forks.
Does BIP9 work with hard forks? Pretty sure it is only for soft forks. If you want to make a hard fork, there is not much point in waiting for any particular miner hash power adoption rate.
With a softfork, here is the only condition for a "stopped chain":
1. User adopts more stringent rules.
2. Someone maliciously creates an invalid block as evaluated by the more stringent rules in #1, but that is valid to older nodes
3. No one ever mines a different block at the height of the block in #2, instead all of the miners only build on top of the block built at #2.
The user would have to adopt a soft fork at a time where no miner has also done the same, and where someone creates a contradictory block (which normally wouldn't happen unless someone was being malicious).
Never the less, I kind of like the idea of the user being notified when a newly activated more stringent soft fork rule caused a block to be rejected. The first time it happens, a message could come up, and then for some time after maybe it would be logged somewhere easily accessible. Such an event could be an excellent trigger to enable replay attack prevention, although maybe not automatically... unless everyone was pretty sure that a long-standing competing fork was likely to occur.
Cheers,
Praxeology Guy
-------- Original Message --------
Subject: Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in
Local Time: April 7, 2017 8:55 AM
UTC Time: April 7, 2017 1:55 PM
From: bitcoin-dev at lists.linuxfoundation.org
To: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
The primary failure mode of a user's misconfiguration of nTimeout will
be a stopped chain.
If less-sophisticated users are offered these configuration settings
then chaintip progress failures that result from them should be
prominently displayed.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/3fcd54e0/attachment.html>;
praxeology_guy [ARCHIVE] /
npub1hzā¦7nzv7
2023-06-07 17:59:31
in reply to nevent1qā¦w58g
Author Public Key
npub1hzkv59ax7ax80nv2fzvcgmveqyk3k5sg9gq695n48l9scenf5c9sa7nzv7Published at
2023-06-07 17:59:31Event JSON
{
"id": "968582120817b63df3a3cc8d3cae5a600b3450bd6f7d0b91da2f4be9b5bd753f",
"pubkey": "b8acca17a6f74c77cd8a4899846d99012d1b52082a01a2d2753fcb0c6669a60b",
"created_at": 1686160771,
"kind": 1,
"tags": [
[
"e",
"cba86c36032b98af3b5224ff15dbcd58e8a8562ced21237c3353e2b4d4bc318b",
"",
"root"
],
[
"e",
"f8a6cfefa1550dcae1731ec2d08833e32ebc519ab3ca0b19be344934ce9c1666",
"",
"reply"
],
[
"p",
"2f55bf03677afdb15d004a39383afba6220aa6c059cafa7b8827b87934d3c254"
]
],
"content": "š
Original date posted:2017-04-07\nš Original message:Ryan Grant,\n\nTLDR Unless I'm missing something, your claim that a misconfiguration would result in a stop chain is wrong because BIP9 only works on soft forks.\n\nDoes BIP9 work with hard forks? Pretty sure it is only for soft forks. If you want to make a hard fork, there is not much point in waiting for any particular miner hash power adoption rate.\n\nWith a softfork, here is the only condition for a \"stopped chain\":\n1. User adopts more stringent rules.\n2. Someone maliciously creates an invalid block as evaluated by the more stringent rules in #1, but that is valid to older nodes\n3. No one ever mines a different block at the height of the block in #2, instead all of the miners only build on top of the block built at #2.\n\nThe user would have to adopt a soft fork at a time where no miner has also done the same, and where someone creates a contradictory block (which normally wouldn't happen unless someone was being malicious).\n\nNever the less, I kind of like the idea of the user being notified when a newly activated more stringent soft fork rule caused a block to be rejected. The first time it happens, a message could come up, and then for some time after maybe it would be logged somewhere easily accessible. Such an event could be an excellent trigger to enable replay attack prevention, although maybe not automatically... unless everyone was pretty sure that a long-standing competing fork was likely to occur.\n\nCheers,\nPraxeology Guy\n\n-------- Original Message --------\nSubject: Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in\nLocal Time: April 7, 2017 8:55 AM\nUTC Time: April 7, 2017 1:55 PM\nFrom: bitcoin-dev at lists.linuxfoundation.org\nTo: Bitcoin Protocol Discussion \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\nThe primary failure mode of a user's misconfiguration of nTimeout will\nbe a stopped chain.\n\nIf less-sophisticated users are offered these configuration settings\nthen chaintip progress failures that result from them should be\nprominently displayed.\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/3fcd54e0/attachment.html\u003e",
"sig": "322afec031ac0611313bc8e93c7cc43a003de86a40d2a41eea5b47939ecfae94c35457ec02ba0cceba65c1f20c5cfe949e79d49b9aad3a3158b718d11245b218"
}