Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-12 📝 Original message: > > > A. Prepayment: node ...
📅 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>;
📝 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>;