<p>Transaction resubmissions is the same for all wallets, regardless of whether they are watch-only or not. If your wallet is loaded and it has unconfirmed transactions, those transactions will be resubmitted to the mempool periodically.</p>
<p>However, in order for a transaction to be stored in the wallet so that this resubmission can occur, it must have either been created and sent by that wallet, or made it into the mempool at some point in time so that it can be added to the wallet. If you are using the PSBT or raw transaction workflow (as you have to with a watch-only wallet), then only the latter applies as these workflows bypass the wallet's sending mechanism.</p>
<p>Thus for watch-only wallets, if your transaction does not make it into the mempool initially, then it will not be periodically resubmitted by the wallet as the wallet will not know about the transaction in order to do so.</p>

CC BY-SA 4.0
2024-02-17T02:53:29.283Z
Is there any interest by bitcoin core to make transactions submitted using the PSBT or raw transaction workflows notify the resubmitter logic without the transaction reaching the mempool first? Just trying to figure out if there is an intentional architectural reason for this or if it is just that no one has had time to make this capability yet. I realize there are privacy considerations for being a broadcaster of a transaction, but there could be some other reasons too. It seems to me like if a transaction is received from the RPC and not a random peer, you would want to always prioritize it.
user1748155
CC BY-SA 4.0
2024-02-17T04:05:18.787Z
It's an intentional decision to modularize and separate components of Bitcoin Core. As `sendrawtransaction` is a node RPC, it shouldn't have a direct interaction with the wallet. However, there could be a way to implement it using the new interfaces, or with a wallet specific RPC. This probably hasn't been attempted as I don't think it's something that someone has thought to ask for previously.
Ava Chow
CC BY-SA 4.0
2024-02-16T19:44:20.667Z
2024-02-16T19:44:20.667Z
Ava Chow
<p>The questions <a href="https://bitcoin.stackexchange.com/questions/96068/what-if-the-mempool-exceeds-300-mb">What if the mempool exceeds 300 MB?</a> , <a href="https://bitcoin.stackexchange.com/questions/103261/does-my-node-rebroadcast-its-mempool-transactions-on-startup">Does my node rebroadcast its mempool transactions on startup?</a> , <a href="https://bitcoin.stackexchange.com/questions/114973/why-rebroadcasting-transactions-in-the-bitcoin-core">Why rebroadcasting transactions in the Bitcoin Core?</a> , and <a href="https://bitcoin.stackexchange.com/questions/117200/rebroadcast-unconfirmed-transaction">rebroadcast unconfirmed transaction</a> suggest that bitcoin core will periodically re-broadcast a transaction from a local wallet that gets evicted from the mempool.</p>
<p>I'm wondering what bitcoind does if I submit a raw transaction with a minimum fee that is 1 sat/vbyte for a local <em>watching only</em> wallet when the mempool is full and the <code>mempoolminfee</code> is higher than 1 sat/vbyte? Does bitcoin core have a &quot;special mempool&quot; for transactions that it knows is part of its own wallet? Or, will bitcoin core reject that raw transaction? My mempool is not currently full, so I can't test this scenario. The scenario I'm asking about is different from the questions above because in the above questions, I believe the transaction fit in the mempool and was evicted, but I'm asking about if it never would have fit in the first place.</p>
<p>The context of this question is related to Sparrow wallet. When I use Sparrow wallet with an electrum server, the electrum server may reject transactions that won't fit in the mempool. This is very annoying because you can't submit low fee transactions when the mempool is full of high fee transactions. Electrum servers behave this way because they don't have any context of a personal wallet, so they don't want to accept a bunch of low fee transactions from everyone.</p>
<p>Sparrow wallet also has a mode where it will work with a local bitcoind instance using the RPC. In that case, Sparrow sets up a watching only descriptor wallet in bitcoind and lets bitcoind track the wallet for it. I'm wondering if since bitcoind is specifically tracking the Sparrow wallet, will it accept very low fee transactions, hold them, and periodically try to add them to the mempool and rebroadcast them when the mempool finally sets the <code>mempoolminfee</code> to a low enough value?</p>

