I’m attempting to know the PSBT interchange format (model 0) described in BIP174 however am confused concerning the specification.
Within the line :
<psbt> := <magic> <global-map> <input-map>* <output-map>*
does the ‘*’ imply the identical as in common expressions, ie. 0 or extra occurrences of the previous merchandise ?
So this may imply there may be precisely one <global-map>
and nil or extra <input-map>
‘s and nil or extra <output-map>
‘s ?
I perceive the separator of 0x00
for every of <global-map>
, <input-map>
, and <output-map>
works as a result of a <keylen>
can by no means be zero.
Nevertheless in PSBT model 0 there aren’t any PSBT_GLOBAL_INPUT_COUNT
or PSBT_GLOBAL_OUTPUT_COUNT
international <keytype>
‘s, so in parsing a model 0 <psbt>
how would we all know once we are passing from the tip of the <input-map>
‘s into the <output-map>
‘s ? Each have the identical format <keypair>* 0x00
and so are indistinguishable by wanting on the binary bytes alone.
I’ve studied the legitimate PSBT check vector ‘PSBT with one P2PKH enter. Outputs are empty’, which breaks down as proven beneath.
We see an <input-map>
adopted by its separator 0x00
, then we see 2 separator’s 0x00 0x00
instantly following that. So what do these two trailing 0x00
‘s imply – do they point out two <output-map>
‘s each with empty <keypair>
‘s, or might or not it’s an <input-map>
with an empty <keypair>
adopted by an <output-map>
with an empty <keypair>
?
Was the omission of PSBT_GLOBAL_INPUT_COUNT
and PSBT_GLOBAL_OUTPUT_COUNT
international <keytype>
‘s in model 0 thought-about a bug?
From BIP174 :
Take a look at vector, legitimate PSBT : 'PSBT with one P2PKH enter. Outputs are empty'
70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab300000000000000 555 bytes
Breakdown :
70736274ff <magic>
<global-map> :
0100 <key> := <keylen> <keytype> <keydata>
<keytype> = PSBT_GLOBAL_UNSIGNED_TX = 0x00
75 <valuelen> = 117
<valuedata> = 'The transaction in community serialization' :
02000000 4 bytes
01 1 byte
268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf6 32 bytes
00000000 4 bytes
00 1 byte
feffffff 4 bytes
02 1 byte
d3dff50500000000 8 bytes
19 1 byte
76a914d0c59903c5bac2868760e90fd521a4665aa7652088ac 25 bytes
00e1f50500000000 8 bytes
17 1 byte
a9143545e6e33b832c47050f24d3eeb93c9c03948bc787 23 bytes
b32e1300 4 bytes
TOTAL BYTES 117 bytes
00 SEPARATOR => finish of <global-map>
<input-map>
0100 <key> := <keylen> <keytype> <keydata>
<keytype> = PSBT_IN_NON_WITNESS_UTXO = 0x00
fda501 <valuelen> = 256 + 165 = 421
<valuedata> = 'The transaction in community serialization format the present enter spends from' :
0100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab300000000 421 bytes
00 SEPARATOR => finish of <input-map>
00 SEPARATOR => ?
00 SEPARATOR => ?
Breakdown of 421 bytes :
01000000 model no
0001 segwit bytes
02 enter counter
Enter #0 :
89a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e5
01000000
17
160014be18d152a9b012039daf3da7de4f53349eecb985
ffffffff
Enter #1 :
86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b4
01000000
17
160014fe3e9ef1a745e974d902c4355943abcb34bd5353
ffffffff
02 output counter
Output #0 :
00c2eb0b00000000
19
76a91485cff1097fd9e008bb34af709c62197b38978a4888ac
Output #1 :
72fef84e2c000000
17
a914339725ba21efd62ac753a9bcd067d6c7a6a39d0587
Witness #0 :
02
47
304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c01
21
03d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f2105
Witness #1 :
02
48
3045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01
21
0223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab3
00000000 Tx locktime