{"type":"rich","version":"1.0","title":"Peter D. Gray [ARCHIVE] wrote","author_name":"Peter D. Gray [ARCHIVE] (npub10v…t058y)","author_url":"https://yabu.me/npub10vqyu8x3f0lfttk98xc28ppuyufaz4df8x4aspa9w9xz5z05snzq7t058y","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-06-23\n📝 Original message:On Fri, Jun 22, 2018 at 06:28:33PM -0400, Achow101 wrote:\n\u003e After reading the comments here about BIP 174, I would like to propose the following changes:\n\u003e \n\u003e - Moving redeemScripts, witnessScripts, and BIP 32 derivation paths to per-input and per-output data\n...\n\nI like this. I agree it's making things easier and it's more flexible.\n\n\u003e - Finalized scriptSig and scriptWitness fields\n\u003e \n\u003e To determine whether two PSBTs are the same, we can compare the unsigned transaction. To ensure that the\n\u003e unsigned transactions are the same for two PSBTs with data for the same tx, we cannot put scriptSigs or\n\u003e scriptWitnesses into it. Thus for each input, two new fields have been added to store the finalized scriptSig\n\u003e and finalized scriptWitness.\n...\n\nTo be honest, I don't understand the reasons/implications of this change, but it seems harmless.\n\n\u003e - Mandatory sighash\n...\n\nGood improvement.\n\n\u003e - Encoding\n\u003e \n\u003e I have decided that PSBTs should either be in binary or encoded as a Base64 string. For the latter, several\n\u003e Bitcoin clients already support Base64 encoding of data (for signed messages) so this will not add any extra\n\u003e dependencies like Z85 would.\n...\n\nPersonally, I don't think you should spec an encoding. It should be binary only and hex for developers and JSON interfaces. My thinking is that PSBT's are not user-visible things. They have a short lifetime and are nothing something that is \"stored\" or referenced much later. Hex is good enough and has no downsides as an excoding except for density.\n\nOn the other hand, suggesting a filename extension (probably .PSBT?) and a mime-type to match, are helpful since wallets and such will want to register with their operating systems to become handlers of those mimetypes. Really that's a lot more important for interoperability at this point, than an encoding.\n\n\u003e A draft of the revised BIP can be found here: https://github.com/achow101/bips/blob/bip174-rev/bip-0174.mediawiki\n\u003e If these changes are satisfactory, I will open a PR to the BIPs repo to update the BIP tomorrow. I will also\n\u003e create test vectors and update the implementation PR'ed to Core.\n...\n\nLooking forward to test vectors, and I might have more to say once my code can handle them (again).\n\nFeedback on the BIP as it stands now: \n\n- Appendix A needs an update, and I suggest defining symbols (PK_PARTIAL_SIG == 0x02) for the numeric key values. This helps implementers as we don't all define our own symbols and/or use numeric constants in our code.\n\n- Those tables are just not working. Might want to reformat as descriptive lists, point form, or generally anything else... sorry.\n\n\u003e Andrew\n\u003e _______________________________________________\n\n---\nPeter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG: A3A31BAD 5A2A5B10\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180623/9c0b1846/attachment.sig\u003e"}