rich1.0Peter D. Gray [ARCHIVE] (npub10v…t058y)https://yabu.me/npub10vqyu8x3f0lfttk98xc28ppuyufaz4df8x4aspa9w9xz5z05snzq7t058ynjumphttps://yabu.me📅 Original date posted:2018-06-23 📝 Original message:On Fri, Jun 22, 2018 at 06:28:33PM -0400, Achow101 wrote: > After reading the comments here about BIP 174, I would like to propose the following changes: > > - Moving redeemScripts, witnessScripts, and BIP 32 derivation paths to per-input and per-output data ... I like this. I agree it's making things easier and it's more flexible. > - Finalized scriptSig and scriptWitness fields > > To determine whether two PSBTs are the same, we can compare the unsigned transaction. To ensure that the > unsigned transactions are the same for two PSBTs with data for the same tx, we cannot put scriptSigs or > scriptWitnesses into it. Thus for each input, two new fields have been added to store the finalized scriptSig > and finalized scriptWitness. ... To be honest, I don't understand the reasons/implications of this change, but it seems harmless. > - Mandatory sighash ... Good improvement. > - Encoding > > I have decided that PSBTs should either be in binary or encoded as a Base64 string. For the latter, several > Bitcoin clients already support Base64 encoding of data (for signed messages) so this will not add any extra > dependencies like Z85 would. ... Personally, 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. On 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. > A draft of the revised BIP can be found here: https://github.com/achow101/bips/blob/bip174-rev/bip-0174.mediawiki > If these changes are satisfactory, I will open a PR to the BIPs repo to update the BIP tomorrow. I will also > create test vectors and update the implementation PR'ed to Core. ... Looking forward to test vectors, and I might have more to say once my code can handle them (again). Feedback on the BIP as it stands now: - 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. - Those tables are just not working. Might want to reformat as descriptive lists, point form, or generally anything else... sorry. > Andrew > _______________________________________________ --- Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180623/9c0b1846/attachment.sig>