Payments below dust limit not trustless \ stacker news ~lightning

pull down to refresh

2141 sats \ 18 comments \ @BallLightning 11 Mar lightning

I just discovered that payments through the lightning network that are below the dust limit don't create HTLC at all. Without HTLC they are unenforsable and may lead to the sender losing money. When in the future the base layer has high fees, the dust limit may become as big as the price of a beer or a price of a pair of headphones - not so trivial sum of money (even more so in some places on the planet).

Has this been discussed anywhere?

view all related items

286 sats \ 2 replies \ @petertodd 11 Mar

Without HTLC they are unenforsable and may lead to the sender losing money.

Nope. I covered this in my big article on L2 protocols: https://petertodd.org/2024/covenant-dependent-layer-2-review

A L2 payment should have one of the following two properties:

Unilateral enforcement on-chain. Lightning generally has this as you can close a channel, and in the case of a non-dust HTLC, actually represent it on-chain. But, obviously this costs fees... which brings us to:
Economic enforcement: alternatively, ensure that the attacker can't profit from theft.

Dust HTLCs meet the second criteria because to steal the value of them you have to close a channel, which results in more transaction fees being ultimately spent than the HTLC is worth (FYI, while the dust HTLC is in flight, the value of it is just added to the transaction fee for the current commitment transaction --- the transaction that would be used to force-close the channel if necessary)

Sure, on occasion someone might lose a few sats from a counterparty closing a channel at the right moment to steal a dust HTLC. But this basically never happens because it's not an economically viable attack. Transaction fees eat up all the profits.

In fact, the dust limit isn't even the right criteria here! The way to choose between a "real" HTLC and a "dust" HTLC is to base it on current fee rates. Right now Lightning implementations arguably create too many real HTLC outputs that can't actually be profitably collected if the channel is in fact force-closed.

0 sats \ 1 reply \ @BallLightning OP 11 Mar

I have a little problem with this statement you made: "Sure, on occasion someone might lose a few sats from a counterparty closing a channel at the right moment to steal a dust HTLC".

I specifically wrote about the future where this amount may not be trivial.

But yeah, I can see many people actually knew that there is such a thing. I didn't know until today..

10 sats \ 0 replies \ @petertodd 11 Mar

I specifically wrote about the future where this amount may not be trivial.

But that's the thing, the game theory isn't about the HTLC amount being small. It's that closing a channel costs fees greater than the amount. So you can't make a profit from this attack.

We probably will have to tweak certain aspects of LN implementations to make sure this logic actually holds up in all cases. But the basic idea is sound.

210 sats \ 6 replies \ @justin_shocknet 11 Mar

Yes, here, every time I call scaling focused people with their fake L2's and shitfork proposals retards and scammers. It's also a long standing meme that millisats in Lightning are shitcoins.

There's nothing that can solve for the fact that if you do not have enough sats to make a chain transaction you are not using Bitcoin, because you literally can't.

Scammers pushing fake L2's like Ark claim they want to do so to scale to those that can't afford to use the chain, when that is in fact not possible because of this fundamental limitation. This "scale for the poors" virtue signal is the premise with which they attack Lightning and grift on its perceived underwhelming adoption: poors cannot afford Lightning channels because they are chain transactions.

Millisats for example in Lightning being is because they're meant to be used only for internal accounting and cannot be settled on chain, because the chain does not have floating point precision. The chain has a fixed supply of 2.1Q sats and that will never change, therefore the dust limit has an absolute floor.

This has 0 to do with high fees as fees could remain at 1 sat per byte forever and it would still take 5-6 digits of sats to be an economically viable sovereign user.

Reality is that given the distribution of Bitcoin it's effectively impossible to ever exceed a billion sovereign people/organizations due to the supply constraint and nothing more.

0 sats \ 5 replies \ @BallLightning OP 11 Mar

Actually payments via lightning below the dust limit are enforced, but only when the lightning payment is completed and the preimage has traversed the path to the sender and the channel states are updated. It is while the HTLC is in flight when what I am describing can happen.

21 sats \ 4 replies \ @justin_shocknet 11 Mar

