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 <
[email protected]> 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
> <http://www.beijing-china-blog.com/>
>
> Skype: rene.pickhardt
>
> mobile: +49 (0)176 5762 3618 <+49%20176%2057623618>
> _______________________________________________
> Lightning-dev mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
