[Lightning-dev] Turbo channels spec?

[ZmnSCPxj]

Good morning Rusty,

> ZmnSCPxj ZmnSCPxj at protonmail.com writes:
>
> > Mostly nitpick on terminology below, but I think text substantially like the above should exist in some kind of "rationale" section in the BOLT, so ---
> > In light of dual-funding we should avoid "funder" and "fundee" in favor of "initiator" and "acceptor".
>
> Yes, Lisa has a patch for this in her spec PR :)
>
> > So what matters for the above rationale is the "sender" of an HTLC and the "receiver" of an HTLC, not really who is acceptor or initiator.
> >
> > -   Risks for HTLC sender is that the channel never confirms, but it probably ignores the risk because it can close onchain (annoying, and fee-heavy, but not loss of funds caused by peer).
> > -   Risks for HTLC receiver is that the channel never confirms, so HTLC must not be routed out to others or resolved locally if the receiver already knows the preimage, UNLESS the HTLC receiver has some other reason to trust the peer.
>
> This misses an important case: even with the dual-funding prototol,
> single-sided funding is more common.
>
> So:
>
> -   if your peer hasn't contributed funds:
>     -   You are in control, channel is safe (modulo your own conf issues)

Hmm.

In single-funding, if you sent out an HTLC, got the preimage, then now your peer has funds in the channel.
If you do this before the channel confirms, then the peer can send to you, and you can accept it safely without concern since your peer cannot block the channel confirmation.

So yes, it seems correct.


Regards,
ZmnSCPxj