<bitcoin-core><wallet><bitcoind><transaction-fees><mempool>
will bitcoind accept, hold, and rebroadcast a 1 sat/vbyte raw transaction via the RPC for a local wallet that won't fit in the mempool when submitted?
user1748155
# will bitcoind accept, hold, and rebroadcast a 1 sat/vbyte raw transaction via the RPC for a local wallet that won't fit in the mempool when submitted?

(Asked by: username_0 on 2024-02-16)

The questions [What if the mempool exceeds 300 MB?](https://bitcoin.stackexchange.com/questions/96068/what-if-the-mempool-exceeds-300-mb) , [Does my node rebroadcast its mempool transactions on startup?](https://bitcoin.stackexchange.com/questions/103261/does-my-node-rebroadcast-its-mempool-transactions-on-startup) , [Why rebroadcasting transactions in the Bitcoin Core?](https://bitcoin.stackexchange.com/questions/114973/why-rebroadcasting-transactions-in-the-bitcoin-core) , and [rebroadcast unconfirmed transaction](https://bitcoin.stackexchange.com/questions/117200/rebroadcast-unconfirmed-transaction) suggest that bitcoin core will periodically re-broadcast a transaction from a local wallet that gets evicted from the mempool.

I'm wondering what bitcoind does if I submit a raw transaction with a minimum fee that is 1 sat/vbyte for a local *watching only* wallet when the mempool is full and the `mempoolminfee` is higher than 1 sat/vbyte? Does bitcoin core have a "special mempool" for transactions that it knows is part of its own wallet? Or, will bitcoin core reject that raw transaction? My mempool is not currently full, so I can't test this scenario. The scenario I'm asking about is different from the questions above because in the above questions, I believe the transaction fit in the mempool and was evicted, but I'm asking about if it never would have fit in the first place.

The context of this question is related to Sparrow wallet. When I use Sparrow wallet with an electrum server, the electrum server may reject transactions that won't fit in the mempool. This is very annoying because you can't submit low fee transactions when the mempool is full of high fee transactions. Electrum servers behave this way because they don't have any context of a personal wallet, so they don't want to accept a bunch of low fee transactions from everyone.

Sparrow wallet also has a mode where it will work with a local bitcoind instance using the RPC. In that case, Sparrow sets up a watching only descriptor wallet in bitcoind and lets bitcoind track the wallet for it. I'm wondering if since bitcoind is specifically tracking the Sparrow wallet, will it accept very low fee transactions, hold them, and periodically try to add them to the mempool and rebroadcast them when the mempool finally sets the `mempoolminfee` to a low enough value?

**Tags:** bitcoin-core, wallet, bitcoind, transaction-fees, mempool


---

## 1 answers

### Answer by username_1 on 2024-02-16. Score: 3 | Accepted answer

Transaction resubmissions is the same for all wallets, regardless of whether they are watch-only or not. If your wallet is loaded and it has unconfirmed transactions, those transactions will be resubmitted to the mempool periodically.

However, in order for a transaction to be stored in the wallet so that this resubmission can occur, it must have either been created and sent by that wallet, or made it into the mempool at some point in time so that it can be added to the wallet. If you are using the PSBT or raw transaction workflow (as you have to with a watch-only wallet), then only the latter applies as these workflows bypass the wallet's sending mechanism.

Thus for watch-only wallets, if your transaction does not make it into the mempool initially, then it will not be periodically resubmitted by the wallet as the wallet will not know about the transaction in order to do so.

> **Comments:**
> **username_0**: Is there any interest by bitcoin core to make transactions submitted using the PSBT or raw transaction workflows notify the resubmitter logic without the transaction reaching the mempool first? Just trying to figure out if there is an intentional architectural reason for this or if it is just that no one has had time to make this capability yet. I realize there are privacy considerations for being a broadcaster of a transaction, but there could be some other reasons too. It seems to me like if a transaction is received from the RPC and not a random peer, you would want to always prioritize it.  
> **username_1**: It's an intentional decision to modularize and separate components of Bitcoin Core. As `sendrawtransaction` is a node RPC, it shouldn't have a direct interaction with the wallet. However, there could be a way to implement it using the new interfaces, or with a wallet specific RPC. This probably hasn't been attempted as I don't think it's something that someone has thought to ask for previously.  

---

