Peter Todd [ARCHIVE] on Nostr: š Original date posted:2015-07-18 š Original message: On Sat, Jul 18, 2015 at ...
š
Original date posted:2015-07-18
š Original message:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150719/4c48df02/attachment.sig>;
š Original message:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150719/4c48df02/attachment.sig>;