Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in

[Ryan Grant <bitcoin-dev@rgrant.org>]

Praxeology Guy,

On Fri, Apr 7, 2017 at 12:56 PM, praxeology_guy
<praxeology_guy@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.