Published on: 2018-07-11T20:05:32+00:00
The discussion among Bitcoin developers regarding the policy for signing Bitcoin transactions with extra metadata has raised concerns about the potential difficulty of implementing new features that require extra data. The fear is that if signers are allowed to refuse to sign because of extra fields, it would create pressure to find places to stuff the extra data where it won't interfere with already deployed signers. This would be unfortunate as PSBT was created specifically to avoid field stuffing.In a recent email exchange among developers, it was suggested to add a statement to the Partially Signed Bitcoin Transaction (PSBT) specification to explain that the result of combining two PSBTs from independent participants should be functionally equivalent to processing the original PSBT by A and then B in a sequence. The rationale behind this is that Combiners can always be replaced with just a different topology of data flow. In terms of conflicts between values, the Combiner which picks arbitrarily will not end up with something worse than what is already needed to deal with.The discussion revolves around the possibility of malicious conflicting values in a scenario where one signer produces an invalid signature or modifies any of the other fields already present in the PSBT for consumption by others. It is believed that combiners can always be replaced with just a different topology of data flow since it does not make a difference. The Combiner, which picks arbitrarily in case of conflicts, will never end up with something worse than what one already needs to deal with.In an email thread between Andrew, William Casarin and Jason Les, William expressed concern about the format of parsing key-value maps arrays. He stated that "you can only parse the format properly by first deserializing the transaction. Since there is no 'length' field for the key-value map arrays, you must count the number of transaction input/outputs and use that as the number of kv maps to parse." However, Andrew disagreed and stated that this was not a problem since almost all roles have to deserialize the unsigned tx before they can do anything.The conversation revolves around the safety concerns of allowing combiners to arbitrarily choose a value. It is stated that conflicts in UTXOs, sighash type, redeem/witness scripts, derivation paths, etc. can cause recoverable or unrecoverable errors and sometimes indicate malicious activity. The safest option is to reject conflicts but allow intelligent processing by combiners if they understand the relevant fields.The concern raised in this context is regarding the format of PSBT (partially signed Bitcoin transaction). The writer points out that the format is confusing and can only be parsed by deserializing the transaction. They explain that there is no "length" field for the key-value map arrays, which means that the number of kv maps to parse must be counted based on the number of transaction input/outputs. This process is brittle because if a Combiner writes the wrong number of key-value maps that do not align with the number of inputs and outputs in the transaction, then the PSBT will not be able to be deserialized properly, but it will still be a valid PSBT.There has been a suggestion to standardize file names used when creating .psbt files to ensure reliability and avoid collisions. This would involve using an 8 character trim of the hash of the unsigned transaction, followed by the role that created the file (such as 'Signer'), and then a 4 character trim of the hash of data unique to that role (such as 'partial sig').In a discussion surrounding the Bitcoin wallet standard, Partially Signed Bitcoin Transactions (PSBT), contributors debated whether or not to allow combiners to choose any value in cases of conflicts within the transaction. Concerns were raised that conflicts in certain fields could be at best a recoverable error and at worst malicious activity, making it generally safer to default to rejecting conflicts, and explicitly allowing the Combiner to process them intelligently if it understands the relevant fields.In an email conversation, some concerns have been raised about the strictness and security properties of BIP. The first issue is regarding choosing from duplicate keys when combining. The proposal is to either change the resolution strategy or explain why picking at random is safe. However, outlawing conflicting values would force all signers to implement fixed deterministic nonce generation, which may result in PSBTs that got copied and signed and combined again failing. So, a better approach would be to choose the keys in such a way that picking arbitrarily is safe. Another issue is regarding signing records with unknown keys. It is suggested to codify the behavior in the standard or mark a field as "optional" so that strict signers know they can safely ignore the unknown field. However, there may not be a situation where this is needed, and signers generally inspect transactions they're signing.The email author expresses concerns about the strictness and security properties of Bitcoin Improvement Proposal (BIP).
Updated on: 2023-08-01T23:28:42.591997+00:00