<p>Luke says it's NOT difficult...</p>
<p><a href="https://github.com/bitcoinknots/bitcoin/issues/74" rel="nofollow noreferrer">https://github.com/bitcoinknots/bitcoin/issues/74</a></p>
<blockquote>
<p>Dynamic dust limit #74</p>
<p>luke-jr commented on Mar 22 •  There is now (as of 26.1) experimental
(and disabled by default) support for dynamically adjusting the &quot;dust&quot;
spam filter threshold. It can be enabled in the GUI, or by configuring
-dustdynamic=target:N to adjust based on a fee estimate for confirmation within N blocks, or -dustdynamic=mempool:N to adjust
based on the worst fee in the best N kvB of your mempool. In either
mode, the fee will be adjusted every 15 minutes (the first time not
for 15 minutes after startup, in an effort to ensure estimators have
sufficient data to work with). Implementation details (including how
often adjustment occurs) may be changed in future releases.</p>
</blockquote>
<p>I would love to hear Murch's opinions on the functionality of this code, as it's obviously more complex than my elementary level coding proposal of</p>
<p>if (Tx &lt; TxFee) {isDust = True;}</p>
<p>While a 4 MB block full of 330 or 546 sat Txs each with 440,000 sat TxFees would be short-term good for miners, such incessant repetition would NOT be good for the Bitcoin Monetary SYSTEM, which is much, MUCH larger than miners. The long-term view of storing &amp; transferring value requires moving Txs that are larger than their Fees.</p>

CC BY-SA 4.0
2024-04-24T03:26:16.133Z
2024-04-24T03:26:16.133Z
DoctorBuzz1
<h3>At the wallet level</h3>
<p>Nothing prevents wallets from implementing reasonable safety measures to protect their users from undesirable behavior.</p>
<p>Bitcoin Core for example has a feature to (by default) reject the creation of transactions with a very high fee value. There is no specific rule to prevent fees higher than the amount transferred, but there certainly could be. Other wallet software may have similar and/or different preventative measures.</p>
<h3>At the policy level</h3>
<p>Policy rules exist to protect the network, not the individual node operator. A rule to prevent too high fees doesn't belong here, as it doesn't hurt the network.</p>
<p>Furthermore, it is <em>hard</em> to imagine what such a rule would look like, because the amount paid/transferred is <em>by design</em> not visible in the transaction (most transactions have change that is sent back to the sender, but which is indistinguishable from the &quot;payment&quot; output to outsiders).</p>
<p>The dust relay rule is intended to disincentivize the creation of transaction outputs which would be more expensive to <strong>spend</strong> than their value. Such outputs are likely to remain unspent in the UTXO set forever, slowly accumulating and eventually increasing node operation costs.</p>
<h3>At the consensus rule level</h3>
<p>The same considerations apply here as for policy rules, except they need to be agreed upon by the entire ecosystem, and are such much harder to change.</p>
<p>So far, this has meant no rules at all that relate to fees (apart from requiring them to be non-negative). This is in part due to the fact that what is &quot;reasonable&quot; economical behavior may change over time, at timescales much shorter than those over which consensus rules can be adapted.</p>

CC BY-SA 4.0
2024-01-16T03:14:22.440Z
I used to think that preventing someone from sending more fees than recipient amounts would interfere with CPFP, but really that should be possible to distinguish.
Murch
CC BY-SA 4.0
2024-01-16T14:40:21.370Z
"Policy rules exist to protect the network, not the individual node operator.", what about maxmempool so my node doesn't crash? or is that also to protect the network somehow
WhoIsNinja
CC BY-SA 4.0
2024-01-16T14:45:38.663Z
@WhoIsNinja Fair enough, I wasn't considering resource limits when I wrote that. My point was more that it would be wrong for *your* node to (try to) prevent another user from shooting themselves in the foot, in situations where they're perfectly capable of preventing that themselves.
Pieter Wuille
CC BY-SA 4.0
2024-01-16T15:38:46.370Z
that makes sense, thanks Pieter!
WhoIsNinja
CC BY-SA 4.0
2024-01-17T04:01:46.330Z
More importantly, rejecting transactions with a very high fee is not mining incentive compatible.
Murch
CC BY-SA 4.0
2024-02-04T03:11:23.063Z
@Murch  I thought the focus of Bitcoin development is more on decentralization, rather than just miner incentive.
WhoIsNinja
CC BY-SA 4.0
2024-01-16T02:38:25.083Z
2024-01-16T02:38:25.083Z
Pieter Wuille
<p>I can't wrap my head around the fact that someone could pay more fees than the value transferred(even though some wallets could be taking care of it at that level) but this also enables a well funded DDoS vector possible.</p>
<p>Is there a technical reason why Bitcoin doesn't prevent something like this at the consensus level or at least Bitcoin core as one of the policy rules?</p>
<p>There's an option for minimum dust relay which has a completely arbitrary default value(making it quite ineffective and inconvenient to use), may be that should be dynamic with an on/off option instead.</p>

