<p>You're missing a crucial piece of information. Bitcoin is not an account based system, but rather one that builds on tokens. Every transaction has a list of tokens that it spends and a list of tokens that it creates. The tokens can be uniquely identified. We call these tokens "Unspent Transaction Outputs" when they are created and sometimes "inputs" when they are being used up.</p>

<p>Every node will check whether a transaction is correctly authorized to spend an input, thus an invalid transaction as you describe would never enter any mempools in the first place as it is spending more funds than the inputs provide. It can also not automatically reference more inputs later, everything must be already set in stone to sign a transaction.</p>

<p>Also see: </p>

<ul>
<li><a href="https://bitcoin.stackexchange.com/q/4301/5406">What is an "unspent output?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/46152/5406">How do transactions leave the memory pool?</a></li>
</ul>

CC BY-SA 3.0
2017-05-25T20:21:40.663Z
2017-05-25T20:21:40.663Z
Murch
<blockquote>
  <p>A Wallet tries to spend more BTC than it current has</p>
</blockquote>

<p>Technically, that would only be possible, if you try to spend an input (coin) that you can't sign (a.k.a. that you don't <strong>own</strong>).</p>

<ul>
<li>Your local mempool (if you run Bitcoin Core or a similar fullnode) would reject the transaction immediately.</li>
<li>The transaction would not be broadcasted over the p2p network, because all nodes do reject transactions that are trying to spend inputs with invalid signatures (or inputs that doesn't exists)</li>
</ul>

<blockquote>
  <p>At some much later point, the Wallet gets more value.</p>
</blockquote>

<p>The transaction is already made. It won't auto-update. It was already rejected.</p>

<p>Now one expect your local wallet knows the ("old", invalid transaction).</p>

<p>The only thing you can do now is to recreate the transaction (now with the correct inputs) and have it send over the network (and have it mined).</p>

<blockquote>
  <p>The previously rejected transaction can suddenly be confirmed.</p>
</blockquote>

<p>Invalid transactions cannot be mined and will not be broadcasted (broadcasting would be possible but extremely unlikely).</p>

CC BY-SA 3.0
2017-05-25T19:00:30.737Z
2017-05-25T19:00:30.737Z
Jonas Schnelli
<p>My basic understanding is that a transaction will continue to exist in the MemPool until it can be completed, (or eventually gets evicted due to the size of the MemPool).</p>

<p>To me, this leads to a strange situation:</p>

<ul>
<li>A Wallet tries to spend more BTC than it current has</li>
<li>Miners reject that transaction (or more properly, fail to confirm it). But the transaction remains in the mempool.</li>
<li>At some much later point, the Wallet gets more value.</li>
<li>The previously rejected transaction can suddenly be confirmed.</li>
</ul>

<p>This is roughly equivalent to bouncing a check with your bank, and then having the check clear days, weeks, or months later when you eventually get the money!</p>

<p>Is this actually how BTC works?  Or is there point where a transaction can be officially and completely rejected, just as at it can be confirmed?</p>

<unconfirmed-transactions><transaction-verification><mempool>
Does an Invalid Transaction persist in the mempool?
abelenky
# Does an Invalid Transaction persist in the mempool?

(Asked by: username_0 on 2017-05-25)

My basic understanding is that a transaction will continue to exist in the MemPool until it can be completed, (or eventually gets evicted due to the size of the MemPool).

To me, this leads to a strange situation:

* A Wallet tries to spend more BTC than it current has
* Miners reject that transaction (or more properly, fail to confirm it). But the transaction remains in the mempool.
* At some much later point, the Wallet gets more value.
* The previously rejected transaction can suddenly be confirmed.

This is roughly equivalent to bouncing a check with your bank, and then having the check clear days, weeks, or months later when you eventually get the money!

Is this actually how BTC works? Or is there point where a transaction can be officially and completely rejected, just as at it can be confirmed?

**Tags:** unconfirmed-transactions, transaction-verification, mempool


---

## 2 answers

### Answer by username_1 on 2017-05-25. Score: 3 | Accepted answer

You're missing a crucial piece of information. Bitcoin is not an account based system, but rather one that builds on tokens. Every transaction has a list of tokens that it spends and a list of tokens that it creates. The tokens can be uniquely identified. We call these tokens "Unspent Transaction Outputs" when they are created and sometimes "inputs" when they are being used up.

Every node will check whether a transaction is correctly authorized to spend an input, thus an invalid transaction as you describe would never enter any mempools in the first place as it is spending more funds than the inputs provide. It can also not automatically reference more inputs later, everything must be already set in stone to sign a transaction.

Also see:

* [What is an "unspent output?](https://bitcoin.stackexchange.com/q/4301/5406)
* [How do transactions leave the memory pool?](https://bitcoin.stackexchange.com/q/46152/5406)


---

### Answer by username_2 on 2017-05-25. Score: 1

> A Wallet tries to spend more BTC than it current has

Technically, that would only be possible, if you try to spend an input (coin) that you can't sign (a.k.a. that you don't **own**).

* Your local mempool (if you run Bitcoin Core or a similar fullnode) would reject the transaction immediately.
* The transaction would not be broadcasted over the p2p network, because all nodes do reject transactions that are trying to spend inputs with invalid signatures (or inputs that doesn't exists)

> At some much later point, the Wallet gets more value.

The transaction is already made. It won't auto-update. It was already rejected.

Now one expect your local wallet knows the ("old", invalid transaction).

The only thing you can do now is to recreate the transaction (now with the correct inputs) and have it send over the network (and have it mined).

> The previously rejected transaction can suddenly be confirmed.

Invalid transactions cannot be mined and will not be broadcasted (broadcasting would be possible but extremely unlikely).


---

