Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-13 📝 Original message: > > > The idea is that ...
📅 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>;
📝 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>;