I disagree with the idea that global types can be removed. Firstly, it is less of a breaking change to leave it there than to remove it entirely. Secondly, there may be a point in the future where global types would be useful/necessary. By having it still be there, we allow for future extensibility.
Andrew On 06/24/2018 01:19 AM, Andrea wrote: > Hi, > > I think in the revised spec we can remove completely the "global types" as a > map or even as typed record. Since there is only one type (the transaction) > and it's compulsory to have one (and only one) we could just drop the > definition of global type and the key associated with it, simply after the > header + separator there must be a transaction. Having read all the > discussion i also agree having per-input key derivation and per-output data > is a lot more handy for signers, no special feeling regarding the > encoding.Looking forward for the test vectors and the new spec. > > Cheers, Andrea. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On June 23, 2018 10:33 PM, Andrew Chow via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> >> On 06/23/2018 10:00 AM, William Casarin wrote: >> >>> Since we're still considering the encoding, I wonder if it would be a >>> >>> good idea to have a human-readible part like lightning invoices[1]? >> I don't think that is necessary. >> >>> Then perhaps you could drop the magic code as well? >> The magic is still necessary for the binary format in order to prevent >> >> normal transaction deserializers from accidentally deserializing a psbt. >> >>> Also we could do a base encoding that excludes + and / characters, such >>> >>> as base62 (gmp-style). It's easier to copy/paste (double clicking a >>> >>> string stops at / or + in base64 encodings). >> While that would be ideal, I think it is better to use an encoding that >> >> most wallets already support. Most wallets already have Base64 decoding >> >> available so that they can decode signed messages which also use Base64 >> >> encoding. I think it is unnecessary to introduce another encoding. >> >> On 06/23/2018 11:27 AM, Peter D. Gray wrote: >> >>> 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. >> I think what will end up happening though is that, at least in the >> >> beginning, PSBTs will primarily be strings that people end up copy and >> >> pasting. Since a PSBT can get pretty large, the strings are rather >> >> cumbersome to move around, especially as hex. At least with Base64 the >> >> strings will be smaller. >> >>> 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. >> Agreed. I will include those in the BIP. >> >>> 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. >> Okay. >> >>> - Those tables are just not working. Might want to reformat as >>> descriptive lists, point form, or generally anything else... sorry. >> I will try my best to fix that. Mediawiki sucks... >> >> Andrew >> >> bitcoin-dev mailing list >> >> bitcoin-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
