<p>Just to give a little background first: Bitcoin uses a so-called UTXO model. You own UTXOs (or &quot;coins&quot;, to give an analogy). Every coin has a value (which can be any number of satoshis) and has an owner (script) &quot;stamped&quot; into it. Every transactions &quot;melts down&quot; a number of existing coins, and &quot;forges&quot; new coins. The value of the new coins cannot exceed the value of the melted coins. The difference between the amount melted down and the amount forged is the fee of a transaction.</p>
<p>This means that the protocol really no concept of a &quot;balance&quot;. There are just coins. You can have 3 BTC in your wallet, consisting of a 1 BTC coin X and a 2 BTC coin Y. These can be stamped with the same script (address) or not. It doesn't really matter - a wallet can consist of many addresses.</p>
<p>So say you want to pay 1.5 BTC to someone else, who has given you address A. Your end goal is creating a transaction that consumes the 2 BTC coin, and produces a 1.5 BTC coin (to the payee) and a 0.5 BTC coin (minus fee) back to a new address of your own wallet (called a <em>change</em> address). It's also possible to consume both the 1 BTC and 2 BTC coins, and outputs 2x a 1.5 BTC coin. Let's assume that's what you're doing.</p>
<p>How would you do this using the Bitcoin Core RPC? There are a number of ways:</p>
<h3>The most automatic way</h3>
<p>If you're using Bitcoin Core's built-in wallet (i.e. the Bitcoin Core wallet is what created the addresses involved, and it manages your coins), you can make it do everything. Just do:</p>
<pre><code>bitcoin-cli sendtoaddress &lt;A&gt; 1.5
</code></pre>
<p>Where <code>&lt;A&gt;</code> is the recipient address. It will automatically determine which of your UTXOs to use, and create a transaction that spends those, pays <code>&lt;A&gt;</code> and creates change, then sign the result, and broadcast it on the network.</p>
<h3>Manually but using the wallet still</h3>
<p>If you want more control, you can perform the things <code>sendtoaddress</code> is doing one by one yourself, allowing you to observe the intermediary results.</p>
<p>The first you do is create a raw transaction that pays <code>&lt;A&gt;</code>, and nothing else:</p>
<pre><code>bitcoin-cli createrawtransaction '[]' '[{&quot;&lt;A&gt;&quot;: 1.5}]'
</code></pre>
<p>It will report a hex raw partial transaction with just that one output, and no inputs. Next you want to add inputs and change. You could do that manually (see further), but you can let the wallet do this for you. This is what <code>fundrawtransaction</code> is for.</p>
<pre><code>bitcoin-cli fundrawtransaction '&quot;&lt;output from CRT&gt;&quot;'
</code></pre>
<p>This will give you another unsigned raw transaction, but now one that includes inputs (sufficient to cover the 1.5 BTC you're trying to send) and change (for whatever is left of the inputs spent after subtracting 1.5 BTC, plus a reasonable fee based on network estimation, and estimation of how big the transaction will be <em>after</em> signing).</p>
<p>Then you sign it, and broadcast it.</p>
<pre><code>bitcoin-cli signrawtransactionwithwallet '&quot;&lt;output from FRT&gt;&quot;'
bitcoin-cli sendrawtransaction '&quot;&lt;output from SRTWW&gt;&quot;'
</code></pre>
<p>The advantage of this approach is that you can inspect the intermediary results at every stage (using <code>decoderawtransaction</code> amongst others), or make many changes to the process. Perhaps you have a multisig wallet with another device - and you need to make a pass by there doing another <code>signrawtransactionwithwallet</code> (or whatever equivalent that other device/software has for working with raw transactions).</p>
<h3>Fully manual</h3>
<p>If you want the most control, you can do everything manually - including the ability to include inputs that don't belong to your own wallet. This is the example you gave in the question, but if that's <em>all</em> you plan to do, you're much better off using one of the previous two methods.</p>
<p>As you pointed out, you first need to gather a list of UTXOs that can be spent. This can be done with <code>listunspent</code>, but you can also include other UTXOs - including ones from other people if you're participating in a <a href="https://en.bitcoin.it/wiki/CoinJoin" rel="noreferrer">CoinJoin</a> transaction for example.</p>
<pre><code>bitcoin-cli listunspent
</code></pre>
<p>Then you have to construct the (full) raw transaction, including the inputs you want to use from before, the output to the recipient, and including a change output back to yourself. If you want that change to go to you own wallet, you can use <code>getrawchangeaddress</code> (which is like <code>getnewaddress</code>, but will treat outputs to it as change rather than an incoming payment). You also need to manually estimate the vsize of the transaction will be after signing, determine a fee to use based on that (the block space market prioritizes transactions based on fee per vsize), and subtract that fee from the change you're creating. This is a bunch of work, and mistakes are easily made.</p>
<p>Next you'll need to sign the transaction. If you have the private key in your own wallet, you can use <code>signrawtransactionwithwallet</code> like before (note that <code>signrawtransaction</code> from your example no longer exists; it has been split up into <code>signrawtransactionwithkey</code> and <code>signrawtransactionwithwallet</code>). If not, you can either use <code>signrawtransactionwithkey</code> if you have the private key, or you could transfer the raw transaction to other devices/people, and sign there too.</p>
<p>Finally you'd use <code>sendrawtransaction</code> just like before.</p>
<h3>Using PSBT</h3>
<p>At this point I need to point out that all the raw transaction based transaction APIs have been superseded by the <a href="https://github.com/bitcoin/bitcoin/blob/v0.21.0/doc/psbt.md" rel="noreferrer">PSBT</a>-based RPCs (see <a href="https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki" rel="noreferrer">BIP 174</a>). If you try to use the RPCs above you'll notice they really only work with simple scripts, and you need to pass a lot of information along everywhere. In particular, <code>signrawtransactionwithkey</code> will need information about the UTXOs again, the scripts used in those, what type of scripts they are. This is pretty painful, and easy to screw up.</p>
<p>PSBT is an interchange format for transferring/storing partially signed transactions, along with any information signers or other participants may need to be able to sign. It'll convey UTXOs, script information, information about the keys in it, ...</p>
<p>The equivalent of &quot;manually but using the wallet still&quot; would be:</p>
<ul>
<li><code>walletcreatefundedpsbt</code> instead of <code>createrawtransaction</code> + <code>fundrawtransaction</code></li>
<li><code>walletprocesspsbt</code> instead of <code>signrawtransactionwithwallet</code></li>
<li><code>finalizepsbt</code> to convert a fully-signed PSBT to a raw transaction</li>
<li><code>sendrawtransaction</code> like before to broadcast the result.</li>
</ul>
<p>The equivalent of &quot;Fully manual&quot; would be:</p>
<ul>
<li><code>createpsbt</code> instead of <code>createrawtransaction</code></li>
<li><code>walletprocesspsbt</code> instead of <code>signrawtransactionwithwallet</code>. There currently is no equivalent for <code>signrawtransactionwithkey</code>, but PSBT is supported by various other pieces of software (most notably, <a href="https://github.com/bitcoin-core/HWI" rel="noreferrer">HWI</a> which allows PSBT signing and other operations with hardware wallets.</li>
<li>Again, <code>finalizepsbt</code> and <code>sendrawtransaction</code> like before.</li>
</ul>
<p>PSBT has a lot more utility functions, such as <code>combinepsbt</code> (mostly for multisig), <code>joinpsbts</code> (for doing CoinJoin-like things), <code>decodepsbt</code> and <code>analyzepsbt</code> that can tell you what to do next, <code>utxoupdatepsbt</code> to gather information from the UTXO set and add it to a PSBT file (which works even if your Bitcoin Core wallet is not involved), etc.</p>
<h3>TL;DR</h3>
<p>You can use a workflow with or without <code>fundrawtransaction</code>. If you don't use it, you have more manual control and aren't forced to use the Bitcoin Core wallet itself.</p>

CC BY-SA 4.0
2021-05-18T04:24:39.180Z
It's the best explanation that I saw. Thanks.
B L
CC BY-SA 4.0
2021-05-18T04:24:57.667Z
But I have some questions.
B L
CC BY-SA 4.0
2021-05-18T04:25:12.133Z
1. `sendtoaddress` - Does it automatically repay the change?
B L
CC BY-SA 4.0
2021-05-18T04:25:24.297Z
2. `fundrawtransaction` - Do I right understand that it's half automatized function what automatic find `input`, fee and auto repay the charge (if I point txhash only); also, I can set these parameters manually, as arguments with `fundrawtransaction` just like with `createrawtransaction`?
B L
CC BY-SA 4.0
2021-05-18T04:31:24.653Z
1. Yes, `sendtoaddress` (and its slightly more advanced version `sendmany`) does everything mentioned here, including adding change. 2. Pretty much, have a look at the documentation for `fundrawtransaction`.
Pieter Wuille
CC BY-SA 4.0
2021-05-10T22:56:45.413Z
2021-05-10T23:46:11.953Z
2021-05-10T23:46:11.953Z
Pieter Wuille
<p>I find on Internet interested <a href="https://vhernando.github.io/bitcoind-raw-transaction-create-howto#:%7E:text=A%20Bitcoin%20raw%20transaction%20is,adds%20it%20to%20a%20block." rel="nofollow noreferrer">article</a>.</p>
<p>How I understand the raw transaction can be created simpler without <code>fundrawtransaction</code>.</p>
<ol>
<li>bitcoin-cli listunspent [misconf=1] [max_number_confirmation=99999999] '''[&quot;&lt;wallet_address&gt;&quot;]'''</li>
<li>bitcoin-cli createrawtransaction
'[{
&quot;txid&quot; : &quot;&lt;txid_of_selected_block&gt;&quot;,
&quot;vout&quot; : 
}]'
'{&quot;&lt;recipient_address&gt;&quot;: &lt;amount_to_send&gt;, &quot;&lt;sender_address&gt;&quot;: &lt;amount_change&gt;}'</li>
<li>bitcoin-cli signrawtransaction &lt;hex_createrawtransaction&gt;</li>
<li>bitcoin-cli sendrawtransaction &lt;hex_signrawtransaction&gt;</li>
</ol>
<p>That's all and without <code>fundrawtransaction</code>.</p>
<p>And I don't understand why <code>fundrawtransaction</code> do need? And what is the difference between &quot;with&quot; and &quot;without&quot;?</p>
<p>I'm a newbie and I not sure I right understand what do mean inputs and outputs and possibly so I can't understand what mean <code>fundrawtransaction</code>?</p>
<p>Please, more examples and more simple speech. Thanks.</p>

