<p>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.</p>

<p>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". </p>

<p>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.</p>

<p>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.</p>

<p>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).</p>

<p>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.</p>

<p>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.</p>

<p>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).</p>

CC BY-SA 4.0
2019-05-20T23:49:05.117Z
_“and an attaker would have to burn quite a bit more in fees to trigger it”_. Incorrect. The losing routing party also loses more on-chain fees than the value of the micropayment lost if they decide to close the channel. Also given the need for channel liquidity, the little guys just have to eat these thefts as a cost of being accepted to channel with a Mt. Box node. Given the microtxn is hidden in the fee, there’s no way to even objectively prove malfeasance.
Shelby Moore III
CC BY-SA 4.0
2019-05-21T00:00:27.370Z
The attacker pays the fees in that case.
G. Maxwell
CC BY-SA 4.0
2019-05-21T00:13:45.267Z
Each party to the channel has to pay on-chain transaction fees to open the channel. If the losing party wishes to close the channel to penalize the attacker, then losing party also pays more total fees than the value lost to the attacker. How do you figure that only the attacker pays fees?
Shelby Moore III
CC BY-SA 4.0
2019-05-21T00:25:59.223Z
Essentially AFAICS there’s no incentives compatibility at all for transactions valued at less than (or even slightly greater than) the on-chain transaction fees involved with opening and closing the channel. Because neither counterparty to the channel has an incentive to lose those fees (to penalize their counterparty for malfeasance) and incur more fees to open a replacement channel.
Shelby Moore III
CC BY-SA 4.0
2019-03-29T01:19:52.497Z
2019-03-29T01:45:43.030Z
2019-03-29T01:45:43.030Z
G. Maxwell
<p>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. </p>

CC BY-SA 4.0
2019-03-27T08:40:42.463Z
Can the relay node intercept micropayments? Is the "trimmed HTLC output" turned into transaction fee? Does this have temporary impact on in-flight payments only, or permanent impacts?
Chris Chen
CC BY-SA 4.0
2019-03-27T14:43:17.843Z
I have honestly no idea what you are asking about. Are you taking about relay lightning node or relay Bitcoin node? What do you mean with in flight payment? Maybe a general thought you could look in the BOLTs for specifics with htlcs and commitment transactions. I think BOLT 05 should cover most of it. If things are unclear maybe the terminology used there would help me to understand your information need so that I can help out.
Rene Pickhardt
CC BY-SA 4.0
2019-12-26T18:38:47.207Z
After reading @G.Maxwell 's answer, I think I have got the answer to the third question: this issue only has temporary impact on in-flight payment. However, I'm still not convinced that, merely the fact that "on-chain fee is more costly than the affected amount" would disincentivize exploiting this issue, just like the case in reality that: if legal costs are too high, the innocent party might just choose to take the unjust loss. (sorry for my broken english)
Chris Chen
CC BY-SA 4.0
2019-03-27T07:25:06.090Z
2019-03-27T07:25:06.090Z
Rene Pickhardt
<p>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.</p>

<p>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 <em>dust limit.</em>  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.</p>

<p>Currently, when LN nodes are asked to route payments below the dust limit, they
<a href="https://elementsproject.org/features/opcodes" rel="noreferrer">trim</a> 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:</p>

<ol>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ol>

<p>Peter Rizun has
<a href="https://medium.com/@peter_r/visualizing-htlcs-and-the-lightning-networks-dirty-little-secret-cb9b5773a0" rel="noreferrer">argued</a> 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."</p>

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

<ol>
<li><p>The amounts involved are currently tiny (about $0.02 at $4,000 USD/BTC).</p></li>
<li><p>Node operators who want to eliminate their risk can simply refuse to route
micropayments below the dust limit.</p></li>
<li><p>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).  </p></li>
</ol>

<p>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
<a href="https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&amp;pli=1#slide=id.g85f425098_0_195" rel="noreferrer">described</a>
how this might be accomplished.</p>

<h2>Removing trust from inexpressible values</h2>

<p>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.</p>

<p>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).</p>

<p>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.</p>

<p>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.</p>

<p>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
<a href="https://elementsproject.org/features/opcodes" rel="noreferrer"><code>OP_DETERMINISTICRANDOM</code></a> 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.</p>

