Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-15 📝 Original message: > I would suggest more to ...
📅 Original date posted:2018-10-15
📝 Original message:
> 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181015/dca18600/attachment.html>;
📝 Original message:
> 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181015/dca18600/attachment.html>;