Re: [Lightning-dev] Splicing Proposal: Feedback please!

[Christian Decker]

Olaoluwa Osuntokun  writes:
> Splicing isn't a substitute for allowing multiple channels. Multiple
> channels allow nodes to:
>
>   * create distinct channels with distinct acceptance policies.
>   * create a mix of public and non-advertised channels with a node.
>   * be able to send more than the (current) max HTLC amount
> using various flavors of AMP.
>   * get past the (current) max channel size value
>   * allow a link to carry more HTLCs (due to the current super low max HTLC
> values) given the additional HTLC pressure that
> AMP may produce (alternative is a commitment fan out)

While these are all good points, I think they are equally well served if
by creating channels to other peers. This has the added benefit of
reducing the node's reliance on a single peer. In fact it seems we are
currently encouraging users to have a small number of fat channels that
are manually maintained (dual-funding, splicing, multiple channels per
peer), rather than making the default to create a diverse set of
channels that allow indirectly routed payments.

Instead of obsessing about that one peer and hoping that that peer is
online when we need it, we should make routed payments a first-class
citizen. If we can route correctly and with confidence we can stop
worrying about that one peer and our connectivity to it. On the other
hand, if routing doesn't work, and people have to worry about that one
channel that connects them directly to the destination, then we're not
much of a network, but rather a set of disjoint channels.

Ultimately users should stop caring about individual channels or peer
relationships, and multipath routing gets us a long way there. I'd
really like to have a wallet that'll just manage channels in the
background and not expose those details to the users which just want to
send and receive payments, and we can start that now by de-emphasizing
the importance of the peer selection.

Regards,
Christian
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Splicing Proposal: Feedback please!

[Olaoluwa Osuntokun]

> I would suggest more to consider the simpler method, despite its larger
> onchain footprint (which is galling),

The on-chain footprint is a shame, and also it gets worse if we start to
allow multiple pending splices. Also the lack of a non-blocking splice in is
a big draw back IMO.

> but mostly because I do not see splicing as being as important as AMP or
> watchtowers (and payment decorrelation seems to affect how AMP can be
> implemented, so its priority also goes up).

Most of what you mention here have _very_ different deployment timelines and
synchronization requirements across clients. For example, splicing is a link
level change and can start to be rolled out immediately. Decorrelation on
the other hand, is a _network_ level change, and would take a considerable
amount of time to reach widespread deployment as it essentially splits the
rouble paths in the network until all/most are upgraded.

If you think any of these items is a higher priority than splicing then you
can simply start working on them! There's no agency that prescribes what
should and shouldn't be pursued or developed, just your willingness to
write some code.

One thing that I think we should lift from the multiple funding output
approach is the "pre seating of inputs". This is cool as it would allow
clients to generate addresses, that others could deposit to, and then have
be spliced directly into the channel. Public derivation can be used, along
with a script template to do it non-interactively, with the clients picking
up these deposits, and initiating a splice in as needed.

-- Laolu



On Thu, Oct 11, 2018 at 11:14 PM ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> Good morning Rusty,
>
> >
> > > It may be good to start brainstorming possible failure modes during
> splice, and how to recover, and also to indicate the expected behavior in
> the proposal, as I believe these will be the points where splicing must be
> designed most precisely. What happens when a splice is ongoing and the
> communication gets disconnected? What happens when some channel failure
> occurs during splicing and we are forced to drop onchain? And so on.
> >
> > Agreed, but we're now debating two fairly different methods for
> > splicing. Once we've decided on that, we can try to design the
> > proposals themselves.
>
> I would suggest more to consider the simpler method, despite its larger
> onchain footprint (which is galling), but mostly because I do not see
> splicing as being as important as AMP or watchtowers (and payment
> decorrelation seems to affect how AMP can be implemented, so its priority
> also goes up).  So I think getting *some* splicing design out would be
> better even if imperfect.  Others may disagree on priority.
>
> Regards,
> ZmnSCPxj
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev