qt: PSBT dialog reports broadcast success while networking is disabled #965

After Rob's wallet-creation finding, I created a Windows VM and asked Codex desktop to try 500 GUI scenarios it considered important. This observation came from that exploration. The system crashed with cyber concerns while I was investigating it, tried to reconstruct it from the logs, the details were given to an AI to convert into an issue, treat everything as a hint to investigate, not as final truth. If it's complete garbage, just close it.

Current behaviour

With GUI network activity disabled, the PSBT Operations dialog reports Transaction broadcast successfully! after a fully signed transaction is accepted into the local mempool, even though the node has no connections and cannot send it to a peer.

In the observed run, the GUI node had networkactive: false and zero connections. After Broadcast was pressed, transaction 3b355553b89e5eeaf7f90e448825a091ab49c6098b0bb1dcc5299a64ca6d6fe7 appeared in the GUI node's mempool with unbroadcast: true, while the controlled peer's mempool remained empty. The GUI displayed the transaction correctly as unconfirmed and reduced the wallet balance only by its 172 sat fee.

Network activity was then enabled and the controlled peer reconnected with transaction relay enabled. The first check still found the transaction marked unbroadcast: true and absent from the peer mempool. Loading the same signed PSBT and pressing Broadcast again relayed the same transaction bytes to the peer and changed unbroadcast to false. The retry did not create another transaction, fee or balance change.

This may be intended if “broadcast successfully” means that the transaction was accepted locally and queued for best-effort relay. If the message is intended to mean that the transaction was sent to the network, it is misleading while networking is disabled.

Expected behaviour

The result should distinguish local mempool acceptance from actual network relay. When networking is disabled, the dialog could report that the transaction was accepted locally and will be relayed when network activity resumes. If the current wording is intentional, clarifying what “broadcast successfully” guarantees would resolve this observation.

Steps to reproduce

<details> <summary>Regtest reproduction used for this observation</summary>

1. Run bitcoin-qt on regtest with a funded wallet and connect it to a controlled local regtest peer.
2. Create or load a fully signed PSBT. The observed PSBT spent one 1 BTC input, paid 0.25 BTC and 0.35 BTC to two wallet addresses, returned 0.39999828 BTC as change, and paid a 172 sat fee.
3. Use the GUI network icon to disable network activity.
4. Verify on the GUI node that getnetworkinfo reports networkactive: false and connections: 0.
5. In the PSBT Operations dialog, press Broadcast once.
6. Observe Transaction broadcast successfully! in the dialog.
7. Check the GUI node and the controlled peer:

gui_cli getmempoolentry 3b355553b89e5eeaf7f90e448825a091ab49c6098b0bb1dcc5299a64ca6d6fe7
peer_cli getrawmempool

The GUI node returned:

{
  "vsize": 172,
  "fees": {"base": 0.00000172},
  "unbroadcast": true
}

The controlled peer returned an empty mempool.

8. Re-enable network activity and wait for the controlled peer to reconnect.
9. Check the two mempools and unbroadcast again. In the observed run, the first check still showed unbroadcast: true and an empty peer mempool.
10. Load the same signed PSBT again and press Broadcast. The peer then received the same raw transaction, unbroadcast became false, and the wallet balance did not change again.

Stop both disposable regtest nodes when finished.

</details>

How did you obtain Bitcoin Core?

Compiled from source.

What version of Bitcoin Core are you using?

master@a174dd4017cf97f283b1848bb31998bfa28465e9.

Operating system and version

Windows Server 2025 Datacenter 10.0.26100 x64 in a VM, Qt 6.11.2, 100% display scale. The VM had an Intel Xeon Platinum 8259CL CPU with four logical processors. The tested bitcoin-qt.exe SHA256 was 6129AA462AD9D59D495ADFB7E6ED0D1141D27BF35B358EDD690F6D82921BBF92.

Additional context

The signed transaction had txid 3b355553b89e5eeaf7f90e448825a091ab49c6098b0bb1dcc5299a64ca6d6fe7, wtxid 28a975e664af0cbd1932f35625174587170c637de260144dfbc073bd6fd06f14, virtual size 172 vB and fee 172 sat. Before the first Broadcast click, the signed PSBT was independently decoded and its input, outputs, change and fee matched the reviewed contents.

PSBTOperationsDialog::broadcastTransaction() shows the success message when the node interface returns TransactionError::OK. In this case, BroadcastTransaction() accepts the transaction into the mempool, adds it to the unbroadcast set, asks peer management to initiate relay, and returns OK even when no peers are available. This explains the observed state but leaves the user-facing meaning of “broadcast successfully” unclear.

The peer was a controlled loopback regtest node using a manual v2 connection with transaction relay enabled. After reconnection it was synchronized at height 109. The check immediately after reconnection found no relay. Automatic delayed relay was not observed for longer, so this report does not establish that the transaction would remain unrelayed without the manual retry.

I searched open and closed issues and pull requests. The closest discussions I found were #56 about broader offline and multisig UX and #644 about checking PSBTs with testmempoolaccept. Neither describes this exact success message and unbroadcast state.

Why this remains unconfirmed

The displayed success message, local acceptance, unbroadcast state and lack of immediate peer relay were all observed directly. What remains unconfirmed is whether the wording violates the intended GUI contract and whether normal delayed relay would have sent the transaction after reconnection without another Broadcast click. No funds were lost, no duplicate transaction was created, and the wallet balance remained correct.