I wonder of consequences if var_int is used in its longer than necessary forms 
(e.g encoding 1 as 0xfd0100 instead of 0x01)

This is already of interest if applying size limit to a block, since 
transaction count is var_int but is not part of the hashed header or the merkle 

It could also be used to create variants of the same transaction message by 
altered representation of txIn and txout counts, that would remain valid 
provided signatures validate with the shortest form, as that is created while 
re-serializing for signature hashing. An implementation that holds mempool by 
raw message hashes could be tricked to believe that a modified encoded version 
of the same transaction is a real double spend. One could also mine a valid 
block with transactions that have a different hash if regularly parsed and 
re-serialized. An SPV client could be confused by such a transaction as it was 
present in the merkle tree proof with a different hash than it gets for the tx 
with its own serialization or from the raw message.

Tamas Blummer
Bits of Proof

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
Bitcoin-development mailing list

Reply via email to