<p>As you write, the <a href="https://bitcoincore.org/en/doc/27.0.0/rpc/wallet/sendmany/" rel="nofollow noreferrer"><code>sendmany</code></a> has the optional parameter <code>subtractfeefrom</code>. It takes an array of addresses which must be a subset of the addresses appearing in the <code>amounts</code> object. Instead of the default behavior of the sender paying for the transaction fees, when any addresses are provided in <code>subtractfeefrom</code>, the transaction fees are deducted in equal shares from the listed recipients.</p>
<p>Under the hood, Bitcoin Core performs coin selection as if the transaction did not cost fees using the actual values of UTXOs instead of their effective values. After assigning the leftover amount to a change output, the fees for the entire transaction are calculated and deducted from the recipients listed in <code>subtractfeefrom</code> in equal shares. If the amount does not divide cleanly, any remainder is deducted from the first listed address, i.e. if the transaction fee amounted to 800 sats and there were three recipients to deduct the fees from, the first would pay 268 sats and the latter two would pay 266 sats.</p>
<p>As the combination of SFFO and attempting to find changeless transactions has caused several bugs in the last year, Bitcoin Core will always create a transaction with change when any variant of <code>subtractfeefromoutput</code> (SFFO) is used. Incidentally, if you want to empty a wallet completely, perhaps consider using the <a href="https://bitcoincore.org/en/doc/27.0.0/rpc/wallet/sendall/" rel="nofollow noreferrer"><code>sendall</code></a> RPC instead.</p>
<p>Overall, SFFO is a huge pain in the neck as it turns a number of the general assumptions about coin selection and transaction building on its head. If you are looking to implement something like it, I would suggest that you do not attempt to copy Bitcoin Core’s approach.</p>

