I think from discussion with Gavin sometime during the montreal scaling bitcoin workshop, XT maybe willing to make things easy and adapt what it's doing. For example in relation to versionBits Gavin said he'd be willing to update XT with an updated/improved versionBits, for example.
It seems more sensible to do what is simple and clean and have both core do that, and XT follow if there is no particular philosophy debate on a given technical topic. This seems a quite constructive approach. Adam On 30 September 2015 at 00:05, Rusty Russell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > "Wladimir J. van der Laan via bitcoin-dev" > <bitcoin-dev@lists.linuxfoundation.org> writes: >> On Sun, Sep 27, 2015 at 02:50:31PM -0400, Peter Todd via bitcoin-dev wrote: >> >>> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY. >> >> There appears to be common agreement on that. >> >> The only source of some controversy is how to deploy: versionbits versus >> IsSuperMajority. I think the versionbits proposal should first have code >> out there for longer before we consider it for concrete softforks. Haste-ing >> along versionbits because CLTV is wanted would be risky. > > Agreed. Unfortunately, a simple "block version >= 4" check is > insufficient, due to XT which sets version bits 001....111. > > Given that, I suggest using the simple test: > > if (pstart->nVersion & 0x8) > ++nFound; > > Which means: > 1) XT won't trigger it. > 2) It won't trigger XT. > 3) You can simply set block nVersion to 8 for now. > 4) We can still use versionbits in parallel later. > > Cheers, > Rusty. > _______________________________________________ > 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
