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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
