📅 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.