BIP174 amendment proposal (Important Signer Check should be mentioned) [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2019-07-09T22:21:25+00:00


Summary:

On the Bitcoin-dev mailing list, Jonathan Underwood proposed a change to the bullet list for signers to ensure that the sighash type provided is acceptable to them. He gave an attack scenario where a signer's UTXO was stolen by a hacker who changed the PSBT input's sighashtype to SIGHASH_ANYONECANPAY | SIGHASH_NONE and after the fact, changed the outputs to send to themselves and added an input they signed with SIGHASH_ALL.Andrew Chow responded, explaining that this attack scenario aligns with the original intent of the sighash field. The signer must determine if the provided sighash type is acceptable, and if not, they should not sign at all. Jonathan agreed with Andrew's explanation and stated that he would write the amendment and make a pull request (PR).On July 9th, 2019, Jonathan Underwood proposed a wording change to the Bitcoin Improvement Proposal (BIP) for the sighash field. This field contains information about how a transaction should be signed. Underwood presented an attack scenario where a hacker modifies the sighashtype of a partially signed Bitcoin transaction (PSBT) to SIGHASH_ANYONECANPAY | SIGHASH_NONE and then adds inputs and outputs to send BTC to themselves.Underwood suggests adding a check for signers to ensure that the sighash type provided is acceptable to them. If it is not acceptable, signing should fail. In cases where no sighash type is provided, signers should default to using SIGHASH_ALL but are allowed to sign with any sighash type they prefer.In his message, Jonathan Underwood describes an attack scenario in which a hacker steals BTC from a signer. The attack involves changing the sighashtype of the input to SIGHASH_ANYONECANPAY | SIGHASH_NONE, modifying the outputs to send BTC to the hacker's address, and adding an input that the hacker signed with SIGHASH_ALL. This results in the loss of BTC for the signer.To address this vulnerability, Underwood proposes additional checks for signers. They should verify if the provided sighash type is acceptable and refuse to sign if it is not. If no sighash type is provided, signers should use SIGHASH_ALL as the default but have the flexibility to sign with any sighash type they choose.


Updated on: 2023-08-02T01:05:47.574840+00:00