<p><strong>A. Is this transaction and/or the block legitimate?</strong></p>
<p>Yes - assuming you accept the segwit soft fork and resulting option for BIP144 format transaction serialisation.</p>
<p><strong>B. If not, why is it in my blk.dat archive?</strong></p>
<p>Not applicable: see above.</p>
<p><strong>C. What does a transaction version of <code>ffffffff</code> imply?</strong></p>
<p>This is noise resulting from attempting to read a segwit tx with pre-segwit parsing schema.</p>
<p><strong>D. Is the scriptPubKey size VarInt <code>fe80ffffff</code> correct?</strong></p>
<p>No, this is also noise resulting from attempting to read a segwit tx with pre-segwit parsing schema.</p>
<p><strong>E. What is the story behind this block?</strong></p>
<p>Per Pieter Wuille's comment:</p>
<blockquote>
<p>...the block you link is the first segwit block (segregated witness),
a softfork and associated protocol change that introduced a new block
and transaction serialization format. The details are specified in
BIP144: github.com/bitcoin/bips/blob/master/bip-0144.mediawiki. I
strongly suspect that's the cause of what throws off your parser.</p>
</blockquote>
<p><a href="https://bitcoin.stackexchange.com/questions/61482/what-was-the-number-of-the-block-in-which-segwit-got-activated-and-first-transa">Note, the block I linked is the second segwit block</a>, but it must have been the first segwit block saved in my local .dat store so my parser hit it first.</p>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki" rel="nofollow noreferrer">BIP144 link</a></p>
<p>To adjust my parser to accept segwit transactions I had to add a conditional statement after reading the Input Count byte. If a value of zero (<code>0x00</code>) appears at its position, it is the &quot;marker&quot; byte which indicates that we are dealing with a segwit transaction. We then read the &quot;flag&quot; byte (which should be one (<code>0x01</code>)), and then the actual Input Count byte. Finally, we must also read the script witnesses:</p>
<p>Before reading the <code>locktime</code>, for each transaction input, read:</p>
<pre><code> NumberStackItems &lt;VarInt&gt;
 For each stack item:
    SizeOfStackItem &lt;VarInt&gt;
    StackItem &lt;SizeofStackItem bytes&gt;
</code></pre>
<p>See also:</p>
<ul>
<li><a href="https://bitcoin.stackexchange.com/a/110810/34190">Reference to Segwit raw transation format</a></li>
<li><a href="https://bitcoin.stackexchange.com/a/55234/34190">Parsing a SegWit transaction - what is the size of witness data?</a></li>
</ul>

CC BY-SA 4.0
2022-12-09T05:03:49.657Z
2024-03-19T16:56:11.580Z
2024-03-19T16:56:11.580Z
Lee
<p>I'm parsing in blocks from my local blk*.dat files, using this <a href="https://learnmeabitcoin.com/technical/blkdat" rel="nofollow noreferrer">excellent website</a> as a guide.</p>
<p>All goes well until file <code>blk00976.dat</code>, block <code>000000000000000000daf7a26d903543377d5cdddb962077e58fd11212479eea</code></p>
<p>In my copy of the file, when the parser reaches byte <code>27871335</code>, it is about to iterate through a set of 64 transaction outputs.</p>
<p>When it reaches the 48th of these, it gets the value <code>c4f1c2b3b69c42c5</code> and then reads a VarInt of <code>fe80ffffff</code>. This is the <a href="https://learnmeabitcoin.com/technical/transaction-data" rel="nofollow noreferrer">number of bytes to read for the next <code>scriptPubKey</code></a>.</p>
<p>The integer value of the VarInt is <code>2164260863</code> bytes (larger than the <code>blk.dat</code> file of <code>133768162</code> bytes).</p>
<p>Note the transaction begins with <code>ffffffff58</code>. Implying a version of <code>ffffffff</code>.</p>
<p>A hexdump of the block in question can be found here: <a href="https://blockchain.info/rawblock/000000000000000000daf7a26d903543377d5cdddb962077e58fd11212479eea?format=hex" rel="nofollow noreferrer">https://blockchain.info/rawblock/000000000000000000daf7a26d903543377d5cdddb962077e58fd11212479eea?format=hex</a> (Find &quot;fe80ffffff&quot; to see where I am looking)</p>
<p><strong>A. Is this transaction and/or the block legitimate?</strong></p>
<p><strong>B. If not, why is it in my blk.dat archive?</strong></p>
<p><strong>C. What does a transaction version of <code>ffffffff</code> imply?</strong></p>
<p><strong>D. Is the scriptPubKey size VarInt <code>fe80ffffff</code> correct?</strong></p>
<p><strong>E. What is the story behind this block?</strong></p>

