{"type":"rich","version":"1.0","title":"Achow101 [ARCHIVE] wrote","author_name":"Achow101 [ARCHIVE] (npub1wh…d26cj)","author_url":"https://yabu.me/npub1wh7lmdsh2r0ygnp39pk7k5a7mll5x5w44pwn6ekvdvmwjhazr5rqxd26cj","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-06-20\n📝 Original message:Hi,\n\nOn June 15, 2018 4:34 PM, Pieter Wuille via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e \n\u003e Hello all,\n\u003e \n\u003e given some recent work and discussions around BIP 174 (Partially\n\u003e Signed Bitcoin Transaction Format) I'd like to bring up a few ideas.\n\u003e First of all, it's unclear to me to what extent projects have already\n\u003e worked on implementations, and thus to what extent the specification\n\u003e is still subject to change. A response of \"this is way too late\" is\n\u003e perfectly fine.\n\nWhile I agree that the BIP itself should be revised to reflect these suggestions, I fear that it may be too late. I know of a few other developers who have implemented BIP 174 already but have not yet responded to this email.\n\n\u003e     \n\u003e -   Generic key offset derivation\n\u003e\n\u003e     Whenever a BIP32 derivation path does not include any hardened steps,\n\u003e     the entirety of the derivation can be conveyed as \"The private key for\n\u003e     P is equal to the private key for Q plus x\", with P and Q points and x\n\u003e     a scalar. This representation is more flexible (it also supports\n\u003e     pay-to-contract derivations), more efficient, and more compact. The\n\u003e     downside is that it requires the Signer to support such derivation,\n\u003e     which I don't believe any current hardware devices do.\n\u003e     Would it make sense to add this as an additional derivation method?\n\nWhile this is a good idea, I'm not sure that implementers would understand this as it requires knowing the cryptography which makes this possible. As an optional feature, not all wallets would understand it, and those that do could create PSBTs which other wallets do not understand and thus cannot sign even if they have the private keys and actually can sign.\n\n\u003e     \n\u003e -   Hex encoding?\n\u003e     \n\u003e     This is a very minor thing. But presumably there will be some standard\n\u003e     way to store PSBTs as text for copy-pasting - either prescribed by the\n\u003e     spec, or de facto. These structures may become pretty large, so\n\u003e     perhaps it's worth choosing something more compact than hexadecimal -\n\u003e     for example Base64 or even Z85 (https://rfc.zeromq.org/spec:32/Z85/).\n\nAgreed. Are there any encodings that do not have double click breaking characters?\n\n\nOn June 19, 2018 2:38 AM, Jonas Schnelli via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I think it could be more flexible (generic) in BIP174.\n\u003e It could be just a single child key {32-bit int}, or just a keypath ({32-bit int}]{32-bit int}…) which is very likely sufficient for a HWW to derive the relevant key without the creation of a lookup-window or other „maps\".\n\nThis ignores all of the other times that a BIP32 keypath needs to be provided. It is not only used for multisig, there may be other times that there are multiple derivation paths and master keys due to multiple inputs and such. Adding a field specific to multisig and HWW only seems pointless and redundant to me.\n\nOn June 19, 2018 2:38 AM, Jonas Schnelli via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e A question to consider is,\n\u003e will there be more per-output data? If yes, it might make sense to have\n\u003e an output section.\n\nI think it is unlikely that there would be anymore per-output data.\n\n\u003e 3) The sighash type 0x03 says the sighash is only a recommendation. That\n\u003eseems rather ambiguous. If the field is specified shouldn't it be binding?\n\nI disagree. It is up to the signer to decide what they wish to sign, not for the creator to specify what to sign. The creator can ask the signer to sign something in a particular way, but it is ultimately up to the signer to decide.\n\n\u003e 4) Is it a good idea to skip records which types we are unaware of? We\n\u003e can't come up with a reasonable example, but intuitively this seems as a\n\u003e potential security issue. We think we should consider  introducing a\n\u003e flag, which would define if the record is \"optional\". In case the signer\n\u003e encounters a record it doesn't recognize and such flag is not set, it\n\u003e aborts the procedure. If we assume the set model we could change the\n\u003e structure to \u003ctype\u003e\u003coptional flag\u003e\u003clength\u003e{data}. We are not keen on\n\u003e this, but we wanted to include this idea to see what you think.\n\nThe idea behind skipping unknown types is to allow forward compatibility. A combiner written now should be able to combine transactions created in the future with new types as combining is really only just merging the maps together.\n\n\u003e In general, the standard is trying to be very space-conservative,\n\u003e however is that really necessary? We would argue for clarity and ease of\n\u003e use over space constraints. We think more straightforward approach is\n\u003e desired, although more space demanding. What are the arguments to make\n\u003e this as small as possible? If we understand correctly, this format is\n\u003e not intended for blockchain nor for persistent storage, so size doesn’t\n\u003e matter nearly as much.\n\nSize is not really a constraint, but we do not want to be unnecessarily large. The PSBT still has to be transmitted to other people. It will likely be used by copy and pasting the string into a text box. Copying and pasting very long strings of text can be annoying and cumbersome. So the goal is to keep the format still relatively clear while avoiding the duplication of data.\n\n\nAndrew"}