š
Original date posted:2017-04-08
š Original message:Praxeology Guy,
On Fri, Apr 7, 2017 at 12:56 PM, praxeology_guy
<praxeology_guy at protonmail.com> wrote:
> 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.
If our rule change timing is different from changes on the chain with
most work, then (extending Johnson Lau's terminology a bit) we may
experience subjective hardfork-ness; due to miners creating blocks
which the economic majority goes on to accept, though they have a less
restrictive ruleset than ours.
> 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).
Correct for the segwit soft fork, which is narrowing the definition
of a nonstandard transaction. It's safe to say that if a block with a
tx violating cleanstack were to occur on a non-segwit chain, that it
was for malicious reasons.
However, some future forks - that a full node experiences as
low subjective hardfork-ness (i.e. soft forks) - might restrict
more common things.
> 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.
Sure, a nice-to-have would be a SetfLargeWorkInvalidChainFound() that
was aware as well, though clients can make these decisions themselves.
Ryan Grant [ARCHIVE] /
npub19aā¦6mwcl
2023-06-07 17:59:32
in reply to nevent1qā¦d4xl
Author Public Key
npub19a2m7qm80t7mzhgqfgunswhm5c3q4fkqt89057ugy7u8jdxncf2q06mwclPublished at
2023-06-07 17:59:32Event JSON
{
"id": "35808913c3ebe30e56e5b56580b37048261738221b87c56ef0021869b6c6e2af",
"pubkey": "2f55bf03677afdb15d004a39383afba6220aa6c059cafa7b8827b87934d3c254",
"created_at": 1686160772,
"kind": 1,
"tags": [
[
"e",
"cba86c36032b98af3b5224ff15dbcd58e8a8562ced21237c3353e2b4d4bc318b",
"",
"root"
],
[
"e",
"968582120817b63df3a3cc8d3cae5a600b3450bd6f7d0b91da2f4be9b5bd753f",
"",
"reply"
],
[
"p",
"b8acca17a6f74c77cd8a4899846d99012d1b52082a01a2d2753fcb0c6669a60b"
]
],
"content": "š
Original date posted:2017-04-08\nš Original message:Praxeology Guy,\n\nOn Fri, Apr 7, 2017 at 12:56 PM, praxeology_guy\n\u003cpraxeology_guy at protonmail.com\u003e wrote:\n\u003e TLDR Unless I'm missing something, your claim that a\n\u003e misconfiguration would result in a stop chain is wrong because BIP9\n\u003e only works on soft forks.\n\nIf our rule change timing is different from changes on the chain with\nmost work, then (extending Johnson Lau's terminology a bit) we may\nexperience subjective hardfork-ness; due to miners creating blocks\nwhich the economic majority goes on to accept, though they have a less\nrestrictive ruleset than ours.\n\n\u003e The user would have to adopt a soft fork at a time where no miner\n\u003e has also done the same, and where someone creates a contradictory\n\u003e block (which normally wouldn't happen unless someone was being\n\u003e malicious).\n\nCorrect for the segwit soft fork, which is narrowing the definition\nof a nonstandard transaction. It's safe to say that if a block with a\ntx violating cleanstack were to occur on a non-segwit chain, that it\nwas for malicious reasons.\n\nHowever, some future forks - that a full node experiences as\nlow subjective hardfork-ness (i.e. soft forks) - might restrict\nmore common things.\n\n\u003e Never the less, I kind of like the idea of the user being notified\n\u003e when a newly activated more stringent soft fork rule caused a block\n\u003e to be rejected. The first time it happens, a message could come up,\n\u003e and then for some time after maybe it would be logged somewhere\n\u003e easily accessible.\n\nSure, a nice-to-have would be a SetfLargeWorkInvalidChainFound() that\nwas aware as well, though clients can make these decisions themselves.",
"sig": "81db5b28f5b31398465b910e69f1cdcf17a4bff68538727761aa597052fe2d990d4141d618e4fa8cec20d141e6e37dfb3770367ac2cef05185e8eb19e06a70a4"
}