ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-13 📝 Original message: Good morning Joost, > > ...
📅 Original date posted:2021-02-13
📝 Original message:
Good morning Joost,
> > Not quite up-to-speed back into this, but, I believe an issue with using feerates rather than fixed fees is "what happens if a channel is forced onchain"?
> >
> > Suppose after C offers the HTLC to D, the C-D channel, for any reason, is forced onchain, and the blockchain is bloated and the transaction remains floating in mempools until very close to the timeout of C-D.
> > C is now liable for a large time the payment is held, and because the C-D channel was dropped onchain, presumably any parameters of the HTLC (including penalties D owes to C) have gotten fixed at the time the channel was dropped onchain.
>
> > The simplicity of the fixed fee is that it bounds the amount of risk that C has in case its outgoing channel is dropped onchain.
>
> The risk is bound in both cases. If you want you can cap the variable fee at a level that isn't considered risky, but it will then not fully cover the actual cost of the locked-up htlc. Also any anti-DoS fee could very well turn out to be insignificant to the cost of closing and reopening a channel with the state of the mempool these days.
I think the problem of accidental channel closure is getting ignored by devs.
If we think any anti-DoS fee will be "insignificant" compared to the cost of closing and reopening a channel, maybe dev attention should be on fixing accidental channel closure costs than any anti-DoS fee mechanism.
Any deterrence of the channel jamming problem is economic so if the anti-DoS fee is tiny, then its deterrence will be tiny as well.
It seems to me that adding this anti-DoS fee *on top of* an accidental channel closure is just adding insult to injury, when we should probably be considering how to ameliorate the injury.
Otherwise forwarding nodes will themselves be deterred from operating at all.
> > Is assuming increasing `hodl_fee_rate` along a payment path at odds with the ordering of timelocks ?
>
> I don't think it is.
In terms of privacy, this is more dangerous.
The decrementing timelock already leaks an upper bound on the distance to payee.
An incrementing holdfee leaks an upper bound on the distance to payer.
This translates to a single payment-part being more easily associated with the payer and payee.
Regards,
ZmnSCPxj
📝 Original message:
Good morning Joost,
> > Not quite up-to-speed back into this, but, I believe an issue with using feerates rather than fixed fees is "what happens if a channel is forced onchain"?
> >
> > Suppose after C offers the HTLC to D, the C-D channel, for any reason, is forced onchain, and the blockchain is bloated and the transaction remains floating in mempools until very close to the timeout of C-D.
> > C is now liable for a large time the payment is held, and because the C-D channel was dropped onchain, presumably any parameters of the HTLC (including penalties D owes to C) have gotten fixed at the time the channel was dropped onchain.
>
> > The simplicity of the fixed fee is that it bounds the amount of risk that C has in case its outgoing channel is dropped onchain.
>
> The risk is bound in both cases. If you want you can cap the variable fee at a level that isn't considered risky, but it will then not fully cover the actual cost of the locked-up htlc. Also any anti-DoS fee could very well turn out to be insignificant to the cost of closing and reopening a channel with the state of the mempool these days.
I think the problem of accidental channel closure is getting ignored by devs.
If we think any anti-DoS fee will be "insignificant" compared to the cost of closing and reopening a channel, maybe dev attention should be on fixing accidental channel closure costs than any anti-DoS fee mechanism.
Any deterrence of the channel jamming problem is economic so if the anti-DoS fee is tiny, then its deterrence will be tiny as well.
It seems to me that adding this anti-DoS fee *on top of* an accidental channel closure is just adding insult to injury, when we should probably be considering how to ameliorate the injury.
Otherwise forwarding nodes will themselves be deterred from operating at all.
> > Is assuming increasing `hodl_fee_rate` along a payment path at odds with the ordering of timelocks ?
>
> I don't think it is.
In terms of privacy, this is more dangerous.
The decrementing timelock already leaks an upper bound on the distance to payee.
An incrementing holdfee leaks an upper bound on the distance to payer.
This translates to a single payment-part being more easily associated with the payer and payee.
Regards,
ZmnSCPxj