Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-03 🗒️ Summary of this message: The author ...

📅 Original date posted:2023-08-03
🗒️ Summary of this message: The author clarifies their intention to encourage research on monetary-based denial-of-service deterrence and provides a rough proof-of-work as an approach to explore. They also discuss the challenges of implementing fees based on the time an HTLC is held.
📝 Original message:
On Mon, Jul 31, 2023 at 02:42:29PM -0400, Clara Shikhelman wrote:
> > A different way of thinking about the monetary approach is in terms of
> > scaling rather than deterrance: that is, try to make the cost that the
> > attacker pays sufficient to scale up your node/the network so that you
> > continue to have excess capacity to serve regular users.

Just to clarify, my goal for these comments was intended to be mostly
along the lines of:

"I think monetary-based DoS deterrence is still likely to be a fruitful
area for research if people are interested, even if the current
implementation work is focussed on reputation-based methods"

At least the way I read the summit notes, I could see people coming away
with the alternative impression; ie "we've explored monetary approaches
and think there's nothing possible there; don't waste your time", and
mostly just wanted to provide a counter to that impression.

The scheme I outlined was mostly provided as a rough proof-of-work to
justify thinking that way and as perhaps one approach that could be
researched further, rather than something people should be actively
working on, let alone anything that should distract from working on the
reputation-based approach.

After talking with harding on irc, it seems that was not as obvious in
text as it was in my head, so just thought I'd spell it out...

> As for liquidity DoS, the “holy grail” is indeed charging fees as a
> function of the time the HTLC was held. As for now, we are not aware of a
> reasonable way to do this.

Sure.

> There is no universal clock,

I think that's too absolute a statement. The requirement is either that
you figure out a way of using the chain tip as a clock (which I gave a
sketch of), or you setup local clocks with each peer and have a scheme
for dealing with them being slightly out of sync (and probably use the
chain tip as a way of ensuring they aren't very out of sync).

> and there is no way
> for me to prove that a message was sent to you, and you decided to pretend
> you didn't.

All the messages in the scheme I suggested involve commitment tx updates
-- either introducing/closing a HTLC or making a payment for keeping a
HTLC active and tying up your counterparty's liquidity. You don't need to
prove that messages were/weren't sent -- if they were, your commitment
tx is already updated to deal with it, if they weren't but should have
been, your channel is in an invalid state, and you close it onchain.

To me, proving things seems like something that comes up in reputation
based approaches, where you need to reference a hit on someone else's
reputation to avoid taking a hit on yours, rather than a monetary based
one, where all you should need to do is check you got paid for whatever
service you were providing, and conversely pay for whatever services
you've been requiring.

> It can easily happen that the fee for a two-week unresolved
> HTLC is higher than the fee for a quickly resolving one.

That should be the common case, yes, and it's problematic if you can have
both a high percentage fee (or a high amount), and a distant timeout.
But that may be a situation you can avoid, and I gave a sketch of one
way you could do that.

> I think this is another take on time-based fees. In this variation, the
> victim is trying to take a fee from the attacker. If the attacker is not
> willing to pay the fee (and why would they?), then the victim has to force
> close. There is no way for the victim to prove that it is someone
> downstream holding the HTLC and not them.

The point is that you get paid for your liquidity beind held hostage;
whether the channel is closed or stays open. If that works, there's
no victim in this scenario -- you set a price for your liquidity to be
reserved over time in the hope that the payment will eventually succeed,
and you get paid that fee, until whoever currently holds the HTLC the
chance of success isn't worth the ongoing cost anymore.

The point of force closing it the same as any force close -- your
counterparty stops following the protocol you both agreed to. That can
happy any time, even just due to cosmic rays.

> > > - They’re not large enough to be enforceable, so somebody always has
> > > to give the money back off chain.
> > If the cap is 500ppm per block, then the liquidity fees for a 2000sat
> > payment ($0.60) are redeemable onchain.
> This heavily depends on the on-chain fees, and so will need to be
> updated as a function of that, and adds another layer of complication.

I don't think that's true -- this is just a direct adjustment to the
commitment tx balance outputs, so doesn't change the on-chain size/cost
of the commitment tx.

The link to on-chain fees (at least in the scheme I outlined) is via
the cap (for which I gave an assumed value above) -- you don't want the
extra profit your counterparty would get from from that adjustment to
outweigh something like sum(their liquidity value of locking their funds
up due to a unilateral close; the unilateral close fees that they pay;
channel reopening costs).

One thing I wonder a bit about is if it might be easier to mess around
with some of these ideas somewhere that supported millisat/picobtc values
natively (and perhaps also had low fees), that way you don't have to
worry as much about the difference between things that are included in
the commitment tx versus are just hopefully true due to the friction of
closing/reopening channels. You could probably make picobtc precision
happen on-chain with an issued asset on Liquid, if you didn't mind
limiting it to 2100BTC total (~$63M), and perhaps put issuance under a
smart contract that automatically swaps it for L-BTC at a 1-1M ratio.
Unfortunately, probably a lot of hassle to set that up, let alone adapt
a lightning client to sit on top of it though.

Cheers,
aj