To be settled on chain however the output still needs to be of a transactable size, so even once settled you still effectively need a larger aggregate.

0 sats \ 3 replies \ @BallLightning OP 11 Mar

Well, the output of the updated channel balance is exactly that. As I already stated that I am talking about the time when the payment is in flight.

You do know that without payments in flight there are two outputs in the commitment transaction, right? It goes without sating that these two outputs can be way bigger than any individual payment and way bigger than the dust limit. You also know that lightning updates the commitment transaction differently for payments above and below the dust limit, right?

21 sats \ 2 replies \ @justin_shocknet 11 Mar

these two outputs can be way bigger than any individual payment

Of course, that's the aggregate of the channel state, the point is that until that channel state is transactable in size that it's inherently trusted.

0 sats \ 1 reply \ @BallLightning OP 11 Mar

Hm... It is trusted because it can be enforced by force close. Payments above the dust limit can be enforced by the HTLC when force closing. The payments below this as far as I see are added to the miners fee in the commitment transaction so you can't really enforce it by force close. This may or may not be a real problem, but I haven't really seen it discussed.

view all 1 replies

21 sats \ 2 replies \ @nullcount 11 Mar

You can use LN more trustlessly by simply requiring a MIN_HTLC above the dust limit for your node/channels. Of course, you'd no longer be able to receive payments below that amount.

LN was never a fully-trustless protocol.

The node that opens a channel also pays the onchain fee to close it. If you're worried about your channel peers making you lose money from below-dust payments, then just realize that you're already trusting every peer not to close the channels you opened to them (especially during a high-fee environment)

0 sats \ 1 reply \ @nullcount 11 Mar

Hot take but... All the LN is just BTC-backed IOUs being traded back-and-forth. Its almost like wBTC except there's no blockchain and no central issuer. Every LN node is like a private sidechain, they can each issue "LN-enabled BTC tokens" which are fungible with one-another and include more decimals of precision. Nodes track the txns of these tokens on their own internal ledgers, periodically pegging in/out with "real BTC".

Its a set of tradeoffs that many seem to think makes LN "not a shitcoin" and it works to solve many of the practical problems that people have when transacting with onchain BTC.

10 sats \ 0 replies \ @DarthCoin 12 Mar

wrong. Are not IOU. Are real sats that are not yet broadcast on the chain.

0 sats \ 2 replies \ @Filiprogrammer 11 Mar

I remember reading a proposal for an Offchain Payment Resolution (OPR) protocol where an HTLC does not add any outputs to the channel state transactions: https://delvingbitcoin.org/t/a-fast-scalable-protocol-for-resolving-lightning-payments/1233

This is ideal for small payments. I can actually see a future where we use a combination of OPR for small payments and the existing Poon-Dryja payment channels for larger payments.

Edit: The author made a 1.1 version going into more detail: https://github.com/JohnLaw2/ln-opr/blob/main/opr_v1.1.pdf

0 sats \ 1 reply \ @BallLightning OP 11 Mar

The current implementation adds the funds in flight to the miner fees (so that the receiver is not incentivised to close the channel), but he can still make the other side lose money (the the reason can be nonmonetary). And multiple small payments can pass through a node.

21 sats \ 0 replies \ @Filiprogrammer 11 Mar

We can lower the value of max_accepted_htlcs to prevent flooding of a node with HTLCs. Also the bad actor will have to keep opening new channels to make others lose money. And opening channels incurs an on-chain fee. So the bad actor has no monetary gain out of it, it actually costs them sats too.

But I do agree that this is a theoretical problem

0 sats \ 1 reply \ @Wumbo 11 Mar

I am familiar with dust on chain but what is the dust limit for lightning?

Are we talking about less than a millisatoshi. (.00000000001 BTC)?

0 sats \ 0 replies \ @BallLightning OP 11 Mar

Well, today I found out that no HTLC on lightning is created for payments below the on-chain dust limit. The channel is updated so that the funds in flight go to the miner fees instead of a HTLC contract. The receiver/forwarder can't steal these money, but he can force the sender to lose them to the miner. So he doesn't have a monetary incentive to do so, but nevertheless he can force the sender to lose money.