I have changed BIPS 112 and 113 to reflect this amended deployment
strategy. I'm beginning to think the issues created by Bitcoin XT are
so serious it probably deserves converting OPs text into an
informational BIP.
On Thu, Aug 20, 2015 at 6:42 PM, Mark Friedenbach via bitcoin-dev
Peter Todd via bitcoin-dev 於 2015-08-19 01:50 寫到:
2) nVersion mask, with IsSuperMajority()
In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would
be masked away, prior to applying standard IsSuperMajority() logic:
block.nVersion ~0x2007
This means that
No, the nVersion would be = 4, so that we don't waste any version values.
On Thu, Aug 20, 2015 at 10:32 AM, jl2012 via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Peter Todd via bitcoin-dev 於 2015-08-19 01:50 寫到:
2) nVersion mask, with IsSuperMajority()
In this option the
Wait, why did Bitcoin-XT use that nVersion???
Definitely option 3 is much cleaner technically, and it would be nice to have
that code implemented, but I'd be rather concerned about the size of the fork
ballooning. It's already four separate features in one fork, which seems pretty
big, even if
I don't think just using version=4 for cltv and friends would be a
problem if it wasn't for the XT/nonXT issue.
On Wed, Aug 19, 2015 at 12:20 PM, Btc Drak btcd...@gmail.com wrote:
On Wed, Aug 19, 2015 at 10:34 AM, Jorge Timón
bitcoin-dev@lists.linuxfoundation.org wrote:
Seems like 3 is
We can use nVersion 0x8 to signal support, while keeping the consensus
rule as nVersion = 4, right? That way we don't waste a bit after this all
clears up.
On Aug 18, 2015 10:50 PM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Deployment of the proposed CLTV, CSV,
Deployment of the proposed CLTV, CSV, etc. soft-forks has been recently
complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners. Both
mine blocks with nVersion=0x2007, which would falsely trigger the
previously suggested implementation using the IsSuperMajority()
mechanism and