<bitcoin-core><transactions><bitcoin-cli>
fundrawtransaction - what is it?
B L
# fundrawtransaction - what is it?

(Asked by: username_0 on 2021-04-28)

I find on Internet interested [article](https://vhernando.github.io/bitcoind-raw-transaction-create-howto#:%7E:text=A%20Bitcoin%20raw%20transaction%20is,adds%20it%20to%20a%20block.).

How I understand the raw transaction can be created simpler without `fundrawtransaction`.

1. bitcoin-cli listunspent [misconf=1] [max\_number\_confirmation=99999999] '''["<wallet\_address>"]'''
2. bitcoin-cli createrawtransaction
   '[{
   "txid" : "<txid\_of\_selected\_block>",
   "vout" :
   }]'
   '{"<recipient\_address>": <amount\_to\_send>, "<sender\_address>": <amount\_change>}'
3. bitcoin-cli signrawtransaction <hex\_createrawtransaction>
4. bitcoin-cli sendrawtransaction <hex\_signrawtransaction>

That's all and without `fundrawtransaction`.

And I don't understand why `fundrawtransaction` do need? And what is the difference between "with" and "without"?

I'm a newbie and I not sure I right understand what do mean inputs and outputs and possibly so I can't understand what mean `fundrawtransaction`?

