📅 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.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 13:03:00
in reply to nevent1q…fwda
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 13:03:00Event JSON
{
"id": "7f0bc5cfd780b045412586d9f9adbce9355f52eeb67b288faaa13825ee587dac",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315780,
"kind": 1,
"tags": [
[
"e",
"5b939faaa8b1530f86472b2f9c4dc55b9f8dea6f71ca80ce3563af20d2a12ae1",
"",
"root"
],
[
"e",
"a8b9f981b374f8822b8a69895cfb0ee71df53b725af67b1d9d5471476a10521a",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-07-05\n📝 Original message:\nZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e writes:\n\u003e 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 ---\n\u003e\n\u003e In light of dual-funding we should avoid \"funder\" and \"fundee\" in favor of \"initiator\" and \"acceptor\".\n\nYes, Lisa has a patch for this in her spec PR :)\n\n\u003e 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.\n\u003e\n\u003e * 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).\n\u003e * 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.\n\nThis misses an important case: even with the dual-funding prototol,\nsingle-sided funding is more common.\n\nSo:\n - if your peer hasn't contributed funds:\n - You are in control, channel is safe (modulo your own conf issues)\n - if the peer has contributed funds:\n - You can send, since cancellation just gives you a free refund (if\n you contributed anything at all).\n - You should not route an incoming HTLCs (unless you trust peer)\n\nCheers,\nRusty.",
"sig": "9e133ac00cf3eb0f2131ddb3c5a02ab1e3a450e69b3aa64e11c6f7bc6c22abfb8f270786ad0983f08bed8eb4669cb75e677040c4e7f2fd60163d307e3660927b"
}