CC BY-SA 4.0
2024-06-06T02:23:36.343Z
Oh, i was trying to copy their approach, but some part is not quite easy to understand, would you mind to explain a bit more on how does the effective rate come from? in addtional, when i take a look on the CPP code, it seem it doesnt create change if the SelectCoins process doesnt require, and afterward, it only subtract the fee from recipient if fee_needed - current_fee, i have no idea what is diff by fee_needed vs current_fee too
Stanley Yuen
CC BY-SA 4.0
2024-06-06T02:26:27.990Z
so in that case, if the change doesnt create, and fee_needed - current_fee > 0 , means recipients receive less, and fee increase, this is not making sense anyway
Stanley Yuen
CC BY-SA 4.0
2024-06-06T13:51:51.823Z
1. Here is a topic that explores [_effective value of UTXOs_](https://bitcoin.stackexchange.com/q/103654/5406) as a concept. The gist is that you know how much fees you will be paying to spend a UTXO when you know the feerate and the output type. You can then deduct the fee from the value of the UTXO in advance of coin selection and makes it much easier to figure out whether you have selected enough. ••• 2. The `selection_target` in Bitcoin Core is composed of the money needed to create the recipient outputs, plus the fees for the fixed size parts of the transactions, and a budget for change.
Murch
CC BY-SA 4.0
2024-06-06T13:53:34.110Z
3. The coin selection methods that create changeless transactions are disabled when the user specifies SFFO. Bitcoin Core will always create a transaction with change if the fee is paid by recipients. ••• 4. Usually, coin selection will consider UTXOs at their _effective value_, i.e. the fee for every UTXO that is selected as an input is already accounted for. When SFFO is active, the UTXOs are counted with their full value and the fee is calculated in the end, before it is deducted from the recipients. That’s why `fee_needed - current_fee` will not be 0 at that point.
Murch
CC BY-SA 4.0
2024-06-07T01:00:20.843Z
Thank you for the information, i will take a deep dive!
Stanley Yuen
CC BY-SA 4.0
2024-06-05T14:26:26.623Z
2024-06-05T14:26:26.623Z
Murch
<p>From the description of Bitcoin Core, <code>subtractfeefrom</code> is a parameter to define which recipient address would opt-in to receive less and contribute to pay the fee</p>
<p>Here is a usecase:</p>
<p>Alex has one UTXO which contains 10 BTC and he sends Mary and Bob each 1 BTC. The transaction fee is 0.5 BTC, so the change to Alex is 10 - 2 - 0.5 = 7.5 BTC.</p>
<p>How does <code>subtractfeefrom</code> apply to above case in DETAIL?</p>
<p>My high level assumption is</p>
<ul>
<li>Get the required fee for the txn</li>
<li>Deduct this amount evenly from every optin output destination, except the change output, e.g 0.5 BTC / 2 destinations</li>
<li>First optin output destination also deduct by the non divisible amount - e.g 0.5BTC % 2 destinations</li>
<li>check if the deducted output is dust, else continue</li>
<li>adding the total deducted amount to change address</li>
</ul>
<p>Additionally, what if there is no change output, do we need to create one in this case?</p>

CC BY-SA 4.0
2024-06-05T13:23:22.890Z
May I ask which RPC you are asking about? I assume it is `sendmany`, since it has the `subtractfeefrom` parameter, but there is also `subtract_fee_from_outputs` on `send`, and `subtractfeefromamount` on `sendtoaddress`.
Murch
CC BY-SA 4.0
2024-06-06T02:24:53.073Z
yes it is sendmany
Stanley Yuen
<bitcoin-core><transaction-fees><subtract-fee-from-output>
How does subtractfeefrom work?
Stanley Yuen
# How does subtractfeefrom work?

(Asked by: username_0 on 2024-06-05)

From the description of Bitcoin Core, `subtractfeefrom` is a parameter to define which recipient address would opt-in to receive less and contribute to pay the fee

Here is a usecase:

Alex has one UTXO which contains 10 BTC and he sends Mary and Bob each 1 BTC. The transaction fee is 0.5 BTC, so the change to Alex is 10 - 2 - 0.5 = 7.5 BTC.

How does `subtractfeefrom` apply to above case in DETAIL?

My high level assumption is

* Get the required fee for the txn
* Deduct this amount evenly from every optin output destination, except the change output, e.g 0.5 BTC / 2 destinations
* First optin output destination also deduct by the non divisible amount - e.g 0.5BTC % 2 destinations
* check if the deducted output is dust, else continue
* adding the total deducted amount to change address

Additionally, what if there is no change output, do we need to create one in this case?

**Tags:** bitcoin-core, transaction-fees, subtract-fee-from-output

> **Comments:**
> **username_1**: May I ask which RPC you are asking about? I assume it is `sendmany`, since it has the `subtractfeefrom` parameter, but there is also `subtract_fee_from_outputs` on `send`, and `subtractfeefromamount` on `sendtoaddress`.  
> **username_0**: yes it is sendmany  

---

## 1 answers

### Answer by username_1 on 2024-06-05. Score: 1 | Accepted answer

As you write, the [`sendmany`](https://bitcoincore.org/en/doc/27.0.0/rpc/wallet/sendmany/) has the optional parameter `subtractfeefrom`. It takes an array of addresses which must be a subset of the addresses appearing in the `amounts` object. Instead of the default behavior of the sender paying for the transaction fees, when any addresses are provided in `subtractfeefrom`, the transaction fees are deducted in equal shares from the listed recipients.

Under the hood, Bitcoin Core performs coin selection as if the transaction did not cost fees using the actual values of UTXOs instead of their effective values. After assigning the leftover amount to a change output, the fees for the entire transaction are calculated and deducted from the recipients listed in `subtractfeefrom` in equal shares. If the amount does not divide cleanly, any remainder is deducted from the first listed address, i.e. if the transaction fee amounted to 800 sats and there were three recipients to deduct the fees from, the first would pay 268 sats and the latter two would pay 266 sats.

As the combination of SFFO and attempting to find changeless transactions has caused several bugs in the last year, Bitcoin Core will always create a transaction with change when any variant of `subtractfeefromoutput` (SFFO) is used. Incidentally, if you want to empty a wallet completely, perhaps consider using the [`sendall`](https://bitcoincore.org/en/doc/27.0.0/rpc/wallet/sendall/) RPC instead.

Overall, SFFO is a huge pain in the neck as it turns a number of the general assumptions about coin selection and transaction building on its head. If you are looking to implement something like it, I would suggest that you do not attempt to copy Bitcoin Core’s approach.

> **Comments:**
> **username_0**: Oh, i was trying to copy their approach, but some part is not quite easy to understand, would you mind to explain a bit more on how does the effective rate come from? in addtional, when i take a look on the CPP code, it seem it doesnt create change if the SelectCoins process doesnt require, and afterward, it only subtract the fee from recipient if fee_needed - current_fee, i have no idea what is diff by fee_needed vs current_fee too  
> **username_0**: so in that case, if the change doesnt create, and fee_needed - current_fee > 0 , means recipients receive less, and fee increase, this is not making sense anyway  
> **username_1**: 1. Here is a topic that explores [_effective value of UTXOs_](https://bitcoin.stackexchange.com/q/103654/5406) as a concept. The gist is that you know how much fees you will be paying to spend a UTXO when you know the feerate and the output type. You can then deduct the fee from the value of the UTXO in advance of coin selection and makes it much easier to figure out whether you have selected enough. ••• 2. The `selection_target` in Bitcoin Core is composed of the money needed to create the recipient outputs, plus the fees for the fixed size parts of the transactions, and a budget for change.  
> **username_1**: 3. The coin selection methods that create changeless transactions are disabled when the user specifies SFFO. Bitcoin Core will always create a transaction with change if the fee is paid by recipients. ••• 4. Usually, coin selection will consider UTXOs at their _effective value_, i.e. the fee for every UTXO that is selected as an input is already accounted for. When SFFO is active, the UTXOs are counted with their full value and the fee is calculated in the end, before it is deducted from the recipients. That’s why `fee_needed - current_fee` will not be 0 at that point.  
> **username_0**: Thank you for the information, i will take a deep dive!  

---

