From laolu32 at gmail.com Mon Jun 25 19:35:41 2018 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Mon, 25 Jun 2018 12:35:41 -0700 Subject: [Lightning-dev] Including a Protocol for splicing to BOLT In-Reply-To: References: Message-ID: Hi Ren?, Speaking at a high level, the main differ between modifying autopilot strategies (channel bootstrapping, and maintenance) vs something like splicing, is that the former is purely policy while the latter is actually a protocol modifications. With respect to difficulty, the first option (in lnd at least) requires a dev to work solely on a high level (implementing a series of "pure" interfaces), on the other hand something like splicing requires a bit more low-level knowledge of Bitcoin, the protocol, and also specific details of an implementation (funding channels, signing, sync, etc). Splicing is likely something to be included (along with many other things on our various wish lists) within BOLT 1.1, which will start to be "officially" drafted late fall of this year. However of course it's possible for implementations to start to draft up working versions, reserving a temporary feature bit. > They people from lightning labs told me that they are currently started > working on splicing Yep, I have a branch locally that has started a full async version of splicing. Mostly started to see if any implementation level details would be a surprise, compared to how we think it all should work in our heads. > but even though it seems technically straight forward t Well the full async implementation may be a bit involved, depending on the architecture of the implementation (see the second point below). In the abstract, I'd say a splicing proposal should include the following: * a generic message for both splice in/out * this allows both sides to schedule/queue up possible changes, opportunistically piggy-backing then on top of the other sides initiation * most of the channel params can also be re-negotiated as this point, another upside is this effectively allows garbage collecting old revocation state * fully async splice in/out * async is ideal as we don't need to block channel operation for confirmations, this greatly improves the UX of the process * async splice in should use a technique similar to what Conner has suggested in the past [0], otherwise it would need to block :( * a sort of pre-announcement gossip messages * purpose of this is to signal to other nodes "hey this channel is about to change outpoints, but you can keep routing through it" * otherwise, if this doesn't exist, then nodes would interpret the action as a close then open of a channel, rather than a re-allocation Jumping down to a lower level detail, the inclusion of a sort of "scheduler" for splicing can also allow implementations to greatly batch all their operations. One example is using a splicing session initiated by the remote party to open channels, send regular on-chain payments, CPFP pending sweeps/commitments, etc. [0]: https://github.com/lightningnetwork/lightning-rfc/issues/280#issuecomment-388269599 -- Laolu On Mon, Jun 25, 2018 at 3:10 AM Ren? Pickhardt via Lightning-dev < lightning-dev at lists.linuxfoundation.org> wrote: > Hey everyone, > > I found a mail from 6 month ago on this list ( c.f.: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-December/000865.html ) > in which it was stated that there was a plan to include a splicing protocol > as BOLT 1.1 (On a side node I wonder weather it would make more sense to > include splicing to BOLT 3?) I checked out the git repo and issues and > don't see that anyone is currently working on that topic and that it hasn't > been included yet. Am I correct? > If noone works on this at the moment and the spec is still needed I might > take the initiative on that one over the next weeks. If someone is working > on this I would kindly offer my support. > > The background for my question: Last weekend I have been attending the 2nd > lightninghackday in Berlin and we had quite some intensive discussions > about the autopilot feature and splicing. (c.f. a summary can be found on > my blog: > https://www.rene-pickhardt.de/improve-the-autopilot-of-bitcoins-lightning-network-summary-of-the-bar-camp-session-at-the-2nd-lightninghackday-in-berlin > ) > > They people from lightning labs told me that they are currently started > working on splicing but even though it seems technically straight forward > the protocols should also be formalized. Previously I planned working on > improving the intelligence of the autopilot feature of the lightning > network however on the weekend I got convinced that splicing should be much > higher priority and the process should be specified in the lightning rfc. > > Also it would be nice if someone would be willing to help out improving > the quality of the spec that I would create since it will be my first time > adding work to such a formal rfc. > > best Rene > > > -- > www.rene-pickhardt.de > > > Skype: rene.pickhardt > > mobile: +49 (0)176 5762 3618 <+49%20176%2057623618> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: