<p>The described behavior does not make sense to me. The <a href="https://bitcoincore.org/en/doc/25.0.0/rpc/rawtransactions/sendrawtransaction/" rel="nofollow noreferrer"><code>sendrawtransaction</code></a> is a node RPC that takes a raw transaction and submits it to the local node’s mempool. If the transaction makes it into the local node’s mempool, the node will relay it to its peers. To that end, the transaction must already be complete. The RPC will work for any valid transaction and does not even require a wallet to be active on the node. Since you could even rebroadcast foreign transactions that way, it seems implausible that the <code>sendrawtransaction</code> call would interact with private keys in any way whatsoever.</p>

CC BY-SA 4.0
2023-10-30T14:22:11.083Z
Yes, in fact, I got this behaviour because I was only considering the utxos that were spendable. Something like if utxo['spendable'] then add it to outputs.
It follows that it was the wrong thing to do since the outputs will be empty if the wallet doesn't have the private keys.
Nahum Maurice
CC BY-SA 4.0
2023-10-30T14:06:20.433Z
2023-10-30T15:00:28.660Z
2023-10-30T15:00:28.660Z
Murch
<p>My question has already been asked before, and some answers were also already given
<a href="https://bitcoin.stackexchange.com/questions/23694/is-it-possible-to-send-coins-without-importing-private-key">the question</a>, however, it's not clear to me why I get some behaviour when implementing it. Here are the details:</p>
<p>I created my transaction and signed it offline, without interacting with bitcoind. But, when I broadcast it to the network (or test acceptability by mempool), it doesn't work unless I import the private key to bitcoind through the rpc command <strong>importprivkey</strong>.</p>
<p>I inspected the bitcoin code to understand why it does behave like that, but unfortunately, I don't quite understand where it does verify for the private key or check that it was imported. As I understand, the transaction's broadcast happens here <a href="https://github.com/bitcoin/bitcoin/blob/2a349f9ea5de9f0157cd117289996e8640473a6d/src/rpc/mempool.cpp#L34" rel="nofollow noreferrer">sendrawtransaction</a>.</p>
<p>Please, can someone explain why it does happen and/or provide a way to just broadcast raw transactions to the network without importing private keys into bitcoind?</p>

CC BY-SA 4.0
2023-10-30T12:12:36.243Z
This is very strange; `sendrawtransaction` is a node RPC and `importprivkey` is a wallet RPC; the two should be completely unrelated, and there is absolutely no requirement that a transaction's private key(s) are imported in order to broadcast a transaction or get it accepted to the mempool. Can you update your post with detailed steps to reproduce the problem?
Pieter Wuille
CC BY-SA 4.0
2023-10-30T12:38:56.020Z
I think you are right. It didn't work because I was checking that the utxos were spendable before adding them to the transactions. After reading you, I realise that you should be right.
Nahum Maurice
<bitcoin-core><bitcoin-core-development><private-key-import><sendrawtransaction>
Broadcast transactions through bitcoind without importing private key
Nahum Maurice
# Broadcast transactions through bitcoind without importing private key

(Asked by: username_0 on 2023-10-30)

My question has already been asked before, and some answers were also already given
[the question](https://bitcoin.stackexchange.com/questions/23694/is-it-possible-to-send-coins-without-importing-private-key), however, it's not clear to me why I get some behaviour when implementing it. Here are the details:

I created my transaction and signed it offline, without interacting with bitcoind. But, when I broadcast it to the network (or test acceptability by mempool), it doesn't work unless I import the private key to bitcoind through the rpc command **importprivkey**.

I inspected the bitcoin code to understand why it does behave like that, but unfortunately, I don't quite understand where it does verify for the private key or check that it was imported. As I understand, the transaction's broadcast happens here [sendrawtransaction](https://github.com/bitcoin/bitcoin/blob/2a349f9ea5de9f0157cd117289996e8640473a6d/src/rpc/mempool.cpp#L34).

Please, can someone explain why it does happen and/or provide a way to just broadcast raw transactions to the network without importing private keys into bitcoind?

**Tags:** bitcoin-core, bitcoin-core-development, private-key-import, sendrawtransaction

> **Comments:**
> **username_1**: This is very strange; `sendrawtransaction` is a node RPC and `importprivkey` is a wallet RPC; the two should be completely unrelated, and there is absolutely no requirement that a transaction's private key(s) are imported in order to broadcast a transaction or get it accepted to the mempool. Can you update your post with detailed steps to reproduce the problem?  
> **username_0**: I think you are right. It didn't work because I was checking that the utxos were spendable before adding them to the transactions. After reading you, I realise that you should be right.  

---

## 1 answers

### Answer by username_2 on 2023-10-30. Score: 2 | Accepted answer

The described behavior does not make sense to me. The [`sendrawtransaction`](https://bitcoincore.org/en/doc/25.0.0/rpc/rawtransactions/sendrawtransaction/) is a node RPC that takes a raw transaction and submits it to the local node’s mempool. If the transaction makes it into the local node’s mempool, the node will relay it to its peers. To that end, the transaction must already be complete. The RPC will work for any valid transaction and does not even require a wallet to be active on the node. Since you could even rebroadcast foreign transactions that way, it seems implausible that the `sendrawtransaction` call would interact with private keys in any way whatsoever.

> **Comments:**
> **username_0**: Yes, in fact, I got this behaviour because I was only considering the utxos that were spendable. Something like if utxo['spendable'] then add it to outputs. It follows that it was the wrong thing to do since the outputs will be empty if the wallet doesn't have the private keys.  

---

