<blockquote>
<ol>
<li>I'm not sure I correctly understand the usage of the <code>CWallet</code> class. By reading the comments and code, I think this class manages the transactions of the Bitcoin Core's node itself and it plays as a role of regular wallet (beside the fact that it is running on a node). It creates transactions and manages UTXOs. Is this correct?</li>
</ol>
</blockquote>
<p>Yes, <code>CWallet</code> is the core of Bitcoin Core's wallet implementation. It tracks the user's transactions and addresses, and constructs and signs transactions.</p>
<blockquote>
<ol start="2">
<li>I tried to figure out the reason behind rebroadcasting from comments above, but couldn't understand anything useful. What is the need to rebroadcast a transaction? As its name suggest, it is broadcasting a previously broadcasted transaction. So why should we want such a thing? Isn't broadcasting once sufficient?</li>
</ol>
</blockquote>
<p>Bitcoin's P2P network doesn't guarantee reliable transmission, especially about unconfirmed transactions. Maybe you were only connected to one or a few nodes, and maybe they went offline right after receiving your transaction. Maybe they were light clients, were broken, or were even malicious, and ignored your transaction entirely.</p>
<p>Even if your transaction made it to a large portion of the network's nodes, it may have gotten evicted from the mempools of those nodes if there was a large wave of higher-fee transactions than yours. If so, it's possible the network may just have forgotten about your transactions.</p>
<p>Especially if it is an incoming payment, the responsibility is on you to get the transaction confirmed. To a lesser extent this is true for the sender as well. The way to accomplish this is broadcasting it to the network, and if it appears to not get mined, occasionally attempt to rebroadcast it.</p>
<p>There has been work around moving this responsibility from the wallet to the mempool. The most important reason for this is privacy: rebroadcasting is a very obvious signal <em>you</em> care about a transaction, as parties not involved in the transaction don't perform this rebroadcasting. If rebroadcasting would be done more generally for all transactions in your mempool (not just ones affecting your own wallet), it would be less obvious.</p>
<blockquote>
<ol start="3">
<li>Even if the flag <code>fBroadcastTransactions</code> is set to <code>true</code>, the function waits until <code>GetTime()</code> is greater that the <code>nNextResend</code>, and this variable is set to at least 12 hours later from <code>GetTime()</code>. So this means that someone who uses the Bitcoin Core's wallet, should wait at least 12 hour for the transaction to be broadcasted? I'm pretty sure that I'm wrong but can't figure out where.</li>
</ol>
</blockquote>
<p>That's exactly right. A rebroadcast event is scheduled somewhat randomly, with 12 to 36 hours between events.</p>

