rich1.0npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxhttps://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxnjumphttps://nostr.ae📅 Original date posted:2020-10-13 📝 Original message: > > > 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. > > If the above is not done (i.e. if I only prepay Joost but not Rusty) then > it seems to me that the below remote attack is possible: > Indeed, the above isn't done. Z only prepays Joost, not rusty. > * I convince Rene to make a channel to me. > You may succeed, but Rene is probably not going to pay you a hold fee because you're untrusted. > * I connect to Joost. > * I prepay to Joost. > * I forward Me->Joost->Rusty->Rene->me. > * I am exploiting the pre-existing tr\*st that Rusty has to Joost, and > the tr\*st that Rene has to Rusty. > * When the HTLC reaches me, I dicker around and wait until it is about to > time out before ultimately failing. > * Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty. But most importantly: you will have paid hold fees to Joost for the long lock time of the htlc. This should keep you from even trying this attack. Thinking a little more deeply: it is in principle possible to give a > financial value to an amount of msat being locked for an amount of time. > For instance the C-Lightning `getroute` has a `riskfactor` argument which > is used in this conversion. > Basically, by being locked in an HTLC and later failing, then the > forwarding node loses the expected return on investment if instead the > amount were locked in an HTLC that later succeeds. > > Now, the cost on a forwarding node is based on the actual amount of time > that its outgoing HTLC is locked. > That is indeed the proposal, to give financial value to the sats and the htlc slot being locked for an amount of time. > When we consider multi-hop payments, then we should consider that the > initiator of the multi-hop payment is asking multiple nodes to put their > funds at risk. > > Thus, the initiator of a multi-hop payment should, in principle, prepay > for *all* the risk of *all* the hops. > > > If we do not enforce this, then an initiator of a multi-hop payment can > pay a small amount relative to the risk that *all* the hops are taking. > I understand that, but I think it might be a large enough shift in the incentives of the attacker. > Secondarily, we currently assume that forwarding nodes will, upon having > their outgoing HTLC claimed, seek to claim the incoming HTLC as quickly as > possible. > This is because the incoming HTLC would be locked and unuseable until they > claim their incoming HTLC, and the liquidity would not be usable for > earning more fees until the incoming HTLC is claimed and put into its pool > of liquidity. > However, if we make anything that is based on the time that a forwarding > node claims its incoming HTLC, then this may incentivize the forwarding > node to delay claiming the incoming HTLC. > Yes, that is the trust part again. > > > > 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. > > What happens if I charge a tiny hold feerate in msats/second, but end up > locking the funds for a week? > How does my peer know that even though I charge a tiny hold fee, I will > hold their funds hostage for a week? > That is the trust part also. > > > > 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. > > Well, onchain activity is fairly rare in practice, so I am uncertain about > the relative size of prepays compared to relative fees of onchain activity. > I imagine payment forwardings to be much more common than onchain > activity, thus the prepays can add up and be significant compared to fees > on onchain activity, thus the tr\*st being considered may end up being a > good fraction of the current tr\*st. > Fair point. If you are continuously overcharged on the hold fees, it may outweigh the once-in-a-channel-lifetime chain fees. But if all your payments through a specific node are delayed, it does get suspicious. Joost -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201013/e33007ce/attachment.html>