bitcoin-cli decoderawtransaction

[zoltanb]

So, I have a signed raw transaction with 1 input and 1 output.
If somebody gets this signed raw transaction the only thing he can do with it is to broadcast the transaction (if it is not yet broadcasted), right?

So, even if the input is signed nobody can alter the transaction to send the input to other output(s), right?

In other words:
- inputs are locked
- outputs are locked
- amounts are locked
- nobody will be able to spend the specific txid and vout to another output(s)
- nobody can find out the private key of my spending addresses

If this is true (and I assume it is), what is the safest way to check that all inputs are signed and the transaction can be broadcasted and it won't generate an error? Can I test the transaction will go through without broadcasting it?

Thanks in advance for all your comments.

[LoyceV]

In other words:
- inputs are locked
- outputs are locked
- amounts are locked
- nobody will be able to spend the specific txid and vout to another output(s)
- nobody can find out the private key of my spending addresses

All of this has to be true, otherwise anyone could do the same right after you broadcast the transaction (which also makes it public).

what is the safest way to check that all inputs are signed and the transaction can be broadcasted and it won't generate an error? Can I test the transaction will go through without broadcasting it?

I would use coinb.in after downloading it and copying to an offline air-gapped system running from a Linux LIVE DVD.

[achow101]

Can I test the transaction will go through without broadcasting it?

You can use the testmempoolaccept command.

[zoltanb]

Can I test the transaction will go through without broadcasting it?

You can use the testmempoolaccept command.

Thanks. testmempoolaccept is the command I was looking for. According to https://bitcoincore.org/en/doc/0.20.0/rpc/rawtransactions/testmempoolaccept/ the result can be true or false.
I checked with a transaction that was already broadcasted and obviously it returned as false because the inputs are not present anymore.

{
    "txid": "c77c...042b",
    "allowed": false,
    "reject-reason": "missing-inputs"
}

If a transaction is not broadcasted yet, does this also check if the inputs are signed or not?
Or, what are all the "reject-reason"-s messages I can receive? Couldn't find it anywhere.

[achow101]

If a transaction is not broadcasted yet, does this also check if the inputs are signed or not?

Yes. It does every check that would occur if the transaction were broadcast. It is the exact same code paths as the actual mempool acceptance logic, minus the part where it is added to the mempool.

Or, what are all the "reject-reason"-s messages I can receive? Couldn't find it anywhere.

All possible validation results can be found in the TxValidationResult enum at https://github.com/bitcoin/bitcoin/blob/master/src/consensus/validation.h#L24

Does it test against default bitcoin core configuration or your own bitcoin core configuration?

It tests against whatever is currently running.

[zoltanb]

Thank you achow101. You have been of great help.

[zoltanb]

Can I test the transaction will go through without broadcasting it?

You can use the testmempoolaccept command.

Is there a way to use the testmempoolaccept cli command to not return false information if one of the inputs are not yet included in a block?
I tried the testmempoolaccept with 2 inputs, one has several hundreds of confirmations, the other one is not included yet in a block (is a zeroconf input).

"allowed": false,
"reject-reason": "missing-inputs"

I assume it rejects the transaction because I am trying to spend an input that is not yet confirmed. However, what if I want to spend that input on a CPFP transaction to broadcast the original transaction faster?

[nc50lc]

I assume it rejects the transaction because I am trying to spend an input that is not yet confirmed. However, what if I want to spend that input on a CPFP transaction to broadcast the original transaction faster?

It should return "true" even if the inputs aren't included in a block.
It's probably because the parent is currently "not in memory pool", using sendrawtransaction to the parent before attempting to use testmempoolaccept to the child should work.

[achow101]

Is there a way to use the testmempoolaccept cli command to not return false information if one of the inputs are not yet included in a block?
I tried the testmempoolaccept with 2 inputs, one has several hundreds of confirmations, the other one is not included yet in a block (is a zeroconf input).

"allowed": false,
"reject-reason": "missing-inputs"

I assume it rejects the transaction because I am trying to spend an input that is not yet confirmed. However, what if I want to spend that input on a CPFP transaction to broadcast the original transaction faster?

testmempoolaccept should work if an input is in the mempool. Your input may not be in the mempool, you can check this by using getmempoolentry with the txid.

Currently testmempoolaccept also does not allow you to provide the child transaction either, but there is ongoing work to support that.