{"type":"rich","version":"1.0","title":"Tomas Susanka [ARCHIVE] wrote","author_name":"Tomas Susanka [ARCHIVE] (npub1pz…xnfhv)","author_url":"https://yabu.me/npub1pzhqhlvhvdg3ygr8keypprax6gg0qmsrtypmez67few4uzsvhqaqkxnfhv","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-06-21\n📝 Original message:Hello,\n\nFirst of all, let me thank you for all the hard work you and others have\nput into this.\n\n\nOn 21.6.2018 02:39, Achow101 via bitcoin-dev wrote:\n\u003e While 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\nWe do realize that this discussion should have happened earlier, however\nagreeing on a good standard should be the number one priority for all\nthe parties involved.\n\nThe fact that someone already implemented this is indeed unfortunate,\nbut I don't think we should lower our demands on the standard just\nbecause of a bad timing.\n\n\u003e\u003e A question to consider is,\n\u003e\u003e will there be more per-output data? If yes, it might make sense to have\n\u003e\u003e an output section.\n\u003e I think it is unlikely that there would be anymore per-output data.\n\nHmm, upon further reflection, maybe it's not even worth including *any*\nper-output data, aside from what the original transaction contains.\n\nThe output redeem script is either:\n- unknown, because we have received only an address from the receiver\n- or it is known, because it is ours and in that case it doesn’t make\nsense to include it in PSBT\n\nWe got stuck on the idea of the Creator providing future (output)\nredeem/witness scripts. But that seems to be a minority use case and can\nbe solved efficiently via the same channels that coordinate the PSBT\ncreation. Sorry to change opinions so quickly on this one.\n\n\u003e\n\u003e\u003e 3) The sighash type 0x03 says the sighash is only a recommendation. That\n\u003e\u003e seems rather ambiguous. If the field is specified shouldn't it be binding?\n\u003e I 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\nThis seems very ambiguous. The Signer always has the option of not\nsigning. *What* to sign is a matter of coordination between the parties;\notherwise, you could make all the fields advisory and let anyone sign\nanything they like?\n\nWe don't understand the usecase for a field that is advisory but not\nbinding. On what basis would you choose to respect or disregard the\nadvisory field? Either one party has a preference, in which case they\nhave to coordinate with the other anyway - or they don't, in which case\nthey simply leave the field out.\n\n\u003e Size 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\nI agree. Just to put some numbers on this: if we expect a 5-part\nderivation path, and add the master key fingerprint, that is 4 + 5*4 =\n24 bytes (~32 base64 letters) per input and signer. I'd argue this is\nnot significant.\nIf we used full xpub, per Pieter's suggestion, that would grow to 32 +\n32 + 5*4 = 84 bytes (~112 letters) per input/signer, which is quite a lot.\n\nOn the other hand, keeping the BIP32 paths per-input means that we don't\nneed to include the public key (as in the lookup key), so that's 32\nbytes down per path. In general, all the keys can be fully reconstructed\nfrom their values:\n\nredeem script key = hash160(value)\nwitness script key = sha256(value)\nbip32 key = derive(value)\n\nThe one exception is a partial signature. But even in that case we\nexpect that a given public key will always correspond to the same\nsignature, so we can act as if the public key is not part of the \"key\".\nIn other words, we can move the public key to the value part of the record.\n\nThis holds true unless there's some non-deterministic signing scheme,\n*and* multiple Signers sign with the same public key, which is what\nPieter was alluding to on Twitter\n(https://twitter.com/pwuille/status/1002627925110185984). Still, I would\nargue (as he also suggested) that keeping the format more complex to\nsupport this particular use case is probably not worth it.\n\nAlso, we can mostly ignore deduplication of witness/redeem scripts.\nThese still need to be included in the resulting transaction, duplicated\nif necessary, so I think counting their repetition against the size of\nPSBT isn't worth it.\n\n\nBest,\nTomas"}