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 <btcd...@gmail.com> wrote: > On Wed, Aug 19, 2015 at 10:34 AM, Jorge Timón > <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? > > > 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. > > > > > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
