"HTLCs don't work for micropayments"?

Question

I read this tweet by Tadge Dryja recently. What exactly did he mean? Is this an issue? If so, is this issue fixable?

Answer 1

It takes about 200 vbytes to spend from a Lightning Network (LN) Hashed Time-Locked Contract (HTLC) output used for routing a payment. At the default minimum feerate of 10 nBTC/vbyte, that makes it uneconomical to attempt to claim a routed micropayment below about 2,000 nBTC ($0.008 USD at $4,000 USD/BTC). As fees rise, larger and larger micropayments become uneconomical to claim.

Worse, the default Bitcoin Core mempool policy attempts to prevent UTXO-set bloat attacks by refusing to relay or mine any transaction containing an output that would be uneconomical to spend at a feerate of 30 nBTC/vbyte. This is called the dust limit. To obey this limit, LN nodes must not include HTLCs for very small micropayments in LN offchain transactions---otherwise those transactions couldn't be confirmed onchain if necessary and other value in the channel could be stolen by a counterparty.

Currently, when LN nodes are asked to route payments below the dust limit, they trim those HTLCs by increasing the potential transaction fee of their channel by the amount of the micropayment rather than adding an HTLC. This fee only actually pays miners if the channel is closed in a state that includes this fee---by mutual agreement between channel counterparties, the fee can be removed in a later state. This creates three possible outcomes:

1. The fee is removed in a later state because both peers agree that the micropayment completed successfully, so the amount is trasfered into a normal-size output that's not subject to the dust limit.

2. The fee is removed in a later state because both peers agree that the micropayment failed (either it was rejected or it timed out). The earlier state where the funds were held in a larger output is restored.

3. The two peers get into a disagreement about the payment and close the channel. In this case, the funds are actually transfered to miners and are lost to whichever channel party was technically correct about the final payment state.

Peter Rizun has argued that, combined with rising Bitcoin transaction fees, this can lead to "the problem where even $50 payments are not 'trustless.' In the case where $50 is below the dust threshold [...], then HTLCs cannot be used to protect the $50 payment. Customers can lose $50 payments through no fault of their own."

It seems like he might be correct, although there are a few evasions we could make about the current network behavior:

1. The amounts involved are currently tiny (about $0.02 at $4,000 USD/BTC).

2. Node operators who want to eliminate their risk can simply refuse to route micropayments below the dust limit.

3. Those willing to accept limited risk can limit their maximum exposure (e.g. only routing up to 10 payments below $0.02 for a maximum risk of $0.20).

However, what we really want is a fundamental solution to this risk---a way to make even micropayments trustless. Happily, the person quoted in the question---Thaddeus Dryja (one of the original LN architects)---previously described how this might be accomplished.

Removing trust from inexpressible values

Above we described micropayments below the dust limit, which is a relay and mining policy (meaning it can be changed without needing global consensus). However, LN also allows micropayments down to 10 pBTC, which is 1/1,000th the consensus-enforced 10 nBTC maximum precision of onchain Bitcoin.

When a channel contains some value that can't be represented onchain, the remaining value is tracked in a database and LN commitments are made using rounding. For example, if 6 nBTC are paid from Alice's side of a channel to Bob's side of a channel, she might actually send him 10 nBTC in an offchain transaction and the extra 4 nBTC are tracked in a database to be credited towards subsequent payments. If the channel is closed at this point, Alice accepts that she's going to lose those 4 nBTC ($0.00002 USD at $4,000 USD/BTC).

Given the tiny amounts involved, that seems like a perfectly satisfactory solution---Bob's unlikely to pay an onchain transaction fee of 4,000 nBTC just to steal 4 nBTC from Alice. But, in early LN presentations, Dryja proposed an alternative technique based on something occasionally discussed among Bitcoin protocol developers: probabilistic payments.

Probabilistic payments are payments that only succeed a specified percentage of the time. For example, Alice wants to pay Bob 1 nBTC, but that's smaller than allowed by Bitcoin. Instead she offers him a probabilistic payment of 10 nBTC (the smallest Bitcoin does allow) with 1-in-10 odds. Nine times out of ten, Bob gets nothing; one time in ten, he gets 10 nBTC. If this is done with a provably fair protocol and the distribution amounts are symmetric to the odds (i.e. there's no house edge), then it's reasonable to believe that receiving 10 nBTC 1/10th of the time is equivalent to receiving 1 nBTC each time.

