<p>Transactions are never cancelled, and there is no refund. However, the sender also does not need to wait for anything to happen before attempting to use their money in another manner, at least in theory.</p>
<p>When a user broadcasts a transaction, it expresses an attempt to move the coins involved. Once that transaction confirms, everyone will agree that that happened. But before confirmation, it is a matter of perspective. Typically, the sender's wallet will treat the coins as gone as soon as the transaction is created, but as far as the blockchain is concerned, they still reside in the sender's wallet.</p>
<p>The protocol does not prevent the sender from creating another transaction that spends the same coins, which therefore necessarily conflicts with the first one (through a principle known as Replace-By-Fee (<a href="https://bitcoinops.org/en/topics/replace-by-fee/" rel="nofollow noreferrer">RBF</a>)). Some wallets allow RBF just for the purpose of increasing the fee of a transaction that is happening too slow, but some also allow a user to &quot;abandon&quot; a non-confirming transactions in some circumstances, permitting the funds to be spent in another way.</p>
<p>In short, there is nothing to refund, because as far as the network is concerned, a non-confirmed transaction simply hasn't <em>happened</em>. It is a matter for the sender's wallet how to deal with that.</p>

CC BY-SA 4.0
2024-12-19T13:53:38.537Z
Thank you! That really helped clarify things for me. I have a follow-up question, though: How does Bitcoin prevent miners' mempools from being overwhelmed with invalid transactions? Is it possible for an attacker to flood the mempool with a ton of invalid transactions, knowing that they would eventually be rejected by the network, like in a double spending scenario?
Learner
CC BY-SA 4.0
2024-12-19T14:50:05.550Z
@Learner it is best to ask follow up questions as new questions using the "ask question" button. But no bitcoin software would ever put an invalid transaction into its mempool. All Bitcoin nodes  check data and discard invalid data. I don't know if there are any measures that prevent a node's mempool  being flooded with unconfirmed but valid transactions spending a common input.
RedGrittyBrick
CC BY-SA 4.0
2024-12-19T12:47:48.613Z
2024-12-19T13:17:17.780Z
2024-12-19T13:17:17.780Z
Pieter Wuille
<p>Going through the following resource:</p>
<blockquote>
<p>When a miner creates a block proposal, the miner is entitled to
specify where all the fees paid by the transactions in that block
proposal should be sent. If the proposal results in a valid block that
becomes a part of the best block chain, the fee income will be sent to
the specified recipient. If a valid block does not collect all
available fees, the amount not collected is permanently destroyed;
this has happened on more than 1,000 occasions from 2011 to
2017,[1][2] with decreasing frequency over time.</p>
</blockquote>
<p>I understand that transaction fees are eventually refunded to the sender. However, what about the miner's fee? If miner's fees are also refunded, how does Bitcoin protect the miner's mempool from being flooded or spammed with invalid transactions? Shouldn't there be some form of deterrent in place to safeguard these mempools?</p>

<transaction-fees><mempool>
What happens to miner's fees when a Bitcoin transaction is rejected?
Learner
# What happens to miner's fees when a Bitcoin transaction is rejected?

(Asked by: username_0 on 2024-12-19)

Going through the following resource:

> When a miner creates a block proposal, the miner is entitled to
> specify where all the fees paid by the transactions in that block
> proposal should be sent. If the proposal results in a valid block that
> becomes a part of the best block chain, the fee income will be sent to
> the specified recipient. If a valid block does not collect all
> available fees, the amount not collected is permanently destroyed;
> this has happened on more than 1,000 occasions from 2011 to
> 2017,[1][2] with decreasing frequency over time.

I understand that transaction fees are eventually refunded to the sender. However, what about the miner's fee? If miner's fees are also refunded, how does Bitcoin protect the miner's mempool from being flooded or spammed with invalid transactions? Shouldn't there be some form of deterrent in place to safeguard these mempools?

**Tags:** transaction-fees, mempool


---

## 1 answers

### Answer by username_1 on 2024-12-19. Score: 4 | Accepted answer

Transactions are never cancelled, and there is no refund. However, the sender also does not need to wait for anything to happen before attempting to use their money in another manner, at least in theory.

When a user broadcasts a transaction, it expresses an attempt to move the coins involved. Once that transaction confirms, everyone will agree that that happened. But before confirmation, it is a matter of perspective. Typically, the sender's wallet will treat the coins as gone as soon as the transaction is created, but as far as the blockchain is concerned, they still reside in the sender's wallet.

The protocol does not prevent the sender from creating another transaction that spends the same coins, which therefore necessarily conflicts with the first one (through a principle known as Replace-By-Fee ([RBF](https://bitcoinops.org/en/topics/replace-by-fee/))). Some wallets allow RBF just for the purpose of increasing the fee of a transaction that is happening too slow, but some also allow a user to "abandon" a non-confirming transactions in some circumstances, permitting the funds to be spent in another way.

In short, there is nothing to refund, because as far as the network is concerned, a non-confirmed transaction simply hasn't *happened*. It is a matter for the sender's wallet how to deal with that.

> **Comments:**
> **username_0**: Thank you! That really helped clarify things for me. I have a follow-up question, though: How does Bitcoin prevent miners' mempools from being overwhelmed with invalid transactions? Is it possible for an attacker to flood the mempool with a ton of invalid transactions, knowing that they would eventually be rejected by the network, like in a double spending scenario?  
> **username_2**: @username_0 it is best to ask follow up questions as new questions using the "ask question" button. But no bitcoin software would ever put an invalid transaction into its mempool. All Bitcoin nodes  check data and discard invalid data. I don't know if there are any measures that prevent a node's mempool  being flooded with unconfirmed but valid transactions spending a common input.  

---