CC BY-SA 4.0
2022-08-21T04:57:39.943Z
Thanks for the answer, so you mean it is possible that a transaction I sent using the Bitcoin Core wallet will be confirmed 12 hours later due to rebroadcasting latency? (even with enough tx fee). Isn't it a flaw for the wallet?
Amir reza Riahi
CC BY-SA 4.0
2022-08-21T12:19:09.200Z
It is possible that a broadcasted transaction isn't confirmed at all, ever. This is true for every wallet, and there is nothing the wallet can do about it but retry to get the transaction known to the network. It only does this every 12 hours because doing it very frequently is a privacy leak.
Pieter Wuille
CC BY-SA 4.0
2022-08-20T18:51:38.503Z
2022-08-20T19:02:51.867Z
2022-08-20T19:02:51.867Z
Pieter Wuille
<p>There is a function <a href="https://github.com/bitcoin/bitcoin/blob/e40ddf36bed81bdf28d386eb961c9ed22b69e207/src/wallet/wallet.cpp#L1903" rel="nofollow noreferrer">here</a>, named <code>ResendWalletTransactions</code> in the Bitcoin Core:</p>
<pre><code>// Rebroadcast transactions from the wallet. We do this on a random timer
// to slightly obfuscate which transactions come from our wallet.
//
// Ideally, we'd only resend transactions that we think should have been
// mined in the most recent block. Any transaction that wasn't in the top
// blockweight of transactions in the mempool shouldn't have been mined,
// and so is probably just sitting in the mempool waiting to be confirmed.
// Rebroadcasting does nothing to speed up confirmation and only damages
// privacy.
void CWallet::ResendWalletTransactions()
{
    // During reindex, importing and IBD, old wallet transactions become
    // unconfirmed. Don't resend them as that would spam other nodes.
    if (!chain().isReadyToBroadcast()) return;

    // Do this infrequently and randomly to avoid giving away
    // that these are our transactions.
    if (GetTime() &lt; nNextResend || !fBroadcastTransactions) return;
    bool fFirst = (nNextResend == 0);
    // resend 12-36 hours from now, ~1 day on average.
    nNextResend = GetTime() + (12 * 60 * 60) + GetRand(24 * 60 * 60);
    if (fFirst) return;

    int submitted_tx_count = 0;

    { // cs_wallet scope
        LOCK(cs_wallet);

        // Try to add wallet transactions to memory pool
        for (auto wtx : GetSortedTxs()) {
            // Attempt to rebroadcast all txes more than 5 minutes older than
            // the last block. SubmitTxMemoryPoolAndRelay() will not rebroadcast
            // any confirmed or conflicting txs.
            if (wtx-&gt;nTimeReceived &gt; m_best_block_time - 5 * 60) continue;
            std::string unused_err_string;
            if (SubmitTxMemoryPoolAndRelay(*wtx, unused_err_string, true)) ++submitted_tx_count;
        }
    } // cs_wallet

    if (submitted_tx_count &gt; 0) {
        WalletLogPrintf(&quot;%s: resubmit %u unconfirmed transactions\n&quot;, __func__, submitted_tx_count);
    }
}
</code></pre>
<ol>
<li><p>I'm not sure I correctly understand the usage of the <code>CWallet</code> class. By reading the comments and code, I think this class manages the transactions of the Bitcoin Core's node itself and it plays as a role of regular wallet (beside the fact that it is running on a node). It creates transactions and manages UTXOs. Is this correct?</p>
</li>
<li><p>I tried to figure out the reason behind rebroadcasting from comments above, but couldn't understand anything useful. What is the need to rebroadcast a transaction? As its name suggest, it is broadcasting a previously broadcasted transaction. So why should we want such a thing? Isn't broadcasting once sufficient?</p>
</li>
<li><p>Even if the flag <code>fBroadcastTransactions</code> is set to <code>true</code>, the function waits until <code>GetTime()</code> is greater that the <code>nNextResend</code>, and this variable is set to at least 12 hours later from <code>GetTime()</code>. So this means that someone who uses the Bitcoin Core's wallet, should wait at least 12 hour for the transaction to be broadcasted? I'm pretty sure that I'm wrong but can't figure out where.</p>
</li>
</ol>
<p>Thanks for any help.</p>

<transactions><wallet><bitcoin-core-development>
Why rebroadcasting transactions in the Bitcoin Core?
Amir reza Riahi
# Why rebroadcasting transactions in the Bitcoin Core?

(Asked by: username_0 on 2022-08-20)