<h2>Probabilistic payments to circumvent the dust limit</h2>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<h2>Addendum: an easier, less clever way to circumvent the dust limit</h2>

<p>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.</p>

<p>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.</p>

<p>(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.)</p>

CC BY-SA 4.0
2019-03-29T09:58:19.420Z
I like your idea with the double htlcs. Would you consider sending this to the lightning dev Mailinglist? It would currently be hard to do this with the way the protocol sets up and settles htlcs. Also the commitment tx would be bigger and would have to  have an even higher onchain fee
Rene Pickhardt
CC BY-SA 4.0
2019-03-29T15:33:23.267Z
@RenePickhardt I think the double HTLC idea isn't particularly satisfying, as (1) it just gets around the dust limit not the fundamental problem, (2) the dust limit isn't really an issue today, and (3) as Maxwell mentions in his answer to this question, the limit would probably be removed (or at least not be increased) if fees were consistently above the default minimum.  Maybe a better easy solution to high uneconomical outputs is allowing people to set their risk values and using multipath payments to use whatever capacity is available: https://twitter.com/hrdng/status/1111541536548929536
David A. Harding
CC BY-SA 4.0
2019-04-04T16:43:46.210Z
Would mimble wimble be able to solve this problem, since the size of transactions in that system aren't dependent on a number of outputs?
B T
CC BY-SA 4.0
2019-05-20T22:50:45.870Z
Probabilistic payments won’t work for the same math reason that non-pooled mining doesn’t work— variance. Users could be waiting weeks, months, and eventually years to ever get paid anything. Especially given [BTC is going to $1 million within 4 years](https://medium.com/@shelby_78386/yes-the-correct-fractal-model-shows-that-btc-is-going-to-1-million-in-less-than-4-years-ccbad1b290f). Peter Rizun is repeating a [long-standing criticism I have made against LN](https://medium.com/@shelby_78386/peter-thanks-for-popularizing-my-long-standing-criticism-of-ln-1da1d6ec2540).
Shelby Moore III
CC BY-SA 4.0
2024-06-02T13:08:02.723Z
I don't see the problem. If I route payment, don't I already got a channel open? I had an upfront cost for the channel (the miners fee in the commitment transaction and the time it would take for me to reclaim my channel capacity bitcoin locked in the funding transaction). So if someone wants to route a micropayment through me I simple create a new transaction where I increase the balance in the correct direction.). Even if its the very first transaction I route for someone, wouldn't the fee already be high in the first commitment transaction?
user2741831
CC BY-SA 4.0
2019-03-28T21:59:48.840Z
2019-03-29T07:34:47.100Z
2019-03-29T07:34:47.100Z
David A. Harding
<p>I read <a href="https://twitter.com/tdryja/status/1101858335144529921?s=19" rel="noreferrer">this tweet by Tadge Dryja</a> recently. What exactly did he mean? Is this an issue? If so, is this issue fixable?</p>

<p><a href="https://i.sstatic.net/uQEJY.png" rel="noreferrer"><img src="https://i.sstatic.net/uQEJY.png" alt="Tweet by Tadge: &quot;HTLCs don&#39;t work for micropayments (below tx fee level), though single satoshi payments can be securely made within a channel.  Pretending 1-satoshi HTLCs are a thing is setting people up to be disappointed...&quot;"></a></p>

<lightning-network><micropayments><hash-time-locked-contract>
"HTLCs don't work for micropayments"?
Chris Chen
# "HTLCs don't work for micropayments"?

(Asked by: username_0 on 2019-03-27)

