Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Matt Corallo <lf-lists@mattcorallo.com>]

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 the code isn't too huge. I'd probably prefer slightly to waste another two version bits than add a bunch of code to the fork now (maybe we can take just a part of the bit-based approach and allow lower version numbers again after the fork reaches 95%?). Either way, a proper version of the bit-based soft forking mechanism should be implemented sooner rather than later (maybe merged unused, even).

Still, it is entirely possible that there is relatively little uptake on XT and a competing proposal has a lot of support before we want to ship a LTV fork, so it may all be moot (or we could choose option 1 to fix the XT fork for them - easily forking off XT miners when either fork happens so XT isn't vulnerable to the 25% attack without needing to mine a massive transaction on Bitcoin first :p).

Matt

On August 19, 2015 11:34:54 AM GMT+02:00, "Jorge Timón via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
>Seems like 3 is something we want to do no matter what and therefore
>is the "most future-proof" solution.
>I wonder if I can help with that (and I know there's more people that
>would be interested).
>Where's the current "non-full" nVersion bits implementation?
>Why implement a "non-full" version instead of going with the full
>implementation directly?
>
>
>On Wed, Aug 19, 2015 at 8:10 AM, Mark Friedenbach via bitcoin-dev
><bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 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, etc. soft-forks has been
>recently
>>> complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners.
>Both
>>> mine blocks with nVersion=0x20000007, which would falsely trigger
>the
>>> previously suggested implementation using the IsSuperMajority()
>>> mechanism and nVersion=4 blocks. Additionally while the
>>> XT/Not-Bitcoin-XT software claims to support Wuille/Todd/Maxwell's
>>> nVersion soft-fork mechanism(3) a key component of it - fork
>>> deadlines(3) - is not implemented.
>>>
>>>
>>> XT/Not-Bitcoin-XT behavior
>>> --------------------------
>>>
>>> Both implementations produce blocks with nVersion=0x20000007,
>>> or in binary: 0b001...111
>>>
>>> Neither implementation supports a fork deadline; both Not-Bitcoin-XT
>and
>>> XT will produce blocks with those bits set indefinitely under any
>>> circumstance, with the proviso that while XT has a hashing power
>>> majority, blocks it produces might not be part of the Bitcoin
>blockchain
>>> after Jan 11th 2016. (though this can flap back and forth if reorgs
>>> happen)
>>>
>>> Curiously the BIP101 draft was changed(4) at the last minute from
>using
>>> the nVersion bits compliant 0x20000004 block nVersion, to using two
>more
>>> bits unnecessarily. The rational for doing this is unknown; the git
>>> commit message associated with the change suggested "compatibility
>>> concerns", but what the concerns actually were isn't specified.
>Equally
>>> even though implementing the fork deadline would be very each in the
>XT
>>> implementation, this was not done. (the XT codebase has had almost
>no
>>> peer review)
>>>
>>>
>>> Options for CLTV/CSV/etc. deployment
>>> ------------------------------------
>>>
>>> 1) Plain IsSuperMajority() with nVersion=4
>>>
>>> This option can be ruled out immediately due to the high risk of
>>> premature triggering, without genuine 95% miner support.
>>>
>>>
>>> 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 & ~0x20000007
>>>
>>> This means that CLTV/CSV/etc. miners running Bitcoin Core would
>create
>>> blocks with nVersion=8, 0b1000. From the perspective of the
>>> CLTV/CSV/etc.  IsSuperMajority() test, XT/Not-Bitcoin-XT miners
>would be
>>> advertising blocks that do not trigger the soft-fork.
>>>
>>> For the perpose of soft-fork warnings, the highest known version can
>>> remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT
>blocks
>>> as well as a future nVersion bits implementation. Equally,
>>> XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an
>>> unknown bit set.
>>>
>>> When nVersion bits is implemented by the Bitcoin protocol, the plan
>of
>>> setting the high bits to 0b001 still works. The three lowest bits
>will
>>> be unusable for some time, but will be eventually recoverable as
>>> XT/Not-Bitcoin-XT mining ceases.
>>>
>>> Equally, further IsSuperMajority() softforks can be accomplished
>with
>>> the same masking technique.
>>>
>>> This option does complicate the XT-coin protocol implementation in
>the
>>> future. But that's their problem, and anyway, the maintainers
>>> (Hearn/Andresen) has strenuously argued(5) against the use of
>soft-forks
>>> and/or appear to be in favor of a more centralized mandatory update
>>> schedule.(6)
>>>
>>>
>>> 3) Full nVersion bits implementation
>>>
>>> The most complex option would be to deploy via full nVersion bits
>>> implementation using flag bit #4 to trigger the fork. Compliant
>miners
>>> would advertise 0x20000008 initially, followed by 0x20000000 once
>the
>>> fork had triggered. The lowest three bits would be unusable for
>forks
>>> for some time, although they could be eventually recovered as
>>> XT/Not-Bitcoin-XT mining ceases.
>>>
>>> The main disadvantage of this option is high initial complexity -
>the
>>> reason why IsSuperMajority() was suggested for CLTV/CSV in the first
>>> place. That said, much of the code required has been implemented in
>XT
>>> for the BIP101 hard-fork logic, although as mentioned above, the
>code
>>> has had very little peer review.
>>>
>>>
>>> References
>>> ----------
>>>
>>> 1) https://github.com/bitcoinxt/bitcoinxt
>>>
>>> 2) https://github.com/xtbit/notbitcoinxt
>>>
>>> 3) "Version bits proposal",
>>>     Pieter Wuille, May 26th 2015, Bitcoin-development mailing list,
>>>
>>>
>http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008282.html,
>>>     https://gist.github.com/sipa/bf69659f43e763540550
>>>
>>> 4)
>>>
>https://github.com/bitcoin/bips/commit/3248c9f67bd7fcd1d05b8db7c5c56e4788deebfe
>>>
>>> 5) "On consensus and forks - What is the difference between a hard
>and
>>> soft fork?",
>>>    Mike Hearn, Aug 12th 2015,
>>>   
>https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7
>>>
>>> 6) 2013 San Jose Bitcoin conference developer round-table
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>>>
>>> _______________________________________________
>>> 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
>>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev