<p>CVarInt encoding is only used in the storage of the UTXO set internally, and never in the P2P protocol. CCompactSize is used in a number of places, including the number of transactions per block, the number of inputs and outputs per transaction, and the length of scripts.</p>

<p>If you're parsing block data, you will never encounter a CVarInt. If you're running into problems, it's almost certainly something else, or there is a bug in your CCompactSize decoder.</p>

CC BY-SA 4.0
2019-04-20T18:38:51.613Z
Oh this is a good news, Unfortunately I don't know exactly what block gives me problems reading the script, because for every blk file I create a json file with the list of blocks, so if I get an error reading I can't generate the json, apparte if not active the logger logs the code, which I will do soon, but for now I know that the last block that reads me converting it to json is the following [This](https://www.blockchain.com/it/btc/block/00000000000000000040d252eedd05d65326c950103d65b4f4ba1a951595b153)
vincenzopalazzo
CC BY-SA 4.0
2019-04-20T18:41:19.280Z
plus i use the library to read bitcoin core files the file is serialize.he exception that raises me is the following ```C ++ exception with description" ReadCompactSize (): size too large: iostream error "thrown in the test body.```
vincenzopalazzo
CC BY-SA 4.0
2019-04-20T19:16:50.360Z
@vincenzopalazzo That probably means you're trying to decode garbage. There is no guarantee that all bytes in the block file belong to a block; there may be gaps etc
Pieter Wuille
CC BY-SA 4.0
2019-04-20T19:21:31.763Z
So it is not guaranteed that all blocks have only the declared data? I mean, does this mean that in the beginning there may be other things that are not useful data for me? but in this way there must be a reference somewhere to see what is in that beginning file no?
Because if bitcoin core uses that data then behind the serialization there is logic
vincenzopalazzo
CC BY-SA 4.0
2019-04-20T19:34:37.260Z
Blocks have well defined data only. But the files can contain garbage in addition to the blocks. There is an index database that stores which position each block is stored at. There is no guarantee that there isn't garbage between blocks (for example, for a crash while writing a block).
Pieter Wuille
CC BY-SA 4.0
2019-04-20T21:21:28.530Z
Is it possible that the block continues in the next file or is there some constraint that I don't know where each file must start with a block?
vincenzopalazzo
CC BY-SA 4.0
2019-04-20T21:36:05.783Z
No, the whole block is always in the same file.
Pieter Wuille
CC BY-SA 4.0
2019-04-20T21:38:31.620Z
Oh thanks, this is really a problem for me now
vincenzopalazzo
CC BY-SA 4.0
2019-04-20T17:36:36.857Z
2019-04-20T17:36:36.857Z
Pieter Wuille
<p>I'm developing a parser bitcoin core and I have a problem whit the type CVarInt, I using the decodifier mode of the CCompact size but at the block 976 I Have a problem whit the type, because the value id is unusually, so I have a question why the bitcoin core decided the change implementation to
CCompact size into CVarInt?</p>

<p>What was introduced in the bitcoin core versions to require a change of implementation?</p>

<p>Sorry for my terrible English but I'm learning.</p>

<bitcoin-core><script><bitcoin-core-development>
Differences to CCompactSize and CVarInt
vincenzopalazzo
# Differences to CCompactSize and CVarInt

(Asked by: username_0 on 2019-04-20)

I'm developing a parser bitcoin core and I have a problem whit the type CVarInt, I using the decodifier mode of the CCompact size but at the block 976 I Have a problem whit the type, because the value id is unusually, so I have a question why the bitcoin core decided the change implementation to
CCompact size into CVarInt?

What was introduced in the bitcoin core versions to require a change of implementation?

Sorry for my terrible English but I'm learning.

**Tags:** bitcoin-core, script, bitcoin-core-development


---

## 1 answers

### Answer by username_1 on 2019-04-20. Score: 3 | Accepted answer

CVarInt encoding is only used in the storage of the UTXO set internally, and never in the P2P protocol. CCompactSize is used in a number of places, including the number of transactions per block, the number of inputs and outputs per transaction, and the length of scripts.

If you're parsing block data, you will never encounter a CVarInt. If you're running into problems, it's almost certainly something else, or there is a bug in your CCompactSize decoder.

> **Comments:**
> **username_0**: Oh this is a good news, Unfortunately I don't know exactly what block gives me problems reading the script, because for every blk file I create a json file with the list of blocks, so if I get an error reading I can't generate the json, apparte if not active the logger logs the code, which I will do soon, but for now I know that the last block that reads me converting it to json is the following [This](https://www.blockchain.com/it/btc/block/00000000000000000040d252eedd05d65326c950103d65b4f4ba1a951595b153)  
> **username_0**: plus i use the library to read bitcoin core files the file is serialize.he exception that raises me is the following ```C ++ exception with description" ReadCompactSize (): size too large: iostream error "thrown in the test body.```  
> **username_1**: @username_0 That probably means you're trying to decode garbage. There is no guarantee that all bytes in the block file belong to a block; there may be gaps etc  
> **username_0**: So it is not guaranteed that all blocks have only the declared data? I mean, does this mean that in the beginning there may be other things that are not useful data for me? but in this way there must be a reference somewhere to see what is in that beginning file no? Because if bitcoin core uses that data then behind the serialization there is logic  
> **username_1**: Blocks have well defined data only. But the files can contain garbage in addition to the blocks. There is an index database that stores which position each block is stored at. There is no guarantee that there isn't garbage between blocks (for example, for a crash while writing a block).  
> **username_0**: Is it possible that the block continues in the next file or is there some constraint that I don't know where each file must start with a block?  
> **username_1**: No, the whole block is always in the same file.  
> **username_0**: Oh thanks, this is really a problem for me now  

---

