v57 firmware update
Firmware update
We've recently been made aware of an interesting bug in the firmware that could cause some transactions to not parse correctly.
Here's an exchange I had with one of our users (who had a parsing problem) detailing the technical aspects of the bug:
In pretty much all Bitcoin transactions I’ve seen, no-one ever uses a feature called “transaction lock time” - but it appears 4 of your 5 inputs DO use this feature!
general format (inside a block) of each input of a transaction - Txin
| Field | Description | Size |
|---|---|---|
| Previous Transaction hash | doubled SHA256-hashed of a (previous) to-be-used transaction | 32 bytes |
| Previous Txout-index | non negative integer indexing an output of the to-be-used transaction | 4 bytes |
| Txin-script length | non negative integer VI = VarInt | 1 - 9 bytes |
| Txin-script / scriptSig | Script | <in-script length>-many bytes |
| sequence_no | normally 0xFFFFFFFF; irrelevant unless transaction's lock_time is > 0 | 4 bytes |
And:
(from Bitcoins the hard way )
| version | 01 00 00 00 | |
| input count | 01 | |
| input | previous output hash (reversed) |
48 4d 40 d4 5b 9e a0 d6 52 fc a8 25 8a b7 ca a4 25 41 eb 52 97 58 57 f9 6f b5 0c d7 32 c8 b4 81 |
| previous output index | 00 00 00 00 | |
| script length | 8a | |
| scriptSig | 47 30 44 02 20 2c b2 65 bf 10 70 7b f4 93 46 c3 51 5d d3 d1 6f c4 54 61 8c 58 ec 0a 0f f4 48 a6 76 c5 4f f7 13 02 20 6c 66 24 d7 62 a1 fc ef 46 18 28 4e ad 8f 08 67 8a c0 5b 13 c8 42 35 f1 65 4e 6a d1 68 23 3e 82 01 41 04 14 e3 01 b2 32 8f 17 44 2c 0b 83 10 d7 87 bf 3d 8a 40 4c fb d0 70 4f 13 5b 6a d4 b2 d3 ee 75 13 10 f9 81 92 6e 53 a6 e8 c3 9b d7 d3 fe fd 57 6c 54 3c ce 49 3c ba c0 63 88 f2 65 1d 1a ac bf cd | |
| sequence | ff ff ff ff | |
| output count | 01 | |
| output | value | 62 64 01 00 00 00 00 00 |
| script length | 19 | |
| scriptPubKey | 76 a9 14 c8 e9 09 96 c7 c6 08 0e e0 62 84 60 0c 68 4e d9 04 d1 4c 5c 88 ac | |
| block lock time | 00 00 00 00 | |
All transactions I’ve used before have the standard sequence value of FFFFFFFF and block lock time of 00000000
However, your input transactions (the 2nd, 3rd, 4th and 5th) have something else [this is the #2 input for example]:
01 00 00 00
01
7e7c39a0397fb0739779b18c597ee18685937c1fb3a77a8d8b7fe07a7ea2a645
06 00 00 00
6a
4730440220770225d9be384816f1226b90fb9bc6be7c0c06e0b842e3cfa7f56d6feed137270220585c92f991f0fc7836642b1263c6ee542febc058f674657a39b6dcab4d3fd2c901210321b2b2f015caf1d0566a903d26626076ca2520ba01a6c7d275fa078ba7c772ce
fe ff ff ff <——————————NORMALLY FF FF FF FF
01
29 66 03 00 00 00 00 00
19
76 a9 14 08853c0973f75b3e8b8cfece99b8488fb3848786 88 ac
72 5c 06 00 <—————————— NORMALLY 00 00 00 00