A. Is that this transaction and/or the block official?
Sure – assuming you settle for the segwit gentle fork and ensuing possibility for BIP144 format transaction serialisation.
B. If not, why is it in my blk.dat archive?
Not relevant: see above.
C. What does a transaction model of ffffffff indicate?
That is noise ensuing from making an attempt to learn a segwit tx with pre-segwit parsing schema.
D. Is the scriptPubKey measurement VarInt fe80ffffff right?
No, that is additionally noise ensuing from making an attempt to learn a segwit tx with pre-segwit parsing schema.
E. What’s the story behind this block?
Per Pieter Wuille’s remark:
…the block you hyperlink is the primary segwit block (segregated witness),
a softfork and related protocol change that launched a brand new block
and transaction serialization format. The main points are laid out in
BIP144: github.com/bitcoin/bips/blob/grasp/bip-0144.mediawiki. I
strongly suspect that is the reason for what throws off your parser.
Notice, the block I linked is the second segwit block, however it should have been the primary segwit block saved in my native .dat retailer so my parser hit it first.
To regulate my parser to just accept segwit transactions I had so as to add a conditional assertion after studying the Enter Rely byte. If a worth of zero (0x00) seems at its place, it’s the “marker” byte which signifies that we’re coping with a segwit transaction. We then learn the “flag” byte (which needs to be one (0x01)), after which the precise Enter Rely byte. Lastly, we should additionally learn the script witnesses:
Earlier than studying the locktime, for every transaction enter, learn:
NumberStackItems <VarInt>
For every stack merchandise:
SizeOfStackItem <VarInt>
StackItem <SizeofStackItem bytes>
See additionally:
