{"type":"rich","version":"1.0","title":"Greg Sanders [ARCHIVE] wrote","author_name":"Greg Sanders [ARCHIVE] (npub1jd…3gh0m)","author_url":"https://yabu.me/npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0m","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-06-21\n📝 Original message:\u003eHmm, upon further reflection, maybe it's not even worth including *any*\nper-output data, aside from what the original transaction contains.\n\n\u003eThe 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\nSigners are an extremely heterogeneous bunch. A signer may need to\nintrospect on the script, such as \"this is a 2-of-3,\nand I'm one of the keys\". Even in basic p2pkh settings not adding any\noutput information rules out things like change\ndetection on any conceivable hardware wallet, or even simple software\nwallets that don't carry significant state.\n\nOn Thu, Jun 21, 2018 at 10:35 AM Tomas Susanka via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hello,\n\u003e\n\u003e First of all, let me thank you for all the hard work you and others have\n\u003e put into this.\n\u003e\n\u003e\n\u003e On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote:\n\u003e \u003e While I agree that the BIP itself should be revised to reflect these\n\u003e suggestions, I fear that it may be too late. I know of a few other\n\u003e developers who have implemented BIP 174 already but have not yet responded\n\u003e to this email.\n\u003e\n\u003e We do realize that this discussion should have happened earlier, however\n\u003e agreeing on a good standard should be the number one priority for all\n\u003e the parties involved.\n\u003e\n\u003e The fact that someone already implemented this is indeed unfortunate,\n\u003e but I don't think we should lower our demands on the standard just\n\u003e because of a bad timing.\n\u003e\n\u003e \u003e\u003e A question to consider is,\n\u003e \u003e\u003e will there be more per-output data? If yes, it might make sense to have\n\u003e \u003e\u003e an output section.\n\u003e \u003e I think it is unlikely that there would be anymore per-output data.\n\u003e\n\u003e Hmm, upon further reflection, maybe it's not even worth including *any*\n\u003e per-output data, aside from what the original transaction contains.\n\u003e\n\u003e The output redeem script is either:\n\u003e - unknown, because we have received only an address from the receiver\n\u003e - or it is known, because it is ours and in that case it doesn’t make\n\u003e sense to include it in PSBT\n\u003e\n\u003e We got stuck on the idea of the Creator providing future (output)\n\u003e redeem/witness scripts. But that seems to be a minority use case and can\n\u003e be solved efficiently via the same channels that coordinate the PSBT\n\u003e creation. Sorry to change opinions so quickly on this one.\n\u003e\n\u003e \u003e\n\u003e \u003e\u003e 3) The sighash type 0x03 says the sighash is only a recommendation. That\n\u003e \u003e\u003e seems rather ambiguous. If the field is specified shouldn't it be\n\u003e binding?\n\u003e \u003e I disagree. It is up to the signer to decide what they wish to sign, not\n\u003e for the creator to specify what to sign. The creator can ask the signer to\n\u003e sign something in a particular way, but it is ultimately up to the signer\n\u003e to decide.\n\u003e\n\u003e This seems very ambiguous. The Signer always has the option of not\n\u003e signing. *What* to sign is a matter of coordination between the parties;\n\u003e otherwise, you could make all the fields advisory and let anyone sign\n\u003e anything they like?\n\u003e\n\u003e We don't understand the usecase for a field that is advisory but not\n\u003e binding. On what basis would you choose to respect or disregard the\n\u003e advisory field? Either one party has a preference, in which case they\n\u003e have to coordinate with the other anyway - or they don't, in which case\n\u003e they simply leave the field out.\n\u003e\n\u003e \u003e Size is not really a constraint, but we do not want to be unnecessarily\n\u003e large. The PSBT still has to be transmitted to other people. It will likely\n\u003e be used by copy and pasting the string into a text box. Copying and pasting\n\u003e very long strings of text can be annoying and cumbersome. So the goal is to\n\u003e keep the format still relatively clear while avoiding the duplication of\n\u003e data.\n\u003e\n\u003e I agree. Just to put some numbers on this: if we expect a 5-part\n\u003e derivation path, and add the master key fingerprint, that is 4 + 5*4 =\n\u003e 24 bytes (~32 base64 letters) per input and signer. I'd argue this is\n\u003e not significant.\n\u003e If we used full xpub, per Pieter's suggestion, that would grow to 32 +\n\u003e 32 + 5*4 = 84 bytes (~112 letters) per input/signer, which is quite a lot.\n\u003e\n\u003e On the other hand, keeping the BIP32 paths per-input means that we don't\n\u003e need to include the public key (as in the lookup key), so that's 32\n\u003e bytes down per path. In general, all the keys can be fully reconstructed\n\u003e from their values:\n\u003e\n\u003e redeem script key = hash160(value)\n\u003e witness script key = sha256(value)\n\u003e bip32 key = derive(value)\n\u003e\n\u003e The one exception is a partial signature. But even in that case we\n\u003e expect that a given public key will always correspond to the same\n\u003e signature, so we can act as if the public key is not part of the \"key\".\n\u003e In other words, we can move the public key to the value part of the record.\n\u003e\n\u003e This holds true unless there's some non-deterministic signing scheme,\n\u003e *and* multiple Signers sign with the same public key, which is what\n\u003e Pieter was alluding to on Twitter\n\u003e (https://twitter.com/pwuille/status/1002627925110185984). Still, I would\n\u003e argue (as he also suggested) that keeping the format more complex to\n\u003e support this particular use case is probably not worth it.\n\u003e\n\u003e Also, we can mostly ignore deduplication of witness/redeem scripts.\n\u003e These still need to be included in the resulting transaction, duplicated\n\u003e if necessary, so I think counting their repetition against the size of\n\u003e PSBT isn't worth it.\n\u003e\n\u003e\n\u003e Best,\n\u003e Tomas\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180621/b752efa0/attachment.html\u003e"}