Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-05 📝 Original message: ZmnSCPxj <ZmnSCPxj at ...
📅 Original date posted:2021-07-05
📝 Original message:
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)
- if the peer has contributed funds:
- You can send, since cancellation just gives you a free refund (if
you contributed anything at all).
- You should not route an incoming HTLCs (unless you trust peer)
Cheers,
Rusty.
📝 Original message:
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)
- if the peer has contributed funds:
- You can send, since cancellation just gives you a free refund (if
you contributed anything at all).
- You should not route an incoming HTLCs (unless you trust peer)
Cheers,
Rusty.