rich1.0npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxhttps://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxnjumphttps://nostr.ae📅 Original date posted:2020-10-12 📝 Original message: > > > A. Prepayment: node pays an amount to its channel peer (for example via > keysend) and the channel peer deducts the hold fees from that prepaid > balance until it is at zero. At that point it somehow (in the htlc fail > message?) communicates Lightning's version of http 402 to ask for more > money. > > If the node has already forwarded the HTLC onward, what enforcement hold > does the node have on the sender of the incoming HTLC? > Presumably the sender of the HTLC has already gotten what it wanted --- an > outgoing HTLC --- so how can the forwarding node enforce this request to > get more money. > The idea is that the available prepaid hold fee balance is enough to cover the worst case hold fee. Otherwise the forward won't happen. The main difference with option B is that you pay a sum upfront which can be used to cover multiple forwards. And that this payment is a separate Lightning payment, not integrated with the add/fail/settle flow. I prefer option B, but implementation effort is also a consideration. > B. Tightly integrated with the htlc add/fail/settle messages. When an > htlc is added, the maximum cost (based on maximum lock time) for holding is > deducted from the sender's channel balance. When the htlc settles, a refund > is given based on the actual lock time. An additional `update_fee`-like > message is added for peers to update their hold fee parameters (fee_base > and fee_rate). > > If I am a forwarding node, and I receive the preimage from the outgoing > HTLC, can I deliberately defer claiming the incoming HTLC (pretending that > the outgoing HTLC was taking longer than it actually took) in order to > reduce the amount I have to refund? > Yes you can. That is the trust part, your peer trusts you not to do this. If they don't trust you, they won't forward to you if you charge a (high) hold fee. > In both cases the sender needs to trust its peer to not steal the payment > and/or artificially delay the forwarding to inflate the hold fee. I think > that is acceptable given that there is a trust relation between peers > already anyway. > > I am wary of *adding* trust. > You might trust someone to keep an eye on your snacks while you go refill > your drink, but not to keep an eye on your hardware wallet when you do the > same. > (Since consuming snacks and drinks and hardware wallets are human > activities, this should show that I am in fact a human.) > So I am arguing that there is trust already between peers. Quite considerable trust even in case of high on-chain fee conditions. The added risk of being scammed out of these prepay sats may not be significant. Joost -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201012/bff0c536/attachment.html>