Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in
> 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
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
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 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
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
Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in
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___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
