From nickodell at gmail.com Sat Jul 18 19:48:32 2015 From: nickodell at gmail.com (Nick ODell) Date: Sat, 18 Jul 2015 13:48:32 -0600 Subject: [Lightning-dev] Lightning modifications draft paper In-Reply-To: <20150718165024.GG26863@muck> References: <87mvyvci2k.fsf@rustcorp.com.au> <20150718165024.GG26863@muck> Message-ID: >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 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 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