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

[Kekcoin via bitcoin-dev]

> 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.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Ryan Grant via bitcoin-dev]

Praxeology Guy,

On Fri, Apr 7, 2017 at 12:56 PM, praxeology_guy
 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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[praxeology_guy via bitcoin-dev]

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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Ryan Grant via bitcoin-dev]

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

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

[shaolinfry via bitcoin-dev]

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


BIP: ?
Title: Version bits extension with guaranteed lock-in
Author: Shaolin Fry 
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


==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===



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 & 0xE000 == 0x2000 && (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.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev