Keeping it for future extensions is a good point, my understanding was that since we always need exactly one transaction it could be part of the definition of PSBT instead of being a key-value (although it is more of a breaking change).
Cheers, Andrea. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On June 24, 2018 10:28 AM, Andrew Chow <achow101-li...@achow101.com> wrote: > > > 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
