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

From: praxeology_guy <praxeology_guy@protonmail.com>
To: Ryan Grant <bitcoin-dev@rgrant.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in
Date: Fri, 07 Apr 2017 13:56:55 -0400	[thread overview]
Message-ID: <6aTsiLggIIoxf0V0RsV1i0B_DLZasJBjUdTTQewxIZYLFHvDVv3sRCFQBNCZ91gkin6vBi_AJgYZ1tVfsnigSAo8JOvDEcQCn7eRbfeH-CA=@protonmail.com> (raw)
In-Reply-To: <CAMnpzfq1WRn_=juvur8JZ4CeOKpk2QeLoCOvszVa63MPhRjuWw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]

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@lists.linuxfoundation.org
To: Bitcoin Protocol Discussion <bitcoin-dev@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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 2775 bytes --]