<blockquote>
<p>I was wondering why the txn_count field in a block exists. The count of transactions could be determined by parsing the txns field in tx format, right?</p>
</blockquote>
<p>Yes, it could, but it isn't. Ultimately serialization formats are a convention, and Satoshi picked one when he created the initial software which has persisted in the protocol. It could be changed, but why bother?</p>
<blockquote>
<p>The tx_in and tx_out can be just parsed and the count can be determined based on that, right?</p>
</blockquote>
<p>That's not quite true - you need some way of conveying at least where the inputs end and the outputs begin (which in the existing protocol is served by the txin count). When deserializing a list of transactions (like in a <code>block</code> message), you also need to know where each transaction ends and the next one begins (which in the existing protocol is served by the txout count).</p>
<blockquote>
<p>Is it also used so you can reserve a certain amount of memory before parsing the transactions you think?</p>
</blockquote>
<p>You could, but that actually isn't done (at least in Bitcoin Core). The problem is what if you receive a block that claims to contain a billion transactions? Instead, it will allocate buffer space in increments of at most a few MB, so an attacker would need to actually send megabytes of data to get you to allocate that much.</p>

CC BY-SA 4.0
2020-11-20T18:20:10.130Z
Thanks for the clear explanation!
Stijn de Vries
CC BY-SA 4.0
2020-11-20T18:01:33.810Z
2020-11-20T18:10:27.810Z
2020-11-20T18:10:27.810Z
Pieter Wuille
<p>Serialization is certainly not my area of expertise, but I'd guess: one challenge with serialized data is to know how much data to read. Explicitly providing the count of objects (and their length) you're about to parse is likely simpler and safer than having multiple levels of terminators in a hierarchical data structure and may actually require less data overall.</p>

CC BY-SA 4.0
2020-11-20T16:20:09.403Z
Thanks! Is it also used so you can reserve a certain amount of memory before parsing the transactions you think?
Stijn de Vries
CC BY-SA 4.0
2020-11-20T15:36:55.687Z
2020-11-20T15:36:55.687Z
Murch
<p>I was wondering why the txn_count field in a block exists. The count of transactions could be determined by parsing the txns field in tx format, right? Same for 'tx_in count' and 'tx_out count' in a transaction. The tx_in and tx_out can be just parsed and the count can be determined based on that, right? Is this true? And if it's true, why do the txn_count, tx_in count and tx_out count fields exist?</p>

<transactions><block><protocol>
Why does the txn_count field exists in a block?
Stijn de Vries
# Why does the txn_count field exists in a block?

(Asked by: username_0 on 2020-11-20)

I was wondering why the txn\_count field in a block exists. The count of transactions could be determined by parsing the txns field in tx format, right? Same for 'tx\_in count' and 'tx\_out count' in a transaction. The tx\_in and tx\_out can be just parsed and the count can be determined based on that, right? Is this true? And if it's true, why do the txn\_count, tx\_in count and tx\_out count fields exist?

**Tags:** transactions, block, protocol


---

## 2 answers

### Answer by username_1 on 2020-11-20. Score: 3 | Accepted answer

> I was wondering why the txn\_count field in a block exists. The count of transactions could be determined by parsing the txns field in tx format, right?

Yes, it could, but it isn't. Ultimately serialization formats are a convention, and Satoshi picked one when he created the initial software which has persisted in the protocol. It could be changed, but why bother?

> The tx\_in and tx\_out can be just parsed and the count can be determined based on that, right?

That's not quite true - you need some way of conveying at least where the inputs end and the outputs begin (which in the existing protocol is served by the txin count). When deserializing a list of transactions (like in a `block` message), you also need to know where each transaction ends and the next one begins (which in the existing protocol is served by the txout count).

> Is it also used so you can reserve a certain amount of memory before parsing the transactions you think?

You could, but that actually isn't done (at least in Bitcoin Core). The problem is what if you receive a block that claims to contain a billion transactions? Instead, it will allocate buffer space in increments of at most a few MB, so an attacker would need to actually send megabytes of data to get you to allocate that much.

> **Comments:**
> **username_0**: Thanks for the clear explanation!  

---

### Answer by username_2 on 2020-11-20. Score: 3

Serialization is certainly not my area of expertise, but I'd guess: one challenge with serialized data is to know how much data to read. Explicitly providing the count of objects (and their length) you're about to parse is likely simpler and safer than having multiple levels of terminators in a hierarchical data structure and may actually require less data overall.

> **Comments:**
> **username_0**: Thanks! Is it also used so you can reserve a certain amount of memory before parsing the transactions you think?  

---

