<p>It seems there is some discrepancy between your <code>estimatedFee</code> variable and the feerate being used in the <code>fundrawtransaction</code> step. </p>

<p>I think you could try simplifying your code to not use the <code>estimatedFee</code> during the <code>vendorXBalance</code> calculation, and then when calling <code>fundrawtransaction</code>, use the <code>subtractFeeFromOutputs</code> option to just have the fee deducted equally from all specified outputs. For example:</p>

<pre><code>balance = Bitcoin.rpc.getbalance '*', 1, true

vendorABalance = vendorAIncome * 95%
vendorBBalance = vendorBIncome * 95%
vendorCBalance = vendorCIncome * 95%

systemBalance = balance - vendorABalance - vendorBBalance - vendorCBalance

rtx = Bitcoin.rpc.createrawtransaction [], [
  { 'Vendor A wallet' =&gt; vendorABalance },
  { 'Vendor B wallet' =&gt; vendorBBalance },
  { 'Vendor C wallet' =&gt; vendorCBalance },
  { 'System wallet' =&gt; systemBalance },
]
Bitcoin.rpc.fundrawtransaction rtx, { includeWatching: true, conf_target: 6, subtractFeeFromOutputs: [vout_index,...] }

# On a offline machine
rtx = bitcoin-cli signrawtransactionwithkey rtx ['private keys']

# Back on the online machine
Bitcoin.rpc.sendrawtransaction rtx
</code></pre>

<p>Here is some relevant text from <code>bitcoin-cli help fundrawtransaction</code> (v0.17.0.1): </p>

<pre><code>"subtractFeeFromOutputs" (array, optional) A json array of integers.
     The fee will be equally deducted from the amount of each specified output.
     The outputs are specified by their zero-based index, before any change 
     output is added.
     Those recipients will receive less bitcoins than you enter in their 
     corresponding amount field. 
     If no outputs are specified here, the sender pays the fee.
       [vout_index,...]
</code></pre>

CC BY-SA 4.0
2019-05-08T10:57:34.597Z
Before I use this solution I have to ask. `equally from all specified outputs`, In the example I gave, everyone will share the same amount to pay the fee, **vendorB** (1 btc) and **vendorC** (7 btc) will contribute the same way to the tx fee. Is there no way to have them contribute by "shares" or participation?
Nicos Karalis
CC BY-SA 4.0
2019-05-08T11:25:44.200Z
Great question, I do not believe it makes the subtracted fee proportionate to the value of the output. See: https://github.com/bitcoin/bitcoin/blob/24dfcf3a56f90b101bc208f48ccdb7813fa08b83/src/wallet/wallet.cpp#L2761.
chytrik
CC BY-SA 4.0
2019-05-08T12:42:09.763Z
Yeah, *subtractFeeFromOutputs* just splits the fee equally. It is important to us because on a very large transaction (100 inputs) a vendor with very small balance (< $10) will be hit hard (even with segwit)
Nicos Karalis
CC BY-SA 4.0
2019-05-08T09:29:07.823Z
2019-05-08T09:44:38.167Z
2019-05-08T09:44:38.167Z
chytrik
<p>We have an instance of bitcoin core running a watch only wallet. This wallet receives a lot of transactions that we need to (once a day) sweep and split into other personal wallets.</p>

<p>The distribution is a full sweep as follows:</p>

<ol>
<li>Each <em>vendor</em> receives 95%, after fee deduction</li>
<li>The system collects 5%, after fee deduction</li>
</ol>

<p>Currently we do it manually like so:</p>

<ol>
<li>Create a new wallet in electrum with addresses that have balance</li>
<li>Manually calculate how much each partner is going to receive</li>
<li>Manually split the bitcoins for each partner</li>
<li>Check how much is the estimated fee for that transaction</li>
<li>Recalculate how much each partner is going to receive taking the fee out</li>
<li>Manually sign the transaction</li>
<li>Broadcast it</li>
</ol>

<p>Example:</p>

<pre><code>Inputs:
  Vendor A: 2 BTC in 5 inputs
  Vendor B: 1 BTC in 2 inputs
  Vendor C: 7 BTC in 20 inputs
Total input transactions: 10 BTC

Assuming fee: 0.0002
We send to each party's personal wallet:
  Vendor A: 1.89996200
  Vendor B: 0.94998100
  Vendor C: 6.64986700
    System: 0.49999000

Total sent: 10 BTC
</code></pre>

<p>I'm trying to automate the calculation of the distribution with the following script: (<em>please assume <code>Bitcoin.rpc</code> is the same as <code>bitcoin-cli</code></em>)</p>



<pre><code>balance = Bitcoin.rpc.getbalance '*', 1, true
estimatedFee = ???

vendorABalance = vendorAIncome * (balance - estimatedFee)/balance * 95%
vendorBBalance = vendorBIncome * (balance - estimatedFee)/balance * 95%
vendorCBalance = vendorCIncome * (balance - estimatedFee)/balance * 95%

systemBalance = balance - estimatedFee - vendorABalance - vendorBBalance - vendorCBalance

rtx = Bitcoin.rpc.createrawtransaction [], [
  { 'Vendor A wallet' =&gt; vendorABalance },
  { 'Vendor B wallet' =&gt; vendorBBalance },
  { 'Vendor C wallet' =&gt; vendorCBalance },
  { 'System wallet' =&gt; systemBalance },
]
Bitcoin.rpc.fundrawtransaction rtx, { includeWatching: true, conf_target: 6 }

# On a offline machine
rtx = bitcoin-cli signrawtransactionwithkey rtx ['private keys']

