>
> 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
Hi all,
Things have been quiet around channel jamming lately, but the vulnerability
it still there as much as it was before. I've participated in an (isolated)
mainnet channel jamming experiment (
11 matches
Mail list logo