The exact mechanism described by Dryja is complicated and I don't know how well it's been reviewed for security. A large problem faced by all ideas for probabilistic payments on Bitcoin is that they're hard or impossible to implement in Bitcoin's very limited Script language. Sidechains based on ElementsProject.org, such as Blockstream Liquid, have re-enabled some disabled math opcodes from Bitcoin plus added an OP_DETERMINISTICRANDOM opcode that make probabilistic payments much easier to implement there (although I'm unaware of any specific work on a definite protocol). Perhaps someday, these opcodes or other similar features will become available on Bitcoin if there is community demand for them.

Probabilistic payments to circumvent the dust limit

In the previous section, we saw probabilistic payments used to trustlessly get around the minimum consensus precision of 10 nBTC. We can use the same mechanism to get around the dust limit trustlessly. If it's uneconomical to spend an HTLC output worth less than 10,000 nBTC, then we simply require probabilistic payments for any amount below that.

For example, Alice wants to route a 1,000 nBTC payment through Bob. Bob requires her to create an HTLC paying him 10,000 nBTC with a 1-in-10 chance of success. Then the LN is processed. If both Alice and Bob agree that it failed, they throw away the HTLC. If they both agree it succeeded, Alice simply adds 1,000 nBTC to a larger output of Bob's, circumventing the dust limit. If they disagree and the transaction needs to go onchain, the probabilistic payment is run and, nine times out of ten, Bob receives nothing (Alice gets her 10,000 nBTC back). One time out of ten, Bob receives 10,000 nBTC. This can be made completely trustless, provably fair, and doesn't require any third parties.

As mentioned above, probabilistic payments are currently a lot of work to implement on Bitcoin and effective use of them may rely on soft forks that are just ideas now. Moreover, while transaction fees are low and Bitcoin valuations still make dust-size outputs worth just pennies, there's no real need to work on complex solutions to the problem of people maybe losing a few cents---people who don't want that risk can simply disable routing payments below about $0.02. But if this becomes a real problem, it's a problem I think we can reasonably expect to solve in a completely trustless way.

Addendum: an easier, less clever way to circumvent the dust limit

Several hours after posting the description above, it occurred to me that there's an easier way to create trustless payments below the dust limit that doesn't depend on untested probabilistic payments. If Alice wants to route a 1,000 nBTC payment through Bob but the minimum economical onchain HTLC is 10,000 nBTC, she and Bob simply create two offchain outputs at the same time: one where Alice pays Bob 11,000 nBTC and one where Bob pays Alice 10,000 nBTC. Both HTLCs use the same hashlock and timelock, so they can both succeed or timeout at the same time. The net effect is a 1,000 nBTC payment to Alice if the offchain payment needs to be settled onchain, plus the regular ability for them to agree on the outcome and update their main balances cooperatively.

Downsides include that this requires that Alice and Bob keep more balance in their side of a channel than they otherwise would in order to handle micropayments and that it costs them more fee overall. This additional burden can be compensated by them charging a higher fee for routing payments below the economical onchain rate. This method also solves the problem in a completely trustless way and it's something that shouldn't require significant research to implement, although it's still perhaps a premature optimization while the current risk is measured in pennies.

(Probabilistic payments are still the only way I know to deal with payments below the minimum onchain precision of 10 nBTC, but that's not the question here.)

Answer 2

A very low value output in Bitcoin (or any similar system) has zero actual value because the cost in fees to spend it would be equal to or greater than the coins it provides. Like someone writing you a check for $0.01, you'd be best off throwing it out because the time it takes to handle it (much less the tiny risk that it bounces and causes you a bounced check fee!) is much more valuable than the penny it pays you.

The argument being made here is that in multi-hop lightning payments, during the brief window when a payment is being made but has not completed, the participants sign ephemeral transactions that pay the amount being paid to a new output whos spending is governed by the hash lock. This is needed in order to make the payment atomic (guaranteeing that all hops succeeded or all fail). Once the payment is complete, this temporary state is replaced with an updated long term state. This is needed because during that time each hop's payment of that new incremental amount is conditional "I'll pay you this coin, only if I got paid that coin".

The combination of the two presents a challenge: making a very tiny payment on chain doesn't make sense because of the cost of eventually using it, so the threat of taking that hash-lock intermediate state to the network is essentially an empty threat.

Lightning implementations today resolve this by instead making their intermediate state take tiny payments payment and move them temporarily to fees, rather than to an uneconomical output. This creates security through game theory: breaking the payment would just cause none of the participants to get the tiny amount, and an attaker would have to burn quite a bit more in fees to trigger it.

Considering that Bitcoin's security in general rests on similar game theoretic assumptions this isn't all that remarkable, but lighting payments for larger values have much stronger properties (such that Bitcoin's consensus is, at least theoretically, the limiting factor in their security by a wide margin).

It's worth observing that lightning supports payments down to something like 10 pico-bitcoin, far smaller than the resolution of Bitcoin itself so the system inherently is always going to have to have some approximation for very small amounts but 'small' doesn't just mean what is representable by the blockchain it also means what is economically sensible there.

I think it's unfortunate that people are talking about "dust" in this discussion, because the 'dust limit' doesn't really have any fundamental relevance, other than that during low fee periods the limit might artificially increase the cutoff point below which the HTLC output becomes an empty threat. I suspect that if feerates hadn't tanked after the introduction of segwit implementations probably would have removed the dust limit policy rules in any case: they're a kludge that compensates for fees being too low to dissuade various antisocial behaviors like spamming for advertising purposes or de-anonymizing users and don't serve much purpose if feerates are consistently high enough to discourage these attacks.

I'm not sure if any of the more modern lightning protocol work like eltoo changes this trade-off as I don't think most people working on lightning have even given it much thought-- the existing incentives for very small payments seem reasonable enough. This consideration also doesn't apply to single hop payments-- they are limited only by the channel amount and the representable increments between the amounts--, though I doubt any lightning implementations make use of that fact (given that they don't seem to think it's especially interesting).

Answer 3

An htlc is a small output in the commitment transaction. As with any output it needs to be bigger than the dust limit. In particular if the amount is smaller than the expected on chain transaction transaction fee to spend it it becomes economically unviable.