Question on PSBT interchange format (version 0)

I am trying to understand the PSBT interchange format (version 0) described in BIP174 but am confused about the specification.

In the line :

<psbt> := <magic> <global-map> <input-map>* <output-map>*

does the '*' mean the same as in regular expressions, ie. 0 or more occurrences of the preceding item ?

So this would mean there is exactly one <global-map> and zero or more <input-map>'s and zero or more <output-map>'s ?

I understand the separator of 0x00 for each of <global-map>, <input-map>, and <output-map> works because a <keylen> can never be zero.

However in PSBT version 0 there are no PSBT_GLOBAL_INPUT_COUNT or PSBT_GLOBAL_OUTPUT_COUNT global <keytype>'s, so in parsing a version 0 <psbt> how would we know when we are passing from the end of the <input-map>'s into the <output-map>'s ? Both have the same format <keypair>* 0x00 and so are indistinguishable by looking at the binary bytes alone.

I have studied the valid PSBT test vector 'PSBT with one P2PKH input. Outputs are empty', which breaks down as shown below.

We see an <input-map> followed by its separator 0x00, then we see 2 separator's 0x00 0x00 immediately following that. So what do these two trailing 0x00's mean - do they indicate two <output-map>'s both with empty <keypair>'s, or could it be an <input-map> with an empty <keypair> followed by an <output-map> with an empty <keypair> ?

Was the omission of PSBT_GLOBAL_INPUT_COUNT and PSBT_GLOBAL_OUTPUT_COUNT global <keytype>'s in version 0 considered a bug?

From BIP174 :

Test vector, valid PSBT : 'PSBT with one P2PKH input. 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 network 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 => end 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 network serialization format the current input spends from' :

0100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab300000000            421 bytes

00                                                                          SEPARATOR => end of <input-map>

00                                                                          SEPARATOR => ?

00                                                                          SEPARATOR => ?


Breakdown of 421 bytes :

01000000            version no
0001                segwit bytes

02                  input counter

Input #0 :
89a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e5
01000000
17
160014be18d152a9b012039daf3da7de4f53349eecb985
ffffffff

Input #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


from Recent Questions - Bitcoin Stack Exchange https://ift.tt/vRm6Nt5
via IFTTT

Popular posts from this blog

Future of Bitcoin encryption and security in a QC era

How will the advancement of quantum computing impact the security of Bitcoin, and what steps are necessary to protect the network from this emerging threat? What role could lattice-based encryption play in safeguarding Bitcoin, and which of the current algorithms are best suited for this purpose? How would the implementation of such encryption technology be integrated into the existing Bitcoin infrastructure, and what challenges might arise during this process? What happens to existing addresses that rely on elliptic curve cryptography? Is there a way to seamlessly transition old addresses to the new system, or would users need to actively transfer their funds to new, more secure addresses? How could such a transition be designed to ensure user security while maintaining trust in the network? from Recent Questions - Bitcoin Stack Exchange https://ift.tt/aZeY2fo via IFTTT
Read more

Possible rollback due to lazy reveal in BRC20?

Let's assume user A committed an inscription with {"op":"deploy", "tick": "test"} at block 100 (without revealing it yet). Then user B commits and reveals the exact same inscription at block 101. Because the indexer isn't aware that A's earlier commit was actually for "test," it recognizes B's "test" token as the official one. From blocks 101 to 199, users freely perform various "test" token transactions (e.g., "mint" , "transfer" ). However, at block 200, user A finally reveals their earlier commit. In that case, will the indexer roll back all "test"-related histories that happened between blocks 101 and 199? If so, can we really trust that all BRC20 tokens recognized by the indexer are "safely" the official ones? from Recent Questions - Bitcoin Stack Exchange https://ift.tt/CsYKVTa via IFTTT
Read more

A way to recover scammed Bitcoin investment

I have learned the hard way that even the most seasoned investors can fall prey to malicious actors. When my Investment was stolen, I felt a sense of betrayal and anger. But then, I discovered this FINANCE TEAM, and their professionalism and unwavering commitment gave me a renewed sense of confidence. From the moment I reached out to this Finance Team, I was impressed by their attention to detail and their deep understanding of the Stock and real estate ecosystem. They listened patiently to my story and carefully analyzed the transaction history, leaving no stone unturned in their investigation. Throughout the recovery process, This Finance Teamkept me informed of their progress, providing me with regular updates and answering my countless questions with patience and understanding. Their unwavering dedication and determination gave me a sense of hope during a time of great uncertainty. To my astonishment, This Finance Team was able to recover a significant portion of my stolen Investme...
Read more