{"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-13\n📝 Original message:\n\u003e\n\u003e \u003e The idea is that the available prepaid hold fee balance is enough to\n\u003e cover the worst case hold fee. Otherwise the forward won't happen. The main\n\u003e difference with option B is that you pay a sum upfront which can be used to\n\u003e cover multiple forwards. And that this payment is a separate Lightning\n\u003e payment, not integrated with the add/fail/settle flow. I prefer option B,\n\u003e but implementation effort is also a consideration.\n\u003e\n\u003e If the above is not done (i.e. if I only prepay Joost but not Rusty) then\n\u003e it seems to me that the below remote attack is possible:\n\u003e\n\nIndeed, the above isn't done. Z only prepays Joost, not rusty.\n\n\n\u003e * I convince Rene to make a channel to me.\n\u003e\n\nYou may succeed, but Rene is probably not going to pay you a hold fee\nbecause you're untrusted.\n\n\n\u003e * I connect to Joost.\n\u003e * I prepay to Joost.\n\u003e * I forward Me-\u003eJoost-\u003eRusty-\u003eRene-\u003eme.\n\u003e   * I am exploiting the pre-existing tr\\*st that Rusty has to Joost, and\n\u003e the tr\\*st that Rene has to Rusty.\n\u003e * When the HTLC reaches me, I dicker around and wait until it is about to\n\u003e time out before ultimately failing.\n\u003e * Rusty loses tr\\*st in Joost, and Rene loses tr\\*st in Rusty.\n\n\nBut most importantly: you will have paid hold fees to Joost for the long\nlock time of the htlc. This should keep you from even trying this attack.\n\nThinking a little more deeply: it is in principle possible to give a\n\u003e financial value to an amount of msat being locked for an amount of time.\n\u003e For instance the C-Lightning `getroute` has a `riskfactor` argument which\n\u003e is used in this conversion.\n\u003e Basically, by being locked in an HTLC and later failing, then the\n\u003e forwarding node loses the expected return on investment if instead the\n\u003e amount were locked in an HTLC that later succeeds.\n\u003e\n\u003e Now, the cost on a forwarding node is based on the actual amount of time\n\u003e that its outgoing HTLC is locked.\n\u003e\n\nThat is indeed the proposal, to give financial value to the sats and the\nhtlc slot being locked for an amount of time.\n\n\n\u003e When we consider multi-hop payments, then we should consider that the\n\u003e initiator of the multi-hop payment is asking multiple nodes to put their\n\u003e funds at risk.\n\u003e\n\u003e Thus, the initiator of a multi-hop payment should, in principle, prepay\n\u003e for *all* the risk of *all* the hops.\n\u003e\n\u003e\n\u003e If we do not enforce this, then an initiator of a multi-hop payment can\n\u003e pay a small amount relative to the risk that *all* the hops are taking.\n\u003e\n\nI understand that, but I think it might be a large enough shift in the\nincentives of the attacker.\n\n\n\u003e Secondarily, we currently assume that forwarding nodes will, upon having\n\u003e their outgoing HTLC claimed, seek to claim the incoming HTLC as quickly as\n\u003e possible.\n\u003e This is because the incoming HTLC would be locked and unuseable until they\n\u003e claim their incoming HTLC, and the liquidity would not be usable for\n\u003e earning more fees until the incoming HTLC is claimed and put into its pool\n\u003e of liquidity.\n\u003e\nHowever, if we make anything that is based on the time that a forwarding\n\u003e node claims its incoming HTLC, then this may incentivize the forwarding\n\u003e node to delay claiming the incoming HTLC.\n\u003e\n\nYes, that is the trust part again.\n\n\n\u003e \u003e \u003e \u003e B. Tightly integrated with the htlc add/fail/settle messages. When\n\u003e an htlc is added, the maximum cost (based on maximum lock time) for holding\n\u003e is deducted from the sender's channel balance. When the htlc settles, a\n\u003e refund is given based on the actual lock time. An additional\n\u003e `update_fee`-like message is added for peers to update their hold fee\n\u003e parameters (fee_base and fee_rate).\n\u003e \u003e \u003e\n\u003e \u003e \u003e If I am a forwarding node, and I receive the preimage from the\n\u003e outgoing HTLC, can I deliberately defer claiming the incoming HTLC\n\u003e (pretending that the outgoing HTLC was taking longer than it actually took)\n\u003e in order to reduce the amount I have to refund?\n\u003e \u003e\n\u003e \u003e Yes you can. That is the trust part, your peer trusts you not to do\n\u003e this. If they don't trust you, they won't forward to you if you charge a\n\u003e (high) hold fee.\n\u003e\n\u003e What happens if I charge a tiny hold feerate in msats/second, but end up\n\u003e locking the funds for a week?\n\u003e How does my peer know that even though I charge a tiny hold fee, I will\n\u003e hold their funds hostage for a week?\n\u003e\n\nThat is the trust part also.\n\n\n\u003e \u003e \u003e \u003e In both cases the sender needs to trust its peer to not steal the\n\u003e payment and/or artificially delay the forwarding to inflate the hold fee. I\n\u003e think that is acceptable given that there is a trust relation between peers\n\u003e already anyway.\n\u003e \u003e \u003e\n\u003e \u003e \u003e I am wary of *adding* trust.\n\u003e \u003e \u003e You might trust someone to keep an eye on your snacks while you go\n\u003e refill your drink, but not to keep an eye on your hardware wallet when you\n\u003e do the same.\n\u003e \u003e \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 \u003e\n\u003e \u003e So I am arguing that there is trust already between peers. Quite\n\u003e considerable trust even in case of high on-chain fee conditions. The added\n\u003e risk of being scammed out of these prepay sats may not be significant.\n\u003e\n\u003e Well, onchain activity is fairly rare in practice, so I am uncertain about\n\u003e the relative size of prepays compared to relative fees of onchain activity.\n\u003e I imagine payment forwardings to be much more common than onchain\n\u003e activity, thus the prepays can add up and be significant compared to fees\n\u003e on onchain activity, thus the tr\\*st being considered may end up being a\n\u003e good fraction of the current tr\\*st.\n\u003e\n\nFair point. If you are continuously overcharged on the hold fees, it may\noutweigh the once-in-a-channel-lifetime chain fees. But if all your\npayments through a specific node are delayed, it does get suspicious.\n\nJoost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201013/e33007ce/attachment.html\u003e"}