ZmnSCPxj [ARCHIVE] on Nostr: š Original date posted:2020-10-12 š Original message: Good morning Joost, I ...
š
Original date posted:2020-10-12
š Original message:
Good morning Joost,
I would like some clarifications on this mechanism.
> 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.
> 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?
> 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.)
How about this?
Before, when thinking about JIT routing, I suggested that a JIT-routing enabled forwarding node should only be willing to pay for the JIT rebalancing up to some fraction (less than 1.0) of the amount already earned from the outgoing channel, in order to protect against some attacks.
And when the JIT-routing node does a rebalance in order to serve the forwarding, it should deduct the cost of the rebalance from its cumulative sum of earnings from that outgoing channel.
The effect of the above is that the already-earned forwarding fees serves as a "level of trust" that the rebalancing in order to serve the outgoing forward will not be wasted.
Perhaps intermediate nodes should limit incoming HTLCs from peers that have not given them a lot of successful forwards and earned forwarding fees from those forwards.
i.e. if it is a new peer, you allow HTLCs up to a certain size, then if the outgoing HTLC is claimed quickly rather than slowly and you earn a good amount of fee, you might be willing to increase the limits of incoming HTLCs.
This is effectively "growing trust".
Of course, now we have to wonder about exit scams where a node manipulates you into increasing this "trust score" and later screwing you over when you are willing to accept larger total HTLCs.... Sigh.
On the other hand, if you base this on the amount of fees you earn per unit time and deducting the converted risk of having your fees locked in outgoing HTLCs, then attackers have to effectively pay you forwarding fees first before they can attack you, and once they attack, they lose the accumulated score.
So in some way, this system functions a little like pre-paid fees, except the pre-payment is in the actual pay-on-successful-forwarding of previous HTLCs you have forwarded.
Maybe.
Regards,
ZmnSCPxj
š Original message:
Good morning Joost,
I would like some clarifications on this mechanism.
> 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.
> 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?
> 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.)
How about this?
Before, when thinking about JIT routing, I suggested that a JIT-routing enabled forwarding node should only be willing to pay for the JIT rebalancing up to some fraction (less than 1.0) of the amount already earned from the outgoing channel, in order to protect against some attacks.
And when the JIT-routing node does a rebalance in order to serve the forwarding, it should deduct the cost of the rebalance from its cumulative sum of earnings from that outgoing channel.
The effect of the above is that the already-earned forwarding fees serves as a "level of trust" that the rebalancing in order to serve the outgoing forward will not be wasted.
Perhaps intermediate nodes should limit incoming HTLCs from peers that have not given them a lot of successful forwards and earned forwarding fees from those forwards.
i.e. if it is a new peer, you allow HTLCs up to a certain size, then if the outgoing HTLC is claimed quickly rather than slowly and you earn a good amount of fee, you might be willing to increase the limits of incoming HTLCs.
This is effectively "growing trust".
Of course, now we have to wonder about exit scams where a node manipulates you into increasing this "trust score" and later screwing you over when you are willing to accept larger total HTLCs.... Sigh.
On the other hand, if you base this on the amount of fees you earn per unit time and deducting the converted risk of having your fees locked in outgoing HTLCs, then attackers have to effectively pay you forwarding fees first before they can attack you, and once they attack, they lose the accumulated score.
So in some way, this system functions a little like pre-paid fees, except the pre-payment is in the actual pay-on-successful-forwarding of previous HTLCs you have forwarded.
Maybe.
Regards,
ZmnSCPxj