CC BY-SA 4.0
2022-12-08T15:13:00.827Z
We can't know what is at byte position 27871335 in *your* blk00976.dat, as the contents of those files depends on the order in which peers gave you historical blocks. Can you perhaps include the full transaction hexdump in your question?
Pieter Wuille
CC BY-SA 4.0
2022-12-08T15:54:45.660Z
@PieterWuille thanks, the hexdump wouldn't fit in the question (too many chars). I've put on github: https://github.com/4c656554/SETransactionHex/blob/main/hex_dump . This is the transaction as constructed until meeting the `fe80ffffff` VarInt.
Lee
CC BY-SA 4.0
2022-12-08T17:03:39.087Z
Can you compute the hash of the block it's in? (Not the claimed hash, but recompute it from the bytes in the blk file).
Pieter Wuille
CC BY-SA 4.0
2022-12-08T19:22:41.257Z
@PieterWuille do you mean the hash of the header? Would I not need to recompute the merkle root including the above problem tx? (which I can't figure out how to do due to big varint)...
Lee
CC BY-SA 4.0
2022-12-08T19:24:01.810Z
Oh, right. My guess is just that you're seeing garbage bytes in the blk.dat file, which you should skip.
Pieter Wuille
CC BY-SA 4.0
2022-12-08T19:53:28.930Z
@PieterWuille perhaps, though seems odd that the block is listed at blockchain.info too in that case?
Lee
CC BY-SA 4.0
2022-12-08T20:07:09.533Z
Oh, the block you link is the first segwit block (segregated witness), a softfork and associated protocol change that introduced a new block and transaction serialization format. The details are specified in BIP144: https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki. I strongly suspect that's the cause of what throws off your parser.
Pieter Wuille
CC BY-SA 4.0
2022-12-09T04:55:44.377Z
@PieterWuille got it; with help from your other answers on here as well, thank you.
Lee
<bitcoin-core><transactions><raw-transaction><transaction-version>
Parsing blk.dat file fails, is this block legitimate?
Lee
# Parsing blk.dat file fails, is this block legitimate?

(Asked by: username_0 on 2022-12-08)

I'm parsing in blocks from my local blk\*.dat files, using this [excellent website](https://learnmeabitcoin.com/technical/blkdat) as a guide.

All goes well until file `blk00976.dat`, block `000000000000000000daf7a26d903543377d5cdddb962077e58fd11212479eea`

In my copy of the file, when the parser reaches byte `27871335`, it is about to iterate through a set of 64 transaction outputs.

When it reaches the 48th of these, it gets the value `c4f1c2b3b69c42c5` and then reads a VarInt of `fe80ffffff`. This is the [number of bytes to read for the next `scriptPubKey`](https://learnmeabitcoin.com/technical/transaction-data).

The integer value of the VarInt is `2164260863` bytes (larger than the `blk.dat` file of `133768162` bytes).

Note the transaction begins with `ffffffff58`. Implying a version of `ffffffff`.

A hexdump of the block in question can be found here: <https://blockchain.info/rawblock/000000000000000000daf7a26d903543377d5cdddb962077e58fd11212479eea?format=hex> (Find "fe80ffffff" to see where I am looking)

**A. Is this transaction and/or the block legitimate?**

**B. If not, why is it in my blk.dat archive?**

**C. What does a transaction version of `ffffffff` imply?**

**D. Is the scriptPubKey size VarInt `fe80ffffff` correct?**

**E. What is the story behind this block?**

**Tags:** bitcoin-core, transactions, raw-transaction, transaction-version

> **Comments:**
> **username_1**: We can't know what is at byte position 27871335 in *your* blk00976.dat, as the contents of those files depends on the order in which peers gave you historical blocks. Can you perhaps include the full transaction hexdump in your question?  
> **username_0**: @username_1 thanks, the hexdump wouldn't fit in the question (too many chars). I've put on github: https://github.com/4c656554/SETransactionHex/blob/main/hex_dump . This is the transaction as constructed until meeting the `fe80ffffff` VarInt.  
> **username_1**: Can you compute the hash of the block it's in? (Not the claimed hash, but recompute it from the bytes in the blk file).  
> **username_0**: @username_1 do you mean the hash of the header? Would I not need to recompute the merkle root including the above problem tx? (which I can't figure out how to do due to big varint)...  
> **username_1**: Oh, right. My guess is just that you're seeing garbage bytes in the blk.dat file, which you should skip.  
> **username_0**: @username_1 perhaps, though seems odd that the block is listed at blockchain.info too in that case?  
> **username_1**: Oh, the block you link is the first segwit block (segregated witness), a softfork and associated protocol change that introduced a new block and transaction serialization format. The details are specified in BIP144: https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki. I strongly suspect that's the cause of what throws off your parser.  
> **username_0**: @username_1 got it; with help from your other answers on here as well, thank you.  

---

## 1 answers

### Answer by username_0 on 2022-12-09. Score: 5 | Accepted answer

**A. Is this transaction and/or the block legitimate?**

Yes - assuming you accept the segwit soft fork and resulting option for BIP144 format transaction serialisation.

**B. If not, why is it in my blk.dat archive?**

Not applicable: see above.

**C. What does a transaction version of `ffffffff` imply?**

This is noise resulting from attempting to read a segwit tx with pre-segwit parsing schema.

**D. Is the scriptPubKey size VarInt `fe80ffffff` correct?**

No, this is also noise resulting from attempting to read a segwit tx with pre-segwit parsing schema.

**E. What is the story behind this block?**

Per username_1 username_1's comment:

> ...the block you link is the first segwit block (segregated witness),
> a softfork and associated protocol change that introduced a new block
> and transaction serialization format. The details are specified in
> BIP144: github.com/bitcoin/bips/blob/master/bip-0144.mediawiki. I
> strongly suspect that's the cause of what throws off your parser.

[Note, the block I linked is the second segwit block](https://bitcoin.stackexchange.com/questions/61482/what-was-the-number-of-the-block-in-which-segwit-got-activated-and-first-transa), but it must have been the first segwit block saved in my local .dat store so my parser hit it first.

[BIP144 link](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki)

To adjust my parser to accept segwit transactions I had to add a conditional statement after reading the Input Count byte. If a value of zero (`0x00`) appears at its position, it is the "marker" byte which indicates that we are dealing with a segwit transaction. We then read the "flag" byte (which should be one (`0x01`)), and then the actual Input Count byte. Finally, we must also read the script witnesses:

Before reading the `locktime`, for each transaction input, read:

```
 NumberStackItems <VarInt>
 For each stack item:
    SizeOfStackItem <VarInt>
    StackItem <SizeofStackItem bytes>

```

See also:

* [Reference to Segwit raw transation format](https://bitcoin.stackexchange.com/a/110810/34190)
* [Parsing a SegWit transaction - what is the size of witness data?](https://bitcoin.stackexchange.com/a/55234/34190)


---

