Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-19 📝 Original message:I don't think just using ...
📅 Original date posted:2015-08-19
📝 Original message: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 <btcdrak at gmail.com> wrote:
> On Wed, Aug 19, 2015 at 10:34 AM, Jorge Timón
> <bitcoin-dev at 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?
>
>
> There is a simple answer to this, convenience: versionbits has not been
> implemented yet, and I believe the BIP is still in review stage. As it seems
> likely the remaining locktime pull requests will be ready by or before the
> next major release, we need a deployment method if versionbits is not ready
> (which is unlikely because no-one appears to be working on it at the
> moment). Pieter indicated he is OK with another IsSuperMajority() rollout in
> the interim. Personally, I dont think we should let perfection be the enemy
> of progress here because at the end of the day, the deployment method is
> less important than the actual featureset being proposed.
>
> That said, the features in the next soft fork proposal are all related and
> best deployed as one featureset softfork, but moving forward, versionbits
> seems essential to be able to roll out multiple features in parallel without
> waiting for activation and enforcement each time.
>
>
>
>
>
📝 Original message: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 <btcdrak at gmail.com> wrote:
> On Wed, Aug 19, 2015 at 10:34 AM, Jorge Timón
> <bitcoin-dev at 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?
>
>
> There is a simple answer to this, convenience: versionbits has not been
> implemented yet, and I believe the BIP is still in review stage. As it seems
> likely the remaining locktime pull requests will be ready by or before the
> next major release, we need a deployment method if versionbits is not ready
> (which is unlikely because no-one appears to be working on it at the
> moment). Pieter indicated he is OK with another IsSuperMajority() rollout in
> the interim. Personally, I dont think we should let perfection be the enemy
> of progress here because at the end of the day, the deployment method is
> less important than the actual featureset being proposed.
>
> That said, the features in the next soft fork proposal are all related and
> best deployed as one featureset softfork, but moving forward, versionbits
> seems essential to be able to roll out multiple features in parallel without
> waiting for activation and enforcement each time.
>
>
>
>
>