📅 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.
>
>
>
>
>
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 17:36:58
in reply to nevent1q…8zju
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Seen on
wss://relay.nostr.bandPublished at
2023-06-07 17:36:58Event JSON
{
"id": "40d2fdd1af37cceaf14349f454a785ab55b900eb39cdb2d334a2ec01dc0d6416",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686159418,
"kind": 1,
"tags": [
[
"e",
"7b6db0ce13f47e3b2db7907716169da0107cc63b6d57e20477da59a8b07dbb21",
"",
"root"
],
[
"e",
"8474e2fa5c38a99bec56b755b587c8bf16022ad77ba5c81c4d95b26ce3a7ae46",
"",
"reply"
],
[
"p",
"fdf31024ca0537ed828d895ddc8525f8af023f0dc935a8327a8a496d0d7a9f83"
]
],
"content": "📅 Original date posted:2015-08-19\n📝 Original message:I don't think just using version=4 for cltv and friends would be a\nproblem if it wasn't for the XT/nonXT issue.\n\nOn Wed, Aug 19, 2015 at 12:20 PM, Btc Drak \u003cbtcdrak at gmail.com\u003e wrote:\n\u003e On Wed, Aug 19, 2015 at 10:34 AM, Jorge Timón\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e Seems like 3 is something we want to do no matter what and therefore\n\u003e\u003e is the \"most future-proof\" solution.\n\u003e\u003e I wonder if I can help with that (and I know there's more people that\n\u003e\u003e would be interested).\n\u003e\u003e Where's the current \"non-full\" nVersion bits implementation?\n\u003e\u003e Why implement a \"non-full\" version instead of going with the full\n\u003e\u003e implementation directly?\n\u003e\n\u003e\n\u003e There is a simple answer to this, convenience: versionbits has not been\n\u003e implemented yet, and I believe the BIP is still in review stage. As it seems\n\u003e likely the remaining locktime pull requests will be ready by or before the\n\u003e next major release, we need a deployment method if versionbits is not ready\n\u003e (which is unlikely because no-one appears to be working on it at the\n\u003e moment). Pieter indicated he is OK with another IsSuperMajority() rollout in\n\u003e the interim. Personally, I dont think we should let perfection be the enemy\n\u003e of progress here because at the end of the day, the deployment method is\n\u003e less important than the actual featureset being proposed.\n\u003e\n\u003e That said, the features in the next soft fork proposal are all related and\n\u003e best deployed as one featureset softfork, but moving forward, versionbits\n\u003e seems essential to be able to roll out multiple features in parallel without\n\u003e waiting for activation and enforcement each time.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e",
"sig": "8e4e3c1c41a64d6f1d66d784ba4bf863464cf888de6772e4f0c5d35acaca5716ee78646d8a7e8e8f49d196c5ecab42ce474b794fbce874dc73fd497f4621c4a7"
}