CC BY-SA 4.0
2024-01-15T20:50:14.517Z
Just a small note about "*why Bitcoin core doesn't prevent something like this at either consensus or policy levels*": Bitcoin core is not an "owner" of Bitcoins consensus rules, its just one of the implementations (among much other) of Bitcoin full node; so it can't prevent anything by itself on consensus level
LeaBit
CC BY-SA 4.0
2024-01-15T20:59:06.463Z
When we talk about full nodes, we can only assume that the majority of the network uses Bitcoin Core. However, my point was not about that, but only that Bitcoin Core cannot change the consensus rules by itself. Perhaps it would be more correct to write in question why Bitcoin does not prevent it at the level of consensus or at least Bitcoin core as a standard rule.
LeaBit
CC BY-SA 4.0
2024-01-15T20:59:45.430Z
gotcha, I agree and updated
WhoIsNinja
CC BY-SA 4.0
2024-01-15T21:00:30.547Z
There are no standard rules in Bitcoin protocol, just in full node (eg Bitcoin core) implementation.
LeaBit
CC BY-SA 4.0
2024-01-15T21:07:30.053Z
Surely, I appreciate the edits suggested.
WhoIsNinja
CC BY-SA 4.0
2024-01-16T04:49:09.287Z
Why is this problematic?  There are reasonably foreseeable situations where one would rationally want to send such a transaction.  Let's say I have an installment of BTC 0.001 due on a loan.  If I don't make the payment on time, it'll incur late fees and penalty interest of BTC 0.01.  So even if transaction fees are currently BTC 0.002, it would be entirely sensible for me to pay it send the transaction.  And I would be extremely upset if protocol rules wouldn't let me do it.
Nate Eldredge
CC BY-SA 4.0
2024-01-16T04:52:12.587Z
So I see no reason to stop someone from paying high fees if the transaction is really worth that much to them.  And in particular, I don't see why the amount of the outputs should be a special threshold.  In the example above, I would be just as eager to send the transaction for a fee of 0.0099 as for 0.0011.  It would just be a coincidence if the required fee happened to be slightly above or below the output value.
Nate Eldredge
CC BY-SA 4.0
2024-01-16T04:55:24.020Z
It happens with fiat money too.  Currently my credit card company owes me $1.29.  They are going to mail me a check, for which the postage and printing costs will almost surely exceed $1.29.  It may be silly, but I'm legally entitled to that money, and they've got to get it to me somehow.  Should the postal service refuse to accept the envelope for mailing?
Nate Eldredge
<mempool><spam>
What makes it difficult to prevent transactions where value transferred is less than the fees paid?
WhoIsNinja
# What makes it difficult to prevent transactions where value transferred is less than the fees paid?

(Asked by: username_0 on 2024-01-15)

I can't wrap my head around the fact that someone could pay more fees than the value transferred(even though some wallets could be taking care of it at that level) but this also enables a well funded DDoS vector possible.

Is there a technical reason why Bitcoin doesn't prevent something like this at the consensus level or at least Bitcoin core as one of the policy rules?

There's an option for minimum dust relay which has a completely arbitrary default value(making it quite ineffective and inconvenient to use), may be that should be dynamic with an on/off option instead.

**Tags:** mempool, spam

