>
> This struck me as an extremely salient point. One thing that has been
> noticeable missing from these discussions is any sort of threat model or
> attacker
> profile. Given this is primarily a griefing attack, and the attacker
> doesn't
> stand any direct gain, how high a fee is considered
> 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
To further illustrate the interactions of the hold fee rate proposal, I've
created a spreadsheet that calculates the fees for a three hop route:
https://docs.google.com/spreadsheets/d/1UX3nMl-L9URO3Vd49DBVaubs6fdi6wxSb-ziSVlF6eo/edit?usp=sharing
(if there was a way to paste a working spreadheet
> The risk of hitting the chain that you mention can be factored into this
> base part as well. The hold fee rate would then be defined in the form (2
> sat + 1%) per minute.
I think this works if the base fee is paid at HTLC commitment lock-in.
Otherwise, you're still exposed to the chain-hit
I've made a first attempt at projecting this idea onto the existing spec:
https://github.com/lightningnetwork/lightning-rfc/pull/843. This may also
clarify some of the questions that haven't been answered yet.
Joost
On Fri, Feb 12, 2021 at 2:29 PM Antoine Riard
wrote:
> Hi Joost,
>
> Thanks
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
Hi Antoine,
That said, routing nodes might still include the risk of hitting the chain
> in the computation of their `hodl_fee_rate` and the corresponding cost of
> having onchain timelocked funds.
>
Yes, that could be another reason to define `hodl_fee_rate` as a base fee
rate plus a component
Hi Joost,
Thanks for working on this and keeping raising awareness about channel
jamming.
> In this post I'd like to present a variation of bidirectional upfront
payments that uses a time-proportional hold fee rate to address the
limitation above. I also tried to come up with a system that aims
Hi ZmnSCPxj,
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
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
10 matches
Mail list logo
