Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-19 📝 Original message:Seems like 3 is something ...
📅 Original date posted:2015-08-19
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>