MIME-Version: 1.0
Sender: rgrant@rgrant.org
In-Reply-To: <6aTsiLggIIoxf0V0RsV1i0B_DLZasJBjUdTTQewxIZYLFHvDVv3sRCFQBNCZ91gkin6vBi_AJgYZ1tVfsnigSAo8JOvDEcQCn7eRbfeH-CA=@protonmail.com>
References: <oO9hdZXHMpEDF84P5wXwMd0JsIeRqcDGVDHjgdNWxq81WpkqCIqrdMgEHmWAmM4a6i1cxDrUkgTPp_kx7N5CZxqwWP_5MtZ5DTAF2VorCp4=@protonmail.ch>
	<G5La89Lv4mv4xT4iey5PieUSZAwELWfUFrNQV--7SvAV8-ps7W6id6Xoj-9pkq5wTJmL8WXTDKhFWWNmJecyG27BdZr9bNe51Z-PtRrAPWY=@protonmail.com>
	<CAMnpzfq1WRn_=juvur8JZ4CeOKpk2QeLoCOvszVa63MPhRjuWw@mail.gmail.com>
	<6aTsiLggIIoxf0V0RsV1i0B_DLZasJBjUdTTQewxIZYLFHvDVv3sRCFQBNCZ91gkin6vBi_AJgYZ1tVfsnigSAo8JOvDEcQCn7eRbfeH-CA=@protonmail.com>
From: Ryan Grant <bitcoin-dev@rgrant.org>
Date: Fri, 7 Apr 2017 23:48:34 -0500
Message-ID: <CAMnpzfpMdikBvoJcQriS6487LmFPB4cxtVj+kQGmqhoOMfyjQg@mail.gmail.com>
To: praxeology_guy <praxeology_guy@protonmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed
	lock-in
Precedence: list

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.