<oembed><type>rich</type><version>1.0</version><title>Achow101 [ARCHIVE] wrote</title><author_name>Achow101 [ARCHIVE] (npub1wh…d26cj)</author_name><author_url>https://yabu.me/npub1wh7lmdsh2r0ygnp39pk7k5a7mll5x5w44pwn6ekvdvmwjhazr5rqxd26cj</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2018-06-22&#xA;📝 Original message:Hi all,&#xA;&#xA;After reading the comments here about BIP 174, I would like to propose the following changes:&#xA;&#xA;- Moving redeemScripts, witnessScripts, and BIP 32 derivation paths to per-input and per-output data&#xA;&#xA;I think that by moving these three fields into input and output specific maps, the format will be&#xA;easier to read and simpler for signers to parse. Instead of having to be able to parse entire&#xA;scripts and extract pubkeys, the signer can simply look at which pubkeys are provided in the inputs&#xA;and sign the input based upon the presence of a pubkey for which the signer has a privkey.&#xA;&#xA;A neat trick that fits well with this model is that a plain pubkey (one that is not part of a BIP 32&#xA;derivation) can still be put in a BIP 32 derivation path field where the value is just the fingerprint&#xA;of the pubkey itself. This would indicate that no derivation needs to be done from the master key, and&#xA;the master key is just the specified key itself.&#xA;&#xA;Additionally, by having the redeemScript and witnessScript readily available in the input, signers&#xA;do not need to construct a map to find a redeemScript or witnessScript and can instead just look&#xA;directly in the input data. There is also no need to include the hashes of these scripts, so the key&#xA;is just the type. This also allows us to enforce the requirement for only one redeemScript and one&#xA;witnessScript per input easily by continuing to follow the generic rule of unique keys.&#xA;&#xA;By using input specific and output specific fields, there is no need for the input index and the input&#xA;count types as all inputs will be accounted for.&#xA;&#xA;- Finalized scriptSig and scriptWitness fields&#xA;&#xA;To determine whether two PSBTs are the same, we can compare the unsigned transaction. To ensure that the&#xA;unsigned transactions are the same for two PSBTs with data for the same tx, we cannot put scriptSigs or&#xA;scriptWitnesses into it. Thus for each input, two new fields have been added to store the finalized scriptSig&#xA;and finalized scriptWitness.&#xA;&#xA;- Mandatory sighash&#xA;&#xA;The sighash type field will be changed from a recommendation to a requirement. Signatures will need to &#xA;use the specified sighash type for that input. If a Signer cannot sign for a particular sighash type, it&#xA;must not add a partial signature.&#xA;&#xA;- Encoding&#xA;&#xA;I have decided that PSBTs should either be in binary or encoded as a Base64 string. For the latter, several&#xA;Bitcoin clients already support Base64 encoding of data (for signed messages) so this will not add any extra&#xA;dependencies like Z85 would.&#xA;&#xA;&#xA;A draft of the revised BIP can be found here: https://github.com/achow101/bips/blob/bip174-rev/bip-0174.mediawiki&#xA;If these changes are satisfactory, I will open a PR to the BIPs repo to update the BIP tomorrow. I will also&#xA;create test vectors and update the implementation PR&#39;ed to Core.&#xA;&#xA;Andrew</html></oembed>