I read [this tweet by Tadge Dryja](https://twitter.com/tdryja/status/1101858335144529921?s=19) recently. What exactly did he mean? Is this an issue? If so, is this issue fixable?

[![Tweet by Tadge: "HTLCs don't work for micropayments (below tx fee level), though single satoshi payments can be securely made within a channel.  Pretending 1-satoshi HTLCs are a thing is setting people up to be disappointed..."](https://i.sstatic.net/uQEJY.png)](https://i.sstatic.net/uQEJY.png)

**Tags:** lightning-network, micropayments, hash-time-locked-contract


---

## 3 answers

### Answer by username_4 on 2019-03-28. Score: 15 | Accepted answer

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](https://elementsproject.org/features/opcodes) 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](https://medium.com/@peter_r/visualizing-htlcs-and-the-lightning-networks-dirty-little-secret-cb9b5773a0) 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](https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098_0_195)
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`](https://elementsproject.org/features/opcodes) 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.)

> **Comments:**
> **username_3**: I like your idea with the double htlcs. Would you consider sending this to the lightning dev Mailinglist? It would currently be hard to do this with the way the protocol sets up and settles htlcs. Also the commitment tx would be bigger and would have to  have an even higher onchain fee  
> **username_4**: @username_3 I think the double HTLC idea isn't particularly satisfying, as (1) it just gets around the dust limit not the fundamental problem, (2) the dust limit isn't really an issue today, and (3) as username_1 mentions in his answer to this question, the limit would probably be removed (or at least not be increased) if fees were consistently above the default minimum.  Maybe a better easy solution to high uneconomical outputs is allowing people to set their risk values and using multipath payments to use whatever capacity is available: https://twitter.com/hrdng/status/1111541536548929536  
> **username_5**: Would mimble wimble be able to solve this problem, since the size of transactions in that system aren't dependent on a number of outputs?  
> **username_2**: Probabilistic payments won’t work for the same math reason that non-pooled mining doesn’t work— variance. Users could be waiting weeks, months, and eventually years to ever get paid anything. Especially given [BTC is going to $1 million within 4 years](https://medium.com/@shelby_78386/yes-the-correct-fractal-model-shows-that-btc-is-going-to-1-million-in-less-than-4-years-ccbad1b290f). Peter Rizun is repeating a [long-standing criticism I have made against LN](https://medium.com/@shelby_78386/peter-thanks-for-popularizing-my-long-standing-criticism-of-ln-1da1d6ec2540).  
> **username_6**: I don't see the problem. If I route payment, don't I already got a channel open? I had an upfront cost for the channel (the miners fee in the commitment transaction and the time it would take for me to reclaim my channel capacity bitcoin locked in the funding transaction). So if someone wants to route a micropayment through me I simple create a new transaction where I increase the balance in the correct direction.). Even if its the very first transaction I route for someone, wouldn't the fee already be high in the first commitment transaction?  

---

### Answer by username_1 on 2019-03-29. Score: 8

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).

> **Comments:**
> **username_2**: _“and an attaker would have to burn quite a bit more in fees to trigger it”_. Incorrect. The losing routing party also loses more on-chain fees than the value of the micropayment lost if they decide to close the channel. Also given the need for channel liquidity, the little guys just have to eat these thefts as a cost of being accepted to channel with a Mt. Box node. Given the microtxn is hidden in the fee, there’s no way to even objectively prove malfeasance.  
> **username_1**: The attacker pays the fees in that case.  
> **username_2**: Each party to the channel has to pay on-chain transaction fees to open the channel. If the losing party wishes to close the channel to penalize the attacker, then losing party also pays more total fees than the value lost to the attacker. How do you figure that only the attacker pays fees?  
> **username_2**: Essentially AFAICS there’s no incentives compatibility at all for transactions valued at less than (or even slightly greater than) the on-chain transaction fees involved with opening and closing the channel. Because neither counterparty to the channel has an incentive to lose those fees (to penalize their counterparty for malfeasance) and incur more fees to open a replacement channel.  

---

### Answer by username_3 on 2019-03-27. Score: 4

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.

> **Comments:**
> **username_0**: Can the relay node intercept micropayments? Is the "trimmed HTLC output" turned into transaction fee? Does this have temporary impact on in-flight payments only, or permanent impacts?  
> **username_3**: I have honestly no idea what you are asking about. Are you taking about relay lightning node or relay Bitcoin node? What do you mean with in flight payment? Maybe a general thought you could look in the BOLTs for specifics with htlcs and commitment transactions. I think BOLT 05 should cover most of it. If things are unclear maybe the terminology used there would help me to understand your information need so that I can help out.  
> **username_0**: After reading @G.username_1 's answer, I think I have got the answer to the third question: this issue only has temporary impact on in-flight payment. However, I'm still not convinced that, merely the fact that "on-chain fee is more costly than the affected amount" would disincentivize exploiting this issue, just like the case in reality that: if legal costs are too high, the innocent party might just choose to take the unjust loss. (sorry for my broken english)  

---

