Transaction construction after introduction of Segwit
In a solution to In what format does a block retailer the transaction information? I gave an instance of hand decoding the construction of the earliest Bitcoin transactions from a hex dump.
A Segwit transaction provides some fields which might be an elective a part of the transaction construction. In non-Segwit transactions, these Segwit fields are absent (have zero size).
The primary such elective area is the witness flag simply after the model quantity
The second elective area is the witness information simply earlier than the ultimate lock-time area.
Area Dimension Description Knowledge sort Feedback 4 model uint32_t 0 or 2 flag elective uint8_t[2] If current, all the time 0001, and signifies the presence of witness information 1+ tx_in depend var_int … 0+ tx_witnesses tx_witness[] A listing of witnesses, one for every enter; omitted if flag is omitted above 4 lock_time uint32_t …
So any parser has to have a look at 2 bytes following the model quantity and determine if it’s a segwit flag (0x0001 big-endian!) or a tx_in_count varint and perhaps a part of a tx_in construction.
Instance of decoding from hex a Segwit transaction
Only for enjoyable, a randomly chosen instance, transaction b0dce2eccbd85f9391e108c8f8f3735cc7b9e6a30f13f82a7fdfaa090d4d093c
0200000000010179 aaafbe7c9d3b0812 a489facaf77508c0 8c190ec7dfd82f12 9aeb995aca23ab00 00000000fdffffff 020bd21900000000 00160014d2caa7b0 8db89cd62c9af34d a53332d30e53bb15 98151b0000000000 1600143d4427468c be7ae396427a1aa9 128fa05b18c7db02 4730440220573fd2 7574cfdde4843476 21e1f48f85ae975c b8c2265a04496ded 038896822302204a 5e04a3a2d160c315 8caa39b58bfc91ac 64c484078ec0225a 7d4d2d4454661f01 2103d96e3819b522 45e42c76f869c9a8 75f6ea5344cf1aee 2e6b3ab03adcfef0 d80ede3b0b00
| Hex Knowledge | Kind | Which means |
|---|---|---|
02000000 |
uint32 | model 2 |
0001 |
2 octets | witness flag |
01 |
varint | depend of transaction inputs |
| Enter 1 | ||
79aaafbe7c9d3b08 12a489facaf77508 c08c190ec7dfd82f 129aeb995aca23ab |
32 octets | Hash of referenced Tx |
00000000 |
uint32 | index of earlier output |
00 |
varint | size of signature script (0 as a result of segwit?) |
fdffffff |
4 octets | Sequence (n.b. RBF) |
02 |
varint | Rely of transaction outputs |
| Output 1 | ||
0bd2190000000000 |
int64 | Quantity in Satoshi (0.01692171 BTC) |
16 |
varint | size of script (0x16 = 22) |
0014d2caa7b08db8 9cd62c9af34da533 32d30e53bb15 |
22 octets | locking script |
| Output 2 | ||
98151b0000000000 |
int64 | Quantity in Satoshi |
16 |
varint | size of script (0x16 = 22) |
00143d4427468cbe 7ae396427a1aa912 8fa05b18c7db |
22 octets | locking script |
| Witness information | ||
02 |
varint | Rely of witness parts |
| Witness element 1 | ||
47 |
varint | Size of witness element (0x47 = 71) |
30440220573fd275 74cfdde484347621 e1f48f85ae975cb8 c2265a04496ded03 8896822302204a5e 04a3a2d160c3158c aa39b58bfc91ac64 c484078ec0225a7d 4d2d4454661f01 |
71 octets | witness |
| Witness element 2 | ||
21 |
varint | Size of witness element (0x21 = 33) |
03d96e3819b52245 e42c76f869c9a875 f6ea5344cf1aee2e 6b3ab03adcfef0d8 0e |
33 octets | witness |
de3b0b00 |
unit32 | Lock time: 000b3bde = block 736222 |
This transaction seems because the ninth in block 736223
Notes
Transaction-IDs
A Transaction ID is a hash of many of the transaction information. It’s normally utilized by nodes as a retrieval index right into a saved record of earlier transactions.
That is what’s proven above as “Hash of referenced Tx”.
Addresses
Be aware {that a} transaction doesn’t comprise Bitcoin addresses. Particularly it doesn’t comprise sending addresses and quantities. What it cointains is a pointer to an unspent ouput of an earlier transaction, a pointer to a UTXO. The pointer takes the type of the Transaction-ID of the sooner transaction and an index variety of the outputs of that transaction. For instance it would say this transaction spends the primary (index 0) output created within the earlier transaction with hash (TXID) 79...ab.
Blockchain explorers will sometimes observe that pointer, get quantities and different particulars from the sooner transaction outputs, calculate the sending addresses and current that data as if it had been a part of this transaction regardless that it is not.
Bitcoin addresses might be thought to be a sort of summary of a script. An handle is a manner for a payee to supply a payer with the data wanted by the payer to create a locking-script in a transaction that pays the payee.
Endianness
We see that model 2 is proven in hex as 02000000. It is because the Bitcoin community protocols largely use little-endian byte ordering fairly than the big-endian byte-ordering that the majority of us discover extra pure.
02000000 little endian is 00000002 huge endian. You simply reverse the order of the bytes remembering that one byte is 2 hex digits. So that you reverse the pairs of digits (not particular person digits).
Witness parts
SegWit is brief for Segregated Witness. It was a change that separated (segregated) sure information right into a separate a part of the transaction.
The witness parts are issues like digital-signatures that might have been a part of the unlocking scripts in pre-segwit transactions.
The precise which means is dependent upon the transaction output sort, which is decided by inspecting the locking script on the sooner transaction whose output is being spent as an enter on this transaction.
Scripts
The locking script and the unlocking script are tiny applications written within the Bitcoin scripting language – which is specifically designed to be easy sufficient that it will possibly’t be used to make assaults on the Bitcoin community.
Typically different names are used similar to ScriptSig (signature script) or ScriptPubKey (public key script) – however these names are historic and are considerably inappropriate names for the usual scripts in newer forms of transaction outputs.