<p>The most expensive part of checking a transaction, ECDSA validation, is cached. </p>

CC BY-SA 3.0
2018-03-23T12:38:28.957Z
Didn't cache also the transaction itself?
Osias Jota
CC BY-SA 3.0
2018-03-23T12:54:13.447Z
Transaction validity can change (OP_CLTV).
Claris
CC BY-SA 3.0
2018-03-23T15:16:15.657Z
Now I'm thinking about it, it can change even before that because there could've been a double spend attempt.
Osias Jota
CC BY-SA 3.0
2018-03-23T12:18:15.237Z
2018-03-23T12:18:15.237Z
Claris
<p>Zero confirmed transaction are unsafe. Simillarly, it is not safe to validate using them as benchmark. See this example:</p>

<ul>
<li>You have a transaction <em>T1</em> that spends txouts of transaction <em>T</em> in mempool</li>
<li>Another transaction <em>T2</em> in mempool spends outputs of <em>T1</em></li>
<li>In Block B 

<ul>
<li>We have tranaction <em>T1'</em> that is double spend of <em>T1</em> with different output. This is possible since miner can directly include <em>T1'</em> in the block and it is valid.</li>
<li>We also have <em>T2</em> in B but it is invalid. Now validating <em>T2</em> based on mempool would be wrong. We have to consider all previous outputs and outputs in the current block.</li>
</ul></li>
</ul>

<p>Also note that bitcoind has to validate blocks which on different forks/chains. Mempool only has unconfirmed transaction on the longest chain</p>

CC BY-SA 3.0
2018-03-23T13:25:16.770Z
Nonsense, you can cache the validation, just not the UTXO check.
Claris
CC BY-SA 3.0
2018-03-23T13:08:23.190Z
2018-03-23T13:08:23.190Z
dark knight
<p>Except for checking for double spends, if there's a transaction in a block that's already in the node's mempool, it can theoretically skip its validation. Does it actually happen, or the nodes validate each transaction twice?</p>

<block><nodes><mempool><validation>
Does a node validates a transaction that comes with a block if it's already in its mempool?
someone235
# Does a node validates a transaction that comes with a block if it's already in its mempool?

(Asked by: username_0 on 2018-03-23)

Except for checking for double spends, if there's a transaction in a block that's already in the node's mempool, it can theoretically skip its validation. Does it actually happen, or the nodes validate each transaction twice?

**Tags:** block, nodes, mempool, validation


---

## 2 answers

### Answer by username_1 on 2018-03-23. Score: 2 | Accepted answer

The most expensive part of checking a transaction, ECDSA validation, is cached.

> **Comments:**
> **username_2**: Didn't cache also the transaction itself?  
> **username_1**: Transaction validity can change (OP_CLTV).  
> **username_2**: Now I'm thinking about it, it can change even before that because there could've been a double spend attempt.  

---

### Answer by username_3 on 2018-03-23. Score: 0

Zero confirmed transaction are unsafe. Simillarly, it is not safe to validate using them as benchmark. See this example:

* You have a transaction *T1* that spends txouts of transaction *T* in mempool
* Another transaction *T2* in mempool spends outputs of *T1*
* In Block B
  + We have tranaction *T1'* that is double spend of *T1* with different output. This is possible since miner can directly include *T1'* in the block and it is valid.
  + We also have *T2* in B but it is invalid. Now validating *T2* based on mempool would be wrong. We have to consider all previous outputs and outputs in the current block.

Also note that bitcoind has to validate blocks which on different forks/chains. Mempool only has unconfirmed transaction on the longest chain

> **Comments:**
> **username_1**: Nonsense, you can cache the validation, just not the UTXO check.  

---

