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