<p>I've done some research on a related topic<sup>*</sup> and I'd say it depends on your assumptions what will happen with the value of Bitcoin, the fee rate, and the cost of creating transactions in the long run.</p>

<p>Under the assumption that the fee rate (in [sat/B]) will remain roughly the same level or increase, it <em>saves the user money</em> to add the change to the fee when the change is smaller than the cost of creating one output and spending one input:</p>

<pre><code>change ≤ (bytesOutput + bytesInput) × feePerByte ⇒ add to fee
</code></pre>

<p>For P2PKH at 150 satoshis per byte this is for example</p>

<pre><code>change ≤ 27,300 satoshis = (34 bytes + 148 bytes) × 150 satoshis per byte
</code></pre>

<p>You may also want to consider that adding the change to transaction fees causes transactions to confirm more quickly, take less blockspace, and reduce the UTXO set.</p>

<p>However, smaller amounts may become spendable in the future, if fee rates would drastically drop, or the cost of spending inputs would significantly decrease. The former could happen due to blocksize increases or introduction of a second layer payment system, while the latter could be brought about by new transaction formats, signature aggregation, or a lowering of the <code>minRelayTxFee</code>.</p>

<p>Alternatively, you can either try to directly match the amount you're trying to spend or just select a sufficiently large amount to create a useful change output. Thank you, Pieter, for the reminder.</p>

<p><sup>* <a href="http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf" rel="nofollow noreferrer">my Master thesis on Coin Selection [PDF with 943KB]</a></sup></p>

CC BY-SA 3.0
2017-03-19T21:25:21.107Z
An alternative is just doing input selection for a larger amount, and then creating change with the result.
Pieter Wuille
CC BY-SA 3.0
2017-03-20T18:24:16.157Z
Right assuming there are additional inputs available. There's the option of allowing users to set their own fees as well, but that seems to open up the chance for errors.
m1xolyd1an
CC BY-SA 4.0
2017-03-19T17:31:39.827Z
2018-07-20T15:53:21.193Z
2018-07-20T15:53:21.193Z
Murch
<p>I'm working on some quirks of a wallet I'm developing, and one of the issues is what to do with change amounts that are larger than dust ~600 satoshis, but less than a practical amount to be sent again with a fee. Should I return the near-dust amount as change, or just tack it on as additional mining fees?</p>

<p>For example, let's say a user spends an amount that after paying to an output and a sufficient fee leaves only 1,000 satoshis as change. Should I send those 1,000 satoshis as change even though 1,000 satoshis is too small to be spent again with a sufficient fee? </p>

<p>Even with fees as low as 10 satoshis per byte with one input and output (P2PKH) you'd need at least 2,000 satoshis for fees. </p>

<p>I'm thinking it might be better to just put the leftover towards additional mining fees if change amount is below a certain threshold, say 3,000 satoshis. An address with just 1,000 satoshis is mostly useless, and would just add to the growing UTXO set that would likely never be spent. Does this approach seem appropriate, or am I "robbing" users of their dust?</p>

<wallet><change><dust><transaction-fees>
Wallet design: What to do with dust amounts in change?
m1xolyd1an
# Wallet design: What to do with dust amounts in change?

(Asked by: username_0 on 2017-03-19)

I'm working on some quirks of a wallet I'm developing, and one of the issues is what to do with change amounts that are larger than dust ~600 satoshis, but less than a practical amount to be sent again with a fee. Should I return the near-dust amount as change, or just tack it on as additional mining fees?

For example, let's say a user spends an amount that after paying to an output and a sufficient fee leaves only 1,000 satoshis as change. Should I send those 1,000 satoshis as change even though 1,000 satoshis is too small to be spent again with a sufficient fee?

Even with fees as low as 10 satoshis per byte with one input and output (P2PKH) you'd need at least 2,000 satoshis for fees.

I'm thinking it might be better to just put the leftover towards additional mining fees if change amount is below a certain threshold, say 3,000 satoshis. An address with just 1,000 satoshis is mostly useless, and would just add to the growing UTXO set that would likely never be spent. Does this approach seem appropriate, or am I "robbing" users of their dust?

**Tags:** wallet, change, dust, transaction-fees


---

## 1 answers

### Answer by username_1 on 2017-03-19. Score: 3 | Accepted answer

I've done some research on a related topic\* and I'd say it depends on your assumptions what will happen with the value of Bitcoin, the fee rate, and the cost of creating transactions in the long run.

Under the assumption that the fee rate (in [sat/B]) will remain roughly the same level or increase, it *saves the user money* to add the change to the fee when the change is smaller than the cost of creating one output and spending one input:

```
change ≤ (bytesOutput + bytesInput) × feePerByte ⇒ add to fee

```

For P2PKH at 150 satoshis per byte this is for example

```
change ≤ 27,300 satoshis = (34 bytes + 148 bytes) × 150 satoshis per byte

```

You may also want to consider that adding the change to transaction fees causes transactions to confirm more quickly, take less blockspace, and reduce the UTXO set.

However, smaller amounts may become spendable in the future, if fee rates would drastically drop, or the cost of spending inputs would significantly decrease. The former could happen due to blocksize increases or introduction of a second layer payment system, while the latter could be brought about by new transaction formats, signature aggregation, or a lowering of the `minRelayTxFee`.

Alternatively, you can either try to directly match the amount you're trying to spend or just select a sufficiently large amount to create a useful change output. Thank you, username_2, for the reminder.

\* [my Master thesis on Coin Selection [PDF with 943KB]](http://username_1.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf)

> **Comments:**
> **username_2**: An alternative is just doing input selection for a larger amount, and then creating change with the result.  
> **username_0**: Right assuming there are additional inputs available. There's the option of allowing users to set their own fees as well, but that seems to open up the chance for errors.  

---