There is a function [here](https://github.com/bitcoin/bitcoin/blob/e40ddf36bed81bdf28d386eb961c9ed22b69e207/src/wallet/wallet.cpp#L1903), named `ResendWalletTransactions` in the Bitcoin Core:

```
// Rebroadcast transactions from the wallet. We do this on a random timer
// to slightly obfuscate which transactions come from our wallet.
//
// Ideally, we'd only resend transactions that we think should have been
// mined in the most recent block. Any transaction that wasn't in the top
// blockweight of transactions in the mempool shouldn't have been mined,
// and so is probably just sitting in the mempool waiting to be confirmed.
// Rebroadcasting does nothing to speed up confirmation and only damages
// privacy.
void CWallet::ResendWalletTransactions()
{
    // During reindex, importing and IBD, old wallet transactions become
    // unconfirmed. Don't resend them as that would spam other nodes.
    if (!chain().isReadyToBroadcast()) return;

    // Do this infrequently and randomly to avoid giving away
    // that these are our transactions.
    if (GetTime() < nNextResend || !fBroadcastTransactions) return;
    bool fFirst = (nNextResend == 0);
    // resend 12-36 hours from now, ~1 day on average.
    nNextResend = GetTime() + (12 * 60 * 60) + GetRand(24 * 60 * 60);
    if (fFirst) return;

    int submitted_tx_count = 0;

    { // cs_wallet scope
        LOCK(cs_wallet);

        // Try to add wallet transactions to memory pool
        for (auto wtx : GetSortedTxs()) {
            // Attempt to rebroadcast all txes more than 5 minutes older than
            // the last block. SubmitTxMemoryPoolAndRelay() will not rebroadcast
            // any confirmed or conflicting txs.
            if (wtx->nTimeReceived > m_best_block_time - 5 * 60) continue;
            std::string unused_err_string;
            if (SubmitTxMemoryPoolAndRelay(*wtx, unused_err_string, true)) ++submitted_tx_count;
        }
    } // cs_wallet

    if (submitted_tx_count > 0) {
        WalletLogPrintf("%s: resubmit %u unconfirmed transactions\n", __func__, submitted_tx_count);
    }
}

```

1. I'm not sure I correctly understand the usage of the `CWallet` class. By reading the comments and code, I think this class manages the transactions of the Bitcoin Core's node itself and it plays as a role of regular wallet (beside the fact that it is running on a node). It creates transactions and manages UTXOs. Is this correct?
2. I tried to figure out the reason behind rebroadcasting from comments above, but couldn't understand anything useful. What is the need to rebroadcast a transaction? As its name suggest, it is broadcasting a previously broadcasted transaction. So why should we want such a thing? Isn't broadcasting once sufficient?
3. Even if the flag `fBroadcastTransactions` is set to `true`, the function waits until `GetTime()` is greater that the `nNextResend`, and this variable is set to at least 12 hours later from `GetTime()`. So this means that someone who uses the Bitcoin Core's wallet, should wait at least 12 hour for the transaction to be broadcasted? I'm pretty sure that I'm wrong but can't figure out where.

Thanks for any help.

**Tags:** transactions, wallet, bitcoin-core-development


---

## 1 answers

### Answer by username_1 on 2022-08-20. Score: 3 | Accepted answer

> 1. I'm not sure I correctly understand the usage of the `CWallet` class. By reading the comments and code, I think this class manages the transactions of the Bitcoin Core's node itself and it plays as a role of regular wallet (beside the fact that it is running on a node). It creates transactions and manages UTXOs. Is this correct?

Yes, `CWallet` is the core of Bitcoin Core's wallet implementation. It tracks the user's transactions and addresses, and constructs and signs transactions.

> 2. I tried to figure out the reason behind rebroadcasting from comments above, but couldn't understand anything useful. What is the need to rebroadcast a transaction? As its name suggest, it is broadcasting a previously broadcasted transaction. So why should we want such a thing? Isn't broadcasting once sufficient?

Bitcoin's P2P network doesn't guarantee reliable transmission, especially about unconfirmed transactions. Maybe you were only connected to one or a few nodes, and maybe they went offline right after receiving your transaction. Maybe they were light clients, were broken, or were even malicious, and ignored your transaction entirely.

Even if your transaction made it to a large portion of the network's nodes, it may have gotten evicted from the mempools of those nodes if there was a large wave of higher-fee transactions than yours. If so, it's possible the network may just have forgotten about your transactions.

Especially if it is an incoming payment, the responsibility is on you to get the transaction confirmed. To a lesser extent this is true for the sender as well. The way to accomplish this is broadcasting it to the network, and if it appears to not get mined, occasionally attempt to rebroadcast it.

There has been work around moving this responsibility from the wallet to the mempool. The most important reason for this is privacy: rebroadcasting is a very obvious signal *you* care about a transaction, as parties not involved in the transaction don't perform this rebroadcasting. If rebroadcasting would be done more generally for all transactions in your mempool (not just ones affecting your own wallet), it would be less obvious.

> 3. Even if the flag `fBroadcastTransactions` is set to `true`, the function waits until `GetTime()` is greater that the `nNextResend`, and this variable is set to at least 12 hours later from `GetTime()`. So this means that someone who uses the Bitcoin Core's wallet, should wait at least 12 hour for the transaction to be broadcasted? I'm pretty sure that I'm wrong but can't figure out where.

That's exactly right. A rebroadcast event is scheduled somewhat randomly, with 12 to 36 hours between events.

> **Comments:**
> **username_0**: Thanks for the answer, so you mean it is possible that a transaction I sent using the Bitcoin Core wallet will be confirmed 12 hours later due to rebroadcasting latency? (even with enough tx fee). Isn't it a flaw for the wallet?  
> **username_1**: It is possible that a broadcasted transaction isn't confirmed at all, ever. This is true for every wallet, and there is nothing the wallet can do about it but retry to get the transaction known to the network. It only does this every 12 hours because doing it very frequently is a privacy leak.  

---

