<p>A very useful RPC is the <code>testmempoolaccept</code> RPC. This will tell you whether the transaction would be accepted by the node. You can use this to determine whether the transaction is correctly signed. It will also tell you what the transaction fee is so you can determine whether the fee is what you expect it to be. If the transaction would not be accepted, it will also tell you what went wrong.</p>
<p>To ensure that the transaction is logically correct (i.e. money is being sent to the right place), you can use <code>decoderawtransaction</code> and examine the contents of the <code>vout</code> array. Each output is in that array and the value for the output and the address, if any, will be listed. So you can scan that array and make sure that the intended recipients are there with the correct values.</p>
<p>It is harder to determine change, but if you know what the change address is and what the change value should be, then you can check it as if it were another recipient as described earlier.</p>
<hr />
<p>One caveat about <code>testmempoolaccept</code>: it only works if the parent transactions are confirmed or in the mempool. The test it runs is on the mempool state at the time of the call, so it behaves as if you had done <code>sendrawtransaction</code> at that moment, except the part where the transaction is actually sent and added to the mempool.</p>

CC BY-SA 4.0
2020-11-02T23:34:35.337Z
2020-11-02T23:34:35.337Z
Ava Chow
<p>I have a protocol that creates a raw signed transaction that is then broadcast to the network. The transaction aims to send X BTC to a single address Z. The transaction is created with the help of bitcoin core.</p>
<p>In the past I've seen a few instances where people got themselves in trouble by creating unexpected transactions, for example by paying 90% of the UTXO's value as a mining fee or the like.</p>
<p>Therefore I was wondering if someone could advise on procedures/tips for the following</p>
<blockquote>
<p>Given a raw transaction T sending X BTC to address Z, how to validate the transaction accomplishes this gracefully?</p>
</blockquote>
<p>The idea is that before the broadcast one issues an additional decoderawtransaction and checks that everything is as intended. I would like to hear tips on what one should check for at this point.</p>
<p>I understand the question itself is a bit vague but I'd like to hear any kind of feedback on what to look for in the output of decoderawtransaction that might be telling something is either not right, or validate that</p>
<ol>
<li>The transaction is sending X BTC to Z,</li>
<li>What the exact expenditure (X+fees) is,</li>
<li>That the change is sent to the right (i.e under the wallet's control) address.</li>
</ol>

<transactions><raw-transaction><utxo>
Practical tips for validating raw transactions
Jernej
# Practical tips for validating raw transactions

(Asked by: username_0 on 2020-11-01)

I have a protocol that creates a raw signed transaction that is then broadcast to the network. The transaction aims to send X BTC to a single address Z. The transaction is created with the help of bitcoin core.

In the past I've seen a few instances where people got themselves in trouble by creating unexpected transactions, for example by paying 90% of the UTXO's value as a mining fee or the like.

Therefore I was wondering if someone could advise on procedures/tips for the following

> Given a raw transaction T sending X BTC to address Z, how to validate the transaction accomplishes this gracefully?

The idea is that before the broadcast one issues an additional decoderawtransaction and checks that everything is as intended. I would like to hear tips on what one should check for at this point.

I understand the question itself is a bit vague but I'd like to hear any kind of feedback on what to look for in the output of decoderawtransaction that might be telling something is either not right, or validate that

1. The transaction is sending X BTC to Z,
2. What the exact expenditure (X+fees) is,
3. That the change is sent to the right (i.e under the wallet's control) address.

**Tags:** transactions, raw-transaction, utxo


---

## 1 answers

### Answer by username_1 on 2020-11-02. Score: 1 | Accepted answer

A very useful RPC is the `testmempoolaccept` RPC. This will tell you whether the transaction would be accepted by the node. You can use this to determine whether the transaction is correctly signed. It will also tell you what the transaction fee is so you can determine whether the fee is what you expect it to be. If the transaction would not be accepted, it will also tell you what went wrong.

To ensure that the transaction is logically correct (i.e. money is being sent to the right place), you can use `decoderawtransaction` and examine the contents of the `vout` array. Each output is in that array and the value for the output and the address, if any, will be listed. So you can scan that array and make sure that the intended recipients are there with the correct values.

It is harder to determine change, but if you know what the change address is and what the change value should be, then you can check it as if it were another recipient as described earlier.

---

One caveat about `testmempoolaccept`: it only works if the parent transactions are confirmed or in the mempool. The test it runs is on the mempool state at the time of the call, so it behaves as if you had done `sendrawtransaction` at that moment, except the part where the transaction is actually sent and added to the mempool.


---