Please, more examples and more simple speech. Thanks.

**Tags:** bitcoin-core, transactions, bitcoin-cli


---

## 1 answers

### Answer by username_1 on 2021-05-10. Score: 13 | Accepted answer

Just to give a little background first: Bitcoin uses a so-called UTXO model. You own UTXOs (or "coins", to give an analogy). Every coin has a value (which can be any number of satoshis) and has an owner (script) "stamped" into it. Every transactions "melts down" a number of existing coins, and "forges" new coins. The value of the new coins cannot exceed the value of the melted coins. The difference between the amount melted down and the amount forged is the fee of a transaction.

This means that the protocol really no concept of a "balance". There are just coins. You can have 3 BTC in your wallet, consisting of a 1 BTC coin X and a 2 BTC coin Y. These can be stamped with the same script (address) or not. It doesn't really matter - a wallet can consist of many addresses.

So say you want to pay 1.5 BTC to someone else, who has given you address A. Your end goal is creating a transaction that consumes the 2 BTC coin, and produces a 1.5 BTC coin (to the payee) and a 0.5 BTC coin (minus fee) back to a new address of your own wallet (called a *change* address). It's also possible to consume both the 1 BTC and 2 BTC coins, and outputs 2x a 1.5 BTC coin. Let's assume that's what you're doing.

How would you do this using the Bitcoin Core RPC? There are a number of ways:

### The most automatic way

If you're using Bitcoin Core's built-in wallet (i.e. the Bitcoin Core wallet is what created the addresses involved, and it manages your coins), you can make it do everything. Just do:

```
bitcoin-cli sendtoaddress <A> 1.5

```

Where `<A>` is the recipient address. It will automatically determine which of your UTXOs to use, and create a transaction that spends those, pays `<A>` and creates change, then sign the result, and broadcast it on the network.

### Manually but using the wallet still

If you want more control, you can perform the things `sendtoaddress` is doing one by one yourself, allowing you to observe the intermediary results.

The first you do is create a raw transaction that pays `<A>`, and nothing else:

```
bitcoin-cli createrawtransaction '[]' '[{"<A>": 1.5}]'

```

It will report a hex raw partial transaction with just that one output, and no inputs. Next you want to add inputs and change. You could do that manually (see further), but you can let the wallet do this for you. This is what `fundrawtransaction` is for.

```
bitcoin-cli fundrawtransaction '"<output from CRT>"'

```

This will give you another unsigned raw transaction, but now one that includes inputs (sufficient to cover the 1.5 BTC you're trying to send) and change (for whatever is left of the inputs spent after subtracting 1.5 BTC, plus a reasonable fee based on network estimation, and estimation of how big the transaction will be *after* signing).

Then you sign it, and broadcast it.

```
bitcoin-cli signrawtransactionwithwallet '"<output from FRT>"'
bitcoin-cli sendrawtransaction '"<output from SRTWW>"'

```

The advantage of this approach is that you can inspect the intermediary results at every stage (using `decoderawtransaction` amongst others), or make many changes to the process. Perhaps you have a multisig wallet with another device - and you need to make a pass by there doing another `signrawtransactionwithwallet` (or whatever equivalent that other device/software has for working with raw transactions).

### Fully manual

If you want the most control, you can do everything manually - including the ability to include inputs that don't belong to your own wallet. This is the example you gave in the question, but if that's *all* you plan to do, you're much better off using one of the previous two methods.

As you pointed out, you first need to gather a list of UTXOs that can be spent. This can be done with `listunspent`, but you can also include other UTXOs - including ones from other people if you're participating in a [CoinJoin](https://en.bitcoin.it/wiki/CoinJoin) transaction for example.

```
bitcoin-cli listunspent

```

Then you have to construct the (full) raw transaction, including the inputs you want to use from before, the output to the recipient, and including a change output back to yourself. If you want that change to go to you own wallet, you can use `getrawchangeaddress` (which is like `getnewaddress`, but will treat outputs to it as change rather than an incoming payment). You also need to manually estimate the vsize of the transaction will be after signing, determine a fee to use based on that (the block space market prioritizes transactions based on fee per vsize), and subtract that fee from the change you're creating. This is a bunch of work, and mistakes are easily made.

Next you'll need to sign the transaction. If you have the private key in your own wallet, you can use `signrawtransactionwithwallet` like before (note that `signrawtransaction` from your example no longer exists; it has been split up into `signrawtransactionwithkey` and `signrawtransactionwithwallet`). If not, you can either use `signrawtransactionwithkey` if you have the private key, or you could transfer the raw transaction to other devices/people, and sign there too.

Finally you'd use `sendrawtransaction` just like before.

### Using PSBT

At this point I need to point out that all the raw transaction based transaction APIs have been superseded by the [PSBT](https://github.com/bitcoin/bitcoin/blob/v0.21.0/doc/psbt.md)-based RPCs (see [BIP 174](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki)). If you try to use the RPCs above you'll notice they really only work with simple scripts, and you need to pass a lot of information along everywhere. In particular, `signrawtransactionwithkey` will need information about the UTXOs again, the scripts used in those, what type of scripts they are. This is pretty painful, and easy to screw up.

PSBT is an interchange format for transferring/storing partially signed transactions, along with any information signers or other participants may need to be able to sign. It'll convey UTXOs, script information, information about the keys in it, ...

The equivalent of "manually but using the wallet still" would be:

* `walletcreatefundedpsbt` instead of `createrawtransaction` + `fundrawtransaction`
* `walletprocesspsbt` instead of `signrawtransactionwithwallet`
* `finalizepsbt` to convert a fully-signed PSBT to a raw transaction
* `sendrawtransaction` like before to broadcast the result.

The equivalent of "Fully manual" would be:

* `createpsbt` instead of `createrawtransaction`
* `walletprocesspsbt` instead of `signrawtransactionwithwallet`. There currently is no equivalent for `signrawtransactionwithkey`, but PSBT is supported by various other pieces of software (most notably, [HWI](https://github.com/bitcoin-core/HWI) which allows PSBT signing and other operations with hardware wallets.
* Again, `finalizepsbt` and `sendrawtransaction` like before.

PSBT has a lot more utility functions, such as `combinepsbt` (mostly for multisig), `joinpsbts` (for doing CoinJoin-like things), `decodepsbt` and `analyzepsbt` that can tell you what to do next, `utxoupdatepsbt` to gather information from the UTXO set and add it to a PSBT file (which works even if your Bitcoin Core wallet is not involved), etc.

### TL;DR

You can use a workflow with or without `fundrawtransaction`. If you don't use it, you have more manual control and aren't forced to use the Bitcoin Core wallet itself.

> **Comments:**
> **username_0**: It's the best explanation that I saw. Thanks.  
> **username_0**: But I have some questions.  
> **username_0**: 1. `sendtoaddress` - Does it automatically repay the change?  
> **username_0**: 2. `fundrawtransaction` - Do I right understand that it's half automatized function what automatic find `input`, fee and auto repay the charge (if I point txhash only); also, I can set these parameters manually, as arguments with `fundrawtransaction` just like with `createrawtransaction`?  
> **username_1**: 1. Yes, `sendtoaddress` (and its slightly more advanced version `sendmany`) does everything mentioned here, including adding change. 2. Pretty much, have a look at the documentation for `fundrawtransaction`.  

---

