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

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

[Kekcoin]

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

> After some thought I managed to simplify the original uaversionbits proposal introducing a simple boolean flag to guarantee lock-in of a BIP9 deployment by the timeout. This seems to be the simplest form combining optional flag day activation with BIP9. This brings the best of both worlds allowing user activated soft forks that can be activated early by the hash power.

After mulling over this proposal I think it is quite elegant; however there is one big "regression" in functionality in regards to BIP9 which it extends upon; a lack of back-out procedure. That is to say, if a protocol change is deployed using this BIP9-with-lock-in-on-timeout method, it is no longer possible to abstain from activating it if it is shown to contain a critical flaw.

I suggest that a second version bit can be used as an abandonment vote; with sufficient hashpower (50% might be enough since it is no longer about safe coordination of protocol change deployment) the proposed protocol change is abandoned. This changes the dynamic from BIP9's "opt-in" to an "opt-out" system, still governed by hashpower, but far less susceptible to minority miner veto.

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

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

[Ryan Grant]

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.

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

[praxeology_guy]

[-- 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 --]

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

[Ryan Grant]

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.

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

[praxeology_guy]

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

shaolinfry,

Not sure if you noticed my comments on your earlier orphaning proposal... but if you did you should already know that I really like this proposal... particularly since orphaning valid old blocks is completely unnecessary.

I really like how you pulled out the "lockinontimeout" variable so that this same method could be used in future softfork proposals... instead of hardcoding a special case hack for SegWit.

- it would be nice if the user could set this variable in a configuration file.
- it would be nice if the user could set the "nTimeout" in "src/chainparams.cpp" in a configuratoin file too. This could be used allow a user to expedite when a softfork would become active on his node when combined with ."lockinontimeout".

Developers such as the Core team could put more conservative values in the program, and then community members such as miners and nodes who feel more strongly about SegWit could either compile their own settings or maybe copy a popular configuration file if such was made possible.

Cheers,
Praxeology Guy

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

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

[shaolinfry]

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

After some thought I managed to simplify the original uaversionbits proposal introducing a simple boolean flag to guarantee lock-in of a BIP9 deployment by the timeout. This seems to be the simplest form combining optional flag day activation with BIP9. This brings the best of both worlds allowing user activated soft forks that can be activated early by the hash power.

Specification: https://github.com/shaolinfry/bips/blob/bip-uavb/bip-uaversionbits.mediawiki
Previous discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html

<pre>
BIP: ?
Title: Version bits extension with guaranteed lock-in
Author: Shaolin Fry <shaolinfry@protonmail.ch>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
Status: Draft
Type: Informational
Created: 2017-02-01
License: BSD-3-Clause
CC0-1.0
</pre>

==Abstract==

This document specifies an extension to BIP9 that introduces an additional activation parameter to guarantee activation of backward-compatible changes (further called "soft forks").

==Motivation==

BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and is also subject to veto by a small minority of non-signalling hashrate.

This specification provides a way to optionally guarantee lock-in at the end of the BIP9 timeout, and therefore activation.

==Specification==

This specification adds a new per-chain deployment parameter to the existing BIP9 specification as follows:

# The '''lockinontimeout''' boolean if set to true, will transition state to LOCKED_IN at timeout if not already ACTIVE.

===State transitions===

<img src="bip-uaversionbits/states.png" align="middle"></img>

The state transition workflow is exactly the same as in BIP9 with an additional rule: During the STARTED state if the '''lockinontimeout''' is set to true, the state will transition to LOCKED_IN when '''timeout''' is reached.

case STARTED:
// BIP9 specification follows
if (GetMedianTimePast(block.parent) >= timeout) {
return (fLockInOnTimeout == true) ? THRESHOLD_LOCKED_IN : THRESHOLD_FAILED
}
int count = 0;
walk = block;
for (i = 0; i < 2016; i++) {
walk = walk.parent;
if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) {
count++;
}
}
if (count >= threshold) {
return LOCKED_IN;
}
return STARTED;

=== Reference implementation ===

https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits

==Deployments==

A living list of deployment proposals can be found [[bip-0009/assignments.mediawiki|here]].

==Copyright==

This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.

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