Adam Back [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-30 📝 Original message:I think from discussion ...

📅 Original date posted:2015-09-30
📝 Original message: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 at lists.linuxfoundation.org> wrote:
> "Wladimir J. van der Laan via bitcoin-dev"
> <bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev