Related question: Test that mempool reattempts delivery of locally submitted transaction

I tried running hidden RPC mockscheduler, I think it worked that day after relaunching nodes few times and trying different things. Today again I am not able to do the relay similar to unbroadcast test.

  1. Start Node 1
  2. Start Node 2 with Node 1 in addnode
  3. Use sendtoaddress to send some bitcoin to own address in Node 2
  4. Check transaction is in getrawmempool and 1 unbroadcast in getmempoolinfo
  5. Node 1 doesn't have these transactions in getrawmempool
  6. Restart nodes
  7. Run this multiple times because its not doing anything: bitcoin-cli -regtest mockscheduler 900
  8. Nothing changes in getrawmempool or getmempoolinfo

After reading lot of things I think the reason is Node 1 not sending getdata request based on:

With these changes, the mempool tracks locally submitted transactions & periodically reattempts initial broadcast. Transactions submitted via the wallet or RPC are added to an "unbroadcast" set & are removed when a peer sends a getdata request, or the transaction is removed from the mempool. Every 10-15 minutes, the node reattempts an initial broadcast.


I checked the packets in Wireshark to see what's going on because debug=mempool and debug=net spams with so many things that are confusing. I found that Node 2 had sent getdata packet with 13 hashes:



getrawmempool returns txid and we see wtxid in Wireshark. I reversed one from Wireshark to get wtxid

INV: 9f5e3c78e1e6a4f7f12b1e876ba6dadfcf3df6812a3ac214dda2455284e0e079

WTXID: 79e0e0845245a2dd14c23a2a81f63dcfdfdaa66b871e2bf1f7a4e6e1783c5e9f

However getrawtransaction doesn't accept wtxid so I am not sure how to check if this transaction belongs to Node 1 or Node 2. I am guessing its Node 1's transaction.

I have no clue what's going wrong and why simple relay for a transaction is not working between these 2 nodes.

  • On which node are you doing mockscheduler on? It has to be run on the node with the txs in the mempool. The wtxid is listed under hash in getrawtransaction. getrawmempool true and getmempoolentry also lists it as wtxid.
    – Ava Chow
    Aug 2, 2021 at 21:53
  • Both nodes have some transactions in mempool. Although I did mockscheduler on Node 2. Now restarted both. Did it on both nodes. Still Node 2 has 1 unbroadcastcount. Thanks for sharing this getrawmempool true which confirms the transaction I'd mentioned above was from Node 1. If it was sent to Node 2 it should have been in it's mempool though.
    – user103136
    Aug 2, 2021 at 22:08
  • After restarting, are the nodes connected to each other?
    – Ava Chow
    Aug 2, 2021 at 22:13
  • Yes. getpeerinfo on Node 1: pastebin.com/raw/VPNYzBP2 and Node 2: pastebin.com/raw/VxBDaBZC
    – user103136
    Aug 2, 2021 at 22:31

1 Answer 1


The steps that you have outlined don't make sense for what you are trying to achieve. You want to make sure that node 2 attempts to broadcast unbroadcasted transactions after 15 minutes. But node 2 and node 1 are connected when you do sendtoaddress, so the transaction that is not supposed to be broadcast is sent to node 1. That's not correct, and that's not what the test does.

To achieve the behavior that you want, you have to start node 2 without connecting it to node 1. They should be disconnected when you do the sendtoaddress. You should only be connecting the nodes after sendtoaddress completes. Then you should be able to observe the broadcast after 15 minutes behavior.

You are probably seeing node 1 doesn't have the transaction immediately after you do sendtoaddress because there is some delay between when the node processes the transaction and when it queues it to be broadcast to its peers. So if you are very fast on checking getrawmempool and getmempoolinfo`, then you will probably observe that the transaction is not broadcast yet. But this is a race condition, and it could be broadcast between your mempool checks and shutdown. This would then cause your later checks to fail.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.