# Back on the online machine
Bitcoin.rpc.sendrawtransaction rtx
</code></pre>

<p>In theory this script does exactly what I need. <strong>If</strong> the <code>estimatedFee</code> variable gets the correct value</p>

<p>But I can't seem to find the sweet spot that will allow for the sweep of the wallet, I get <em>Insufficient funds</em> or there will be some leftovers.</p>

<p>What can I do?</p>

<bitcoin-core><transaction-fees><raw-transaction>
Accurately calculate fees to sweep all coins
Nicos Karalis
# Accurately calculate fees to sweep all coins

(Asked by: username_0 on 2019-05-08)

We have an instance of bitcoin core running a watch only wallet. This wallet receives a lot of transactions that we need to (once a day) sweep and split into other personal wallets.
The distribution is a full sweep as follows:

Each vendor receives 95%, after fee deduction
The system collects 5%, after fee deduction

Currently we do it manually like so:

Create a new wallet in electrum with addresses that have balance
Manually calculate how much each partner is going to receive
Manually split the bitcoins for each partner
Check how much is the estimated fee for that transaction
Recalculate how much each partner is going to receive taking the fee out
Manually sign the transaction
Broadcast it

Example:
Inputs:
  Vendor A: 2 BTC in 5 inputs
  Vendor B: 1 BTC in 2 inputs
  Vendor C: 7 BTC in 20 inputs
Total input transactions: 10 BTC

Assuming fee: 0.0002
We send to each party's personal wallet:
  Vendor A: 1.89996200
  Vendor B: 0.94998100
  Vendor C: 6.64986700
    System: 0.49999000

Total sent: 10 BTC

I'm trying to automate the calculation of the distribution with the following script: (please assume Bitcoin.rpc is the same as bitcoin-cli)
balance = Bitcoin.rpc.getbalance '*', 1, true
estimatedFee = ???

vendorABalance = vendorAIncome * (balance - estimatedFee)/balance * 95%
vendorBBalance = vendorBIncome * (balance - estimatedFee)/balance * 95%
vendorCBalance = vendorCIncome * (balance - estimatedFee)/balance * 95%

systemBalance = balance - estimatedFee - vendorABalance - vendorBBalance - vendorCBalance

rtx = Bitcoin.rpc.createrawtransaction [], [
  { 'Vendor A wallet' => vendorABalance },
  { 'Vendor B wallet' => vendorBBalance },
  { 'Vendor C wallet' => vendorCBalance },
  { 'System wallet' => systemBalance },
]
Bitcoin.rpc.fundrawtransaction rtx, { includeWatching: true, conf_target: 6 }

# On a offline machine
rtx = bitcoin-cli signrawtransactionwithkey rtx ['private keys']

# Back on the online machine
Bitcoin.rpc.sendrawtransaction rtx

In theory this script does exactly what I need. If the estimatedFee variable gets the correct value
But I can't seem to find the sweet spot that will allow for the sweep of the wallet, I get Insufficient funds or there will be some leftovers.
What can I do?

**Tags:** bitcoin-core, transaction-fees, raw-transaction


---

## 1 answers

### Answer by username_1 on 2019-05-08. Score: 1

It seems there is some discrepancy between your estimatedFee variable and the feerate being used in the fundrawtransaction step. 
I think you could try simplifying your code to not use the estimatedFee during the vendorXBalance calculation, and then when calling fundrawtransaction, use the subtractFeeFromOutputs option to just have the fee deducted equally from all specified outputs. For example:
balance = Bitcoin.rpc.getbalance '*', 1, true

vendorABalance = vendorAIncome * 95%
vendorBBalance = vendorBIncome * 95%
vendorCBalance = vendorCIncome * 95%

systemBalance = balance - vendorABalance - vendorBBalance - vendorCBalance

rtx = Bitcoin.rpc.createrawtransaction [], [
  { 'Vendor A wallet' => vendorABalance },
  { 'Vendor B wallet' => vendorBBalance },
  { 'Vendor C wallet' => vendorCBalance },
  { 'System wallet' => systemBalance },
]
Bitcoin.rpc.fundrawtransaction rtx, { includeWatching: true, conf_target: 6, subtractFeeFromOutputs: [vout_index,...] }

# On a offline machine
rtx = bitcoin-cli signrawtransactionwithkey rtx ['private keys']

# Back on the online machine
Bitcoin.rpc.sendrawtransaction rtx

Here is some relevant text from bitcoin-cli help fundrawtransaction (v0.17.0.1): 
"subtractFeeFromOutputs" (array, optional) A json array of integers.
     The fee will be equally deducted from the amount of each specified output.
     The outputs are specified by their zero-based index, before any change 
     output is added.
     Those recipients will receive less bitcoins than you enter in their 
     corresponding amount field. 
     If no outputs are specified here, the sender pays the fee.
       [vout_index,...]

> **Comments:**
> **username_0**: Before I use this solution I have to ask. `equally from all specified outputs`, In the example I gave, everyone will share the same amount to pay the fee, **vendorB** (1 btc) and **vendorC** (7 btc) will contribute the same way to the tx fee. Is there no way to have them contribute by "shares" or participation?  
> **username_1**: Great question, I do not believe it makes the subtracted fee proportionate to the value of the output. See: https://github.com/bitcoin/bitcoin/blob/24dfcf3a56f90b101bc208f48ccdb7813fa08b83/src/wallet/wallet.cpp#L2761.  
> **username_0**: Yeah, *subtractFeeFromOutputs* just splits the fee equally. It is important to us because on a very large transaction (100 inputs) a vendor with very small balance (< $10) will be hit hard (even with segwit)  

---

