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