ZmnSCPxj <[email protected]> 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.
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
