<p>You're running in <code>blocksonly</code> mode, which by default disables the broadcasting of wallet transactions. This is for privacy reasons: in blocksonly mode you don't participate in general in transaction relay. If then suddenly your node is seen broadcasting a transaction anyway, it would be very apparent to your peers that the transaction is yours.</p>
<p>Possible solutions:</p>
<ul>
<li>Disable blocksonly mode.</li>
<li>Forcibly enable wallet broadcasting (<code>walletbroadcast=1</code> in the config file), accepting the privacy risk.</li>
<li>Manually broadcast the transaction through <code>sendrawtransaction</code>.</li>
</ul>
<p>There does exist a wallet rebroadcast mechanism, which will occasionally (every 12 to 36 hours) broadcast unconfirmed wallet transactions again (if wallet broadcasting is enabled at all). So if you disable blocksonly mode, or enable wallet broadcasting, and restart, the transaction should eventually make it out. The third option is a lot faster though.</p>

CC BY-SA 4.0
2023-12-06T21:38:13.813Z
2023-12-07T00:01:27.240Z
2023-12-07T00:01:27.240Z
Pieter Wuille
<p>I sent transaction with bitcoin-cli:</p>
<pre class="lang-sh prettyprint-override"><code>bitcoin-cli sendtoaddress tb1q3qlv7k648hec866a0x395hq0h3sqcg2lrq5r0k 0.001
</code></pre>
<p>As an answer I've got transaction Id.</p>
<p>But it still has no confirmation (a few hours).</p>
<p>Bellow are some details:</p>
<p>Network: signet.</p>
<p>Bitcoin core 25.0.0</p>
<p>Blockchain is synced.</p>
<p><strong>Transaction:</strong></p>
<pre class="lang-json prettyprint-override"><code> {
     &quot;address&quot;: &quot;tb1q3qlv7k648hec866a0x395hq0h3sqcg2lrq5r0k&quot;,
     &quot;category&quot;: &quot;send&quot;,
     &quot;amount&quot;: -0.00100000,
     &quot;vout&quot;: 0,
     &quot;fee&quot;: -0.00014100,
     &quot;confirmations&quot;: 0,
     &quot;trusted&quot;: false,
     &quot;txid&quot;: &quot;f0aaf3aeca4590521557ce20bf12f2f8b4ec2520bebc45ab7958f87f08965c2f&quot;,
     &quot;wtxid&quot;: &quot;4c053b7ac21b0c86febb427d377d57b5397c4e4884c8a2397d1c3405b6ab7040&quot;,
     &quot;walletconflicts&quot;: [
     ],
     &quot;time&quot;: 1701862331,
     &quot;timereceived&quot;: 1701862331,
     &quot;bip125-replaceable&quot;: &quot;yes&quot;,
     &quot;abandoned&quot;: false   
}
</code></pre>
<p><strong>bitcoin.conf:</strong></p>
<pre><code>    chain=signet
    blocksonly=1
    daemon=1
    dbcache=4000
    txindex=1
    debug=1
    logips=1
    fallbackfee=0.001
</code></pre>
<p>What can be wrong?</p>

CC BY-SA 4.0
2023-12-06T19:33:25.670Z
What RPC did you use, and what error did you receive back?
Murch
CC BY-SA 4.0
2023-12-06T20:11:51.167Z
I've got no errors. How can I check my RPC?
Nikolai Kushpela
CC BY-SA 4.0
2023-12-06T20:15:07.630Z
@MikkiUkraine Please update your question to include what you are trying to achieve, how you are doing that, what do you expect to see, and what you are seeing instead? It is entirely unclear from your current question what the problem is.
Pieter Wuille
CC BY-SA 4.0
2023-12-06T20:47:24.377Z
@PieterWuille Updated
Nikolai Kushpela
CC BY-SA 4.0
2023-12-07T18:18:32.050Z
I took the liberty to edit the title of your question to be closer to what was happening. Feel free to suggest edit/revert if that doesn't capture your intent.
Pieter Wuille
<bitcoin-core><bitcoind><bitcoin-cli><ubuntu><bitcoin.conf>
Wallet transaction not confirming in blocksonly mode
Nikolai Kushpela
# Wallet transaction not confirming in blocksonly mode

(Asked by: username_0 on 2023-12-06)

I sent transaction with bitcoin-cli:
bitcoin-cli sendtoaddress tb1q3qlv7k648hec866a0x395hq0h3sqcg2lrq5r0k 0.001

As an answer I've got transaction Id.
But it still has no confirmation (a few hours).
Bellow are some details:
Network: signet.
Bitcoin core 25.0.0
Blockchain is synced.
Transaction:
 {
     "address": "tb1q3qlv7k648hec866a0x395hq0h3sqcg2lrq5r0k",
     "category": "send",
     "amount": -0.00100000,
     "vout": 0,
     "fee": -0.00014100,
     "confirmations": 0,
     "trusted": false,
     "txid": "f0aaf3aeca4590521557ce20bf12f2f8b4ec2520bebc45ab7958f87f08965c2f",
     "wtxid": "4c053b7ac21b0c86febb427d377d57b5397c4e4884c8a2397d1c3405b6ab7040",
     "walletconflicts": [
     ],
     "time": 1701862331,
     "timereceived": 1701862331,
     "bip125-replaceable": "yes",
     "abandoned": false   
}

bitcoin.conf:
    chain=signet
    blocksonly=1
    daemon=1
    dbcache=4000
    txindex=1
    debug=1
    logips=1
    fallbackfee=0.001

What can be wrong?

**Tags:** bitcoin-core, bitcoind, bitcoin-cli, ubuntu, bitcoin.conf

> **Comments:**
> **username_1**: What RPC did you use, and what error did you receive back?  
> **username_0**: I've got no errors. How can I check my RPC?  
> **username_2**: @MikkiUkraine Please update your question to include what you are trying to achieve, how you are doing that, what do you expect to see, and what you are seeing instead? It is entirely unclear from your current question what the problem is.  
> **username_0**: @PieterWuille Updated  
> **username_2**: I took the liberty to edit the title of your question to be closer to what was happening. Feel free to suggest edit/revert if that doesn't capture your intent.  

---

## 1 answers

### Answer by username_2 on 2023-12-06. Score: 1 | Accepted answer

You're running in `blocksonly` mode, which by default disables the broadcasting of wallet transactions. This is for privacy reasons: in blocksonly mode you don't participate in general in transaction relay. If then suddenly your node is seen broadcasting a transaction anyway, it would be very apparent to your peers that the transaction is yours.

Possible solutions:

* Disable blocksonly mode.
* Forcibly enable wallet broadcasting (`walletbroadcast=1` in the config file), accepting the privacy risk.
* Manually broadcast the transaction through `sendrawtransaction`.

There does exist a wallet rebroadcast mechanism, which will occasionally (every 12 to 36 hours) broadcast unconfirmed wallet transactions again (if wallet broadcasting is enabled at all). So if you disable blocksonly mode, or enable wallet broadcasting, and restart, the transaction should eventually make it out. The third option is a lot faster though.


---

