{"type":"rich","version":"1.0","title":"Andrea [ARCHIVE] wrote","author_name":"Andrea [ARCHIVE] (npub18r…8qr6z)","author_url":"https://yabu.me/npub18rpmnsgdeefa9vxvg4sewhx70wjmnhtkcpdxuecyrlyg7ref4eyqd8qr6z","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-06-24\n📝 Original message:Hi, \n\nI 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.\n\nCheers, Andrea.\n\n‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\n\nOn June 23, 2018 10:33 PM, Andrew Chow via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e ​​\n\u003e \n\u003e On 06/23/2018 10:00 AM, William Casarin wrote:\n\u003e \n\u003e \u003e Since we're still considering the encoding, I wonder if it would be a\n\u003e \u003e \n\u003e \u003e good idea to have a human-readible part like lightning invoices[1]?\n\u003e \n\u003e I don't think that is necessary.\n\u003e \n\u003e \u003e Then perhaps you could drop the magic code as well?\n\u003e \n\u003e The magic is still necessary for the binary format in order to prevent\n\u003e \n\u003e normal transaction deserializers from accidentally deserializing a psbt.\n\u003e \n\u003e \u003e Also we could do a base encoding that excludes + and / characters, such\n\u003e \u003e \n\u003e \u003e as base62 (gmp-style). It's easier to copy/paste (double clicking a\n\u003e \u003e \n\u003e \u003e string stops at / or + in base64 encodings).\n\u003e \n\u003e While that would be ideal, I think it is better to use an encoding that\n\u003e \n\u003e most wallets already support. Most wallets already have Base64 decoding\n\u003e \n\u003e available so that they can decode signed messages which also use Base64\n\u003e \n\u003e encoding. I think it is unnecessary to introduce another encoding.\n\u003e \n\u003e On 06/23/2018 11:27 AM, Peter D. Gray wrote:\n\u003e \n\u003e \u003e 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.\n\u003e \n\u003e I think what will end up happening though is that, at least in the\n\u003e \n\u003e beginning, PSBTs will primarily be strings that people end up copy and\n\u003e \n\u003e pasting. Since a PSBT can get pretty large, the strings are rather\n\u003e \n\u003e cumbersome to move around, especially as hex. At least with Base64 the\n\u003e \n\u003e strings will be smaller.\n\u003e \n\u003e \u003e 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.\n\u003e \n\u003e Agreed. I will include those in the BIP.\n\u003e \n\u003e \u003e Looking forward to test vectors, and I might have more to say once my code can handle them (again).\n\u003e \u003e \n\u003e \u003e Feedback on the BIP as it stands now:\n\u003e \u003e \n\u003e \u003e -   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\u003e \n\u003e Okay.\n\u003e \n\u003e \u003e -   Those tables are just not working. Might want to reformat as descriptive lists, point form, or generally anything else... sorry.\n\u003e \n\u003e I will try my best to fix that. Mediawiki sucks...\n\u003e \n\u003e Andrew\n\u003e \n\u003e bitcoin-dev mailing list\n\u003e \n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}