<p>There are several reasons why I think having those would be a terrible idea.</p>

<ul>
<li><p>Scalability. If scripts can access arbitrary pieces of the blockchain, fully validating nodes would require (fast!) access to the entire chain. This is currently not the case - fully validating nodes do not need the full chain, but only a small database of unspent transaction outputs (which is less than 3 GiB, and grows much slower).</p></li>
<li><p>Mempool management. If script validity can depend on the state of the blockchain, unconfirmed transactions can be invalidated by new blocks. It is possible to construct these hypothetical blockchain inspection opcodes so that new blocks never invalidate things (e.g. only have opcodes that fetch from a block, and if that block is not found, cause immediate script failure). However, even in that case validity may be affected by reorganizations. That would effectively mean that the entire mempool would need to be revalidated after every reorganization.</p></li>
<li><p>Fungibility. Related to the previous point, it is even the case that deeper-than-1 reorganizations may affect the  validity of already confirmed transactions. This means wallet software would need to be extra careful about accepting payments with transactions whose validity depends on blockchain state, as reorganizations have an increased chance of wiping them out, even when the sender is completely honest. This is not true for transactions right now - transactions removed during a reorg can always be re-accepted in new blocks in the new branch.</p></li>
</ul>

CC BY-SA 3.0
2017-09-26T10:57:08.530Z
Thank you for this detailed answer Pieter. Thank you for everything you do for Bitcoin.
Andrey Dzhukov
CC BY-SA 3.0
2017-09-25T17:55:41.103Z
2017-09-25T17:55:41.103Z
Pieter Wuille
<p>Blockchain data is immutable, so once valid a transaction will always be valid and full nodes can verify it.</p>

CC BY-SA 3.0
2017-09-25T16:37:29.063Z
Can you be more specific? What are you imagining querying and for what purpose?
David Schwartz
<development><script>
Why there are no OP_CODEs for querying the blockchain and retrieving data to the stack?
Andrey Dzhukov
# Why there are no OP_CODEs for querying the blockchain and retrieving data to the stack?

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

Blockchain data is immutable, so once valid a transaction will always be valid and full nodes can verify it.

**Tags:** development, script

> **Comments:**
> **username_1**: Can you be more specific? What are you imagining querying and for what purpose?  

---

## 1 answers

### Answer by username_2 on 2017-09-25. Score: 2 | Accepted answer

There are several reasons why I think having those would be a terrible idea.

* Scalability. If scripts can access arbitrary pieces of the blockchain, fully validating nodes would require (fast!) access to the entire chain. This is currently not the case - fully validating nodes do not need the full chain, but only a small database of unspent transaction outputs (which is less than 3 GiB, and grows much slower).
* Mempool management. If script validity can depend on the state of the blockchain, unconfirmed transactions can be invalidated by new blocks. It is possible to construct these hypothetical blockchain inspection opcodes so that new blocks never invalidate things (e.g. only have opcodes that fetch from a block, and if that block is not found, cause immediate script failure). However, even in that case validity may be affected by reorganizations. That would effectively mean that the entire mempool would need to be revalidated after every reorganization.
* Fungibility. Related to the previous point, it is even the case that deeper-than-1 reorganizations may affect the validity of already confirmed transactions. This means wallet software would need to be extra careful about accepting payments with transactions whose validity depends on blockchain state, as reorganizations have an increased chance of wiping them out, even when the sender is completely honest. This is not true for transactions right now - transactions removed during a reorg can always be re-accepted in new blocks in the new branch.

> **Comments:**
> **username_0**: Thank you for this detailed answer username_2. Thank you for everything you do for Bitcoin.  

---

