📅 Original date posted:2015-07-18
📝 Original message:
>As to BIP62 being out of date, can you point to specific things? They'll get fixed.
Just one thing, actually. The "Block validity" section references
version 3 blocks, but those are already used by the BIP66 softfork.
On Sat, Jul 18, 2015 at 10:50 AM, Peter Todd <pete at petertodd.org> wrote:
> On Sat, Jul 18, 2015 at 09:25:54AM -0700, Mark Friedenbach wrote:
>> On Sat, Jul 18, 2015 at 9:19 AM, Nick ODell <nickodell at gmail.com> wrote:
>>
>> > There doesn't seem to be any deployment timeline.
>> >
>>
>> Welcome to bitcoin development.
>>
>> At the moment we have only the capability to push out one soft fork vote at
>> a time. The uncontroversial aspects of BIP62 were rushed out as BIP66 in
>> response to an undisclosed vulnerability, as mentioned. I believe there is
>> consensus now that BIP65: CHECKLOCKTIMEVERIFY has higher deployment
>> priority, so it will be next. There is no deployment timeline for BIP62
>> because it is a low priority in this soft-fork logjam.
>
> A slight clarification: we do have the capability to push out more than
> one soft-fork *upgrade signaling* at a time, but this is very far from a
> vote because if miners decide not to upgrade there is no easy way to
> recover. The nVersion bits mechanism I co-authored with Pieter Wuille
> and Gregory Maxwell is closer to a vote because a soft-fork failing to
> go through has a clear and non-coercive outcome.
>
> For instance, if my own BIP65 had been accepted into v0.11.0 miners who
> had upgraded to v0.10.x/0.9.5 would have been signaling that they
> supported BIP66, while sumultaneously miners running v0.11.0 would be
> signalling that they supported both BIP66 and BIP65. As adoption
> increased BIP66 would trigger first, followed by BIP65. (theoretically
> both could trigger on the same block too)
>
> The problem is if miners had decided they didn't like BIP66 but wanted
> to implement BIP65 there would be no mechanism to do that - it depends
> on the details, but from the point of view of at least some nodes you
> likely would have hard-forked Bitcoin in the process of stopping the
> failed soft-fork.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000b675c4d825a10c278b8d63ee4df90a19393f3b6498fd073
Nick ODell [ARCHIVE] /
npub192…qwur0
2023-06-09 12:43:41
in reply to nevent1q…eqac
Author Public Key
npub192dh6dprqsvsrdeche436s9xunwnlyzpu7jl5j3d83nz62tgznrsnqwur0Published at
2023-06-09 12:43:41Event JSON
{
"id": "5b0f9551f5ca128efd3e3068cf3314fbfd1db87599baba30f5aa601a0f162c2b",
"pubkey": "2a9b7d3423041901b738be6b1d40a6e4dd3f9041e7a5fa4a2d3c662d296814c7",
"created_at": 1686314621,
"kind": 1,
"tags": [
[
"e",
"a859dce2c9cc841a5be8294d50ac395dcd85f4a25bee712ee1cc23781bfb221c",
"",
"root"
],
[
"e",
"d72175069fff6b7cb3a8df97eff28d1c2aeedf235a74da3e8667a5dc5d8e61dd",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-07-18\n📝 Original message:\n\u003eAs to BIP62 being out of date, can you point to specific things? They'll get fixed.\nJust one thing, actually. The \"Block validity\" section references\nversion 3 blocks, but those are already used by the BIP66 softfork.\n\nOn Sat, Jul 18, 2015 at 10:50 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e On Sat, Jul 18, 2015 at 09:25:54AM -0700, Mark Friedenbach wrote:\n\u003e\u003e On Sat, Jul 18, 2015 at 9:19 AM, Nick ODell \u003cnickodell at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e \u003e There doesn't seem to be any deployment timeline.\n\u003e\u003e \u003e\n\u003e\u003e\n\u003e\u003e Welcome to bitcoin development.\n\u003e\u003e\n\u003e\u003e At the moment we have only the capability to push out one soft fork vote at\n\u003e\u003e a time. The uncontroversial aspects of BIP62 were rushed out as BIP66 in\n\u003e\u003e response to an undisclosed vulnerability, as mentioned. I believe there is\n\u003e\u003e consensus now that BIP65: CHECKLOCKTIMEVERIFY has higher deployment\n\u003e\u003e priority, so it will be next. There is no deployment timeline for BIP62\n\u003e\u003e because it is a low priority in this soft-fork logjam.\n\u003e\n\u003e A slight clarification: we do have the capability to push out more than\n\u003e one soft-fork *upgrade signaling* at a time, but this is very far from a\n\u003e vote because if miners decide not to upgrade there is no easy way to\n\u003e recover. The nVersion bits mechanism I co-authored with Pieter Wuille\n\u003e and Gregory Maxwell is closer to a vote because a soft-fork failing to\n\u003e go through has a clear and non-coercive outcome.\n\u003e\n\u003e For instance, if my own BIP65 had been accepted into v0.11.0 miners who\n\u003e had upgraded to v0.10.x/0.9.5 would have been signaling that they\n\u003e supported BIP66, while sumultaneously miners running v0.11.0 would be\n\u003e signalling that they supported both BIP66 and BIP65. As adoption\n\u003e increased BIP66 would trigger first, followed by BIP65. (theoretically\n\u003e both could trigger on the same block too)\n\u003e\n\u003e The problem is if miners had decided they didn't like BIP66 but wanted\n\u003e to implement BIP65 there would be no mechanism to do that - it depends\n\u003e on the details, but from the point of view of at least some nodes you\n\u003e likely would have hard-forked Bitcoin in the process of stopping the\n\u003e failed soft-fork.\n\u003e\n\u003e --\n\u003e 'peter'[:-1]@petertodd.org\n\u003e 00000000000000000b675c4d825a10c278b8d63ee4df90a19393f3b6498fd073",
"sig": "eb4ade13c7d50bafa35d03f76adbd6e23e80b6db003c43d84db5d7334069c09d17f9e76970492d3033f80469857b500acf2155e4474bf097b5478f2ca69daec3"
}