Published on: 2020-05-11T22:12:33+00:00
Pieter Wuille, a Bitcoin Core developer, has proposed a change to the existing BIP341 and BIP342. This change aims to improve the ability of signers to determine whether they can safely sign with only O(1) information per input. The current model poses limitations as in some cases signers may need to be provided with the entire creating transaction. Wuille supports AJ's approach, which does not increase per-signature hashing while retaining the ability to cache information across BIP141/BIP341. Coinbaseness and height are also being considered, but Wuille believes their utility is low.The proposed amendment to BIP-341 suggests committing to the scriptPubKeys of all transaction inputs instead of just the output being spent. This change is aimed at improving the reliability of determining ownership of external inputs, particularly in applications like CoinJoin where transactions contain external inputs. Without this mechanism, an adversary could display incorrect information about the amount being spent, resulting in theft of user funds. The proposed solution commits to every spent scriptPubKey and therefore every element of the TxOut instead of just the amount. Committing to the input values in the transaction digest would allow for compact fee proofs, and the same reasoning applies to scriptPubKeys. Coinjoin with offline signers would be substantially harder without this proposal.The proposal being discussed is related to the inclusion of sha_scriptPubKeys in a transaction's signature message. However, this would limit some use cases where SIGHASH_ALL behavior is not required. The proposal suggests that sha_scriptPubKeys should only be included if hash_type does not match SIGHASH_ANYONECANPAY. The context also highlights an attack scenario in CoinJoin transactions where the attacker can construct a transaction with two inputs and outputs of identical value, one belonging to the user and another to the attacker. As an alternative proposal, it is suggested that a separate BIP for new sigash flags be created. Additionally, the email mentions the importance of including the scriptPubKey to verify the ownership proof signature. Finally, the email describes how adding the height of the coin to the signature message would constitute a change of a different caliber and is not currently proposed.In an email exchange, Anthony Towns raises concerns about missing information in Bitcoin transactions, specifically the height of a coin and whether it is a Coinbase output. He suggests that committing to the coinbase flag might have some use, but cautions against adding the height of the coin as it would make it hard to chain unconfirmed spends. In a discussion about verifying output scriptPubKeys in Bitcoin transactions, it is pointed out that not verifying these keys would limit one's ability to track where funds went. The current design of sharing the hashOutputs value with BIP-143 is seen as a valuable property to maintain.Russell O'Connor suggests separating the hashes of the ScriptPubKeys from the input values in sha_scriptPubKeys, while Andrew's suggestion to add another hash to the signature message for sha_scriptPubKeys achieves this. They could also make the scriptPubKey field dependent on hash_type matching ANYONECANPAY, which would mean committing to each component of the UTXOs being spent. Russell O'Connor also proposed separating the hashing of the output values from the output ScriptPubKeys in sha_outputs so that applications interested only in summing the values of the outputs do not have to wade through those arbitrary long ScriptPubKeys in the outputs.Andrew Kozlik discusses the need for a wallet to ascertain non-ownership of an external input by obtaining the scriptPubKey of the previous output spent by the input. He mentions the impracticality of checking whether a scriptPubKey contains any of the possible two billion keys in a specific BIP32 derivation path. Greg Saunders' scheme can be used as an alternative, which requires one-way communication from a signing device to a coordinator.In a Bitcoin development discussion, Andrew Kozlik proposed a modification to the signature message of BIP-0341. He suggested that the signature message should commit to the scriptPubKeys of all transaction inputs, rather than just the scriptPubKey of the output being spent. This proposal is motivated by the need for wallets in situations such as CoinJoin to accurately determine if an input belongs to the wallet or not, in order to calculate the actual amount being spent by the user.The proposed solution involves adding another hash to the signature message: sha_scriptPubKeys (32). This hash would be the SHA256 of the serialization of all scriptPubKeys of the previous outputs spent by the transaction. By including this hash, wallets would be able to reliably determine for each input whether it belongs to the wallet or not, ensuring the accuracy of the amount being spent.Jeremy Rubin responded to Andrew's proposal by suggesting that using SIGHASH_ALL would sign the COutPoints of all inputs, eliminating the need for signing any additional data.
Updated on: 2023-08-02T02:08:51.329382+00:00