> **Comments:**
> **username_1**: Just a small note about "*why Bitcoin core doesn't prevent something like this at either consensus or policy levels*": Bitcoin core is not an "owner" of Bitcoins consensus rules, its just one of the implementations (among much other) of Bitcoin full node; so it can't prevent anything by itself on consensus level  
> **username_1**: When we talk about full nodes, we can only assume that the majority of the network uses Bitcoin Core. However, my point was not about that, but only that Bitcoin Core cannot change the consensus rules by itself. Perhaps it would be more correct to write in question why Bitcoin does not prevent it at the level of consensus or at least Bitcoin core as a standard rule.  
> **username_0**: gotcha, I agree and updated  
> **username_1**: There are no standard rules in Bitcoin protocol, just in full node (eg Bitcoin core) implementation.  
> **username_0**: Surely, I appreciate the edits suggested.  
> **username_2**: Why is this problematic?  There are reasonably foreseeable situations where one would rationally want to send such a transaction.  Let's say I have an installment of BTC 0.001 due on a loan.  If I don't make the payment on time, it'll incur late fees and penalty interest of BTC 0.01.  So even if transaction fees are currently BTC 0.002, it would be entirely sensible for me to pay it send the transaction.  And I would be extremely upset if protocol rules wouldn't let me do it.  
> **username_2**: So I see no reason to stop someone from paying high fees if the transaction is really worth that much to them.  And in particular, I don't see why the amount of the outputs should be a special threshold.  In the example above, I would be just as eager to send the transaction for a fee of 0.0099 as for 0.0011.  It would just be a coincidence if the required fee happened to be slightly above or below the output value.  
> **username_2**: It happens with fiat money too.  Currently my credit card company owes me $1.29.  They are going to mail me a check, for which the postage and printing costs will almost surely exceed $1.29.  It may be silly, but I'm legally entitled to that money, and they've got to get it to me somehow.  Should the postal service refuse to accept the envelope for mailing?  

---

## 2 answers

### Answer by username_4 on 2024-01-16. Score: 4 | Accepted answer

### At the wallet level

Nothing prevents wallets from implementing reasonable safety measures to protect their users from undesirable behavior.

Bitcoin Core for example has a feature to (by default) reject the creation of transactions with a very high fee value. There is no specific rule to prevent fees higher than the amount transferred, but there certainly could be. Other wallet software may have similar and/or different preventative measures.

### At the policy level

Policy rules exist to protect the network, not the individual node operator. A rule to prevent too high fees doesn't belong here, as it doesn't hurt the network.

Furthermore, it is *hard* to imagine what such a rule would look like, because the amount paid/transferred is *by design* not visible in the transaction (most transactions have change that is sent back to the sender, but which is indistinguishable from the "payment" output to outsiders).

The dust relay rule is intended to disincentivize the creation of transaction outputs which would be more expensive to **spend** than their value. Such outputs are likely to remain unspent in the UTXO set forever, slowly accumulating and eventually increasing node operation costs.

### At the consensus rule level

The same considerations apply here as for policy rules, except they need to be agreed upon by the entire ecosystem, and are such much harder to change.

So far, this has meant no rules at all that relate to fees (apart from requiring them to be non-negative). This is in part due to the fact that what is "reasonable" economical behavior may change over time, at timescales much shorter than those over which consensus rules can be adapted.

> **Comments:**
> **username_5**: I used to think that preventing someone from sending more fees than recipient amounts would interfere with CPFP, but really that should be possible to distinguish.  
> **username_0**: "Policy rules exist to protect the network, not the individual node operator.", what about maxmempool so my node doesn't crash? or is that also to protect the network somehow  
> **username_4**: @username_0 Fair enough, I wasn't considering resource limits when I wrote that. My point was more that it would be wrong for *your* node to (try to) prevent another user from shooting themselves in the foot, in situations where they're perfectly capable of preventing that themselves.  
> **username_0**: that makes sense, thanks username_4!  
> **username_5**: More importantly, rejecting transactions with a very high fee is not mining incentive compatible.  
> **username_0**: @username_5  I thought the focus of Bitcoin development is more on decentralization, rather than just miner incentive.  

---

### Answer by username_3 on 2024-04-24. Score: 1

Luke says it's NOT difficult...

<https://github.com/bitcoinknots/bitcoin/issues/74>

> Dynamic dust limit #74
>
> luke-jr commented on Mar 22 • There is now (as of 26.1) experimental
> (and disabled by default) support for dynamically adjusting the "dust"
> spam filter threshold. It can be enabled in the GUI, or by configuring
> -dustdynamic=target:N to adjust based on a fee estimate for confirmation within N blocks, or -dustdynamic=mempool:N to adjust
> based on the worst fee in the best N kvB of your mempool. In either
> mode, the fee will be adjusted every 15 minutes (the first time not
> for 15 minutes after startup, in an effort to ensure estimators have
> sufficient data to work with). Implementation details (including how
> often adjustment occurs) may be changed in future releases.

I would love to hear username_5's opinions on the functionality of this code, as it's obviously more complex than my elementary level coding proposal of

if (Tx < TxFee) {isDust = True;}

While a 4 MB block full of 330 or 546 sat Txs each with 440,000 sat TxFees would be short-term good for miners, such incessant repetition would NOT be good for the Bitcoin Monetary SYSTEM, which is much, MUCH larger than miners. The long-term view of storing & transferring value requires moving Txs that are larger than their Fees.


---

