Why rebroadcasting transactions in the Bitcoin Core?

Question

There is a function here, 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.

Answer 1

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.