{"type":"rich","version":"1.0","author_name":"npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","author_url":"https://nostr.ae/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-05-02\n📝 Original message:At the end of the day I don't really care that much I just prefer something\nthat doesn't throw taproot in for another review cycle.\n\nA side effect of this proposal is it would seem to make it not possible to\nproduce a signature for a transaction without having access to the inputs.\nThis is limiting for a number of cases where you don't care about that\ndata. There are a litany of use cases where you don't want to have\nSIGHASH_ALL behavior, and having to sign the scriptpubkeys breaks that. So\nat the very least it should respect other flags.\n\nI also don't really understand the exact attack. So you submit a\ntransaction to the wallet asking them to sign input 10. They sign. They've\ncommitted to the signature being bound to the specific COutpoint and input\nindex, so I don't see how they wouldn't be required to sign a second\nsignature with the other output too? Is there an attack you can describe\nend-to-end relying on this behavior?\n\nIf you look at the TXID hash the vouts are one of the last fields\nserialized. this makes it possible (at least, I think) to do a midstate\nproof so that all you are providing is the hash midstate, and the relevant\ntransaction output,  the siblings after, and the locktime. So you get to\nskip all the input data, the witness data, and most of the output data.\n\nThis sort of data can easily go into the proprietary use (maybe becoming\nwell defined if there's a standardization push) area in PSBT, so that\nhardware devices can get easy access to it. All they have to do to verify\nis to finalize the hash against that buffer and match to the correct input.\n\n\nAs an alternative proposal, I think you can just make a separate BIP for\nsome new sigash flags that can be reviewed separately from taproot. There's\na lot of value in investing in figuring out more granular controls over\nwhat the signature hash is you sign, which may have some exciting\ncontracting implications!\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n\n\nOn Fri, May 1, 2020 at 5:26 AM Greg Sanders via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e For what it's worth this measure had been discussed as a lightweight way\n\u003e of informing offline signers if inputs were segwit or not for malleability\n\u003e analysis reasons. So there's at least a couple direct use-cases it seems.\n\u003e\n\u003e On Fri, May 1, 2020, 8:23 AM Russell O'Connor via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e While I'm not entirely convinced yet that accertaining non-ownership of\n\u003e\u003e an input is a robust method of solving the problem here, I also see little\n\u003e\u003e reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is\n\u003e\u003e already indirectly covered through the outpoints, so it is just a matter of\n\u003e\u003e optimization.  Furthermore in the consensus code, the ScriptPubKeys are\n\u003e\u003e part of the UTXO data set, and it is already being retrieved as part of the\n\u003e\u003e transaction checking process, so it is readily available.\n\u003e\u003e\n\u003e\u003e I'm not sure how much my opinion on the topic matters, but I did include\n\u003e\u003e this kind of functionality in my design for Simplicity on Elements, and I\n\u003e\u003e have been leaning towards adding this kind of functionality in my Bitcoin\n\u003e\u003e demo application of Simplicity.\n\u003e\u003e\n\u003e\u003e Regarding specifics, I personally think it would be better to keep the\n\u003e\u003e hashes of the ScriptPubKeys separate from the hashes of the input values.\n\u003e\u003e This way anyone only interested in input values does not need to wade\n\u003e\u003e through what are, in principle, arbitrarily long ScriptPubKeys in order to\n\u003e\u003e check the input values (which each fixed size).  To that end, I would also\n\u003e\u003e (and independently) propose separating the hashing of the output values\n\u003e\u003e from the output ScriptPubKeys in `sha_outputs` so again, applications\n\u003e\u003e interested only in summing the values of the outputs (for instance to\n\u003e\u003e compute fees) do not have to wade through those arbitrarily long\n\u003e\u003e ScriptPubKeys in the outputs.\n\u003e\u003e\n\u003e\u003e On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Hi everyone,\n\u003e\u003e\u003e\n\u003e\u003e\u003e In the current draft of BIP-0341 [1] the signature message commits to\n\u003e\u003e\u003e the scriptPubKey of the output being spent by the input. I propose that the\n\u003e\u003e\u003e signature message should commit to the scriptPubKeys of *all* transaction\n\u003e\u003e\u003e inputs.\n\u003e\u003e\u003e\n\u003e\u003e\u003e In certain applications like CoinJoin, a wallet has to deal with\n\u003e\u003e\u003e transactions containing external inputs. To calculate the actual amount\n\u003e\u003e\u003e that the user is spending, the wallet needs to reliably determine for each\n\u003e\u003e\u003e input whether it belongs to the wallet or not. Without such a mechanism an\n\u003e\u003e\u003e adversary can fool the wallet into displaying incorrect information about\n\u003e\u003e\u003e the amount being spent, which can result in theft of user funds [2].\n\u003e\u003e\u003e\n\u003e\u003e\u003e In order to ascertain non-ownership of an input which is claimed to be\n\u003e\u003e\u003e external, the wallet needs the scriptPubKey of the previous output spent by\n\u003e\u003e\u003e this input. It must acquire the full transaction being spent and verify its\n\u003e\u003e\u003e hash against that which is given in the outpoint. This is an obstacle in\n\u003e\u003e\u003e the implementation of lightweight air-gapped wallets and hardware wallets\n\u003e\u003e\u003e in general. If the signature message would commit to the scriptPubKeys of\n\u003e\u003e\u003e all transaction inputs, then the wallet would only need to acquire the\n\u003e\u003e\u003e scriptPubKey of the output being spent without having to acquire and verify\n\u003e\u003e\u003e the hash of the entire previous transaction. If an attacker would provide\n\u003e\u003e\u003e an incorrect scriptPubKey, then that would cause the wallet to generate an\n\u003e\u003e\u003e invalid signature message.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Note that committing only to the scriptPubKey of the output being spent\n\u003e\u003e\u003e is insufficient for this application, because the scriptPubKeys which are\n\u003e\u003e\u003e needed to ascertain non-ownership of external inputs are precisely the ones\n\u003e\u003e\u003e that would not be included in any of the signature messages produced by the\n\u003e\u003e\u003e wallet.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The obvious way to implement this is to add another hash to the\n\u003e\u003e\u003e signature message:\n\u003e\u003e\u003e sha_scriptPubKeys (32): the SHA256 of the serialization of all\n\u003e\u003e\u003e scriptPubKeys of the previous outputs spent by this transaction.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Cheers,\n\u003e\u003e\u003e Andrew Kozlik\n\u003e\u003e\u003e\n\u003e\u003e\u003e [1]\n\u003e\u003e\u003e https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message\n\u003e\u003e\u003e [2]\n\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\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/20200501/03f1d2e4/attachment-0001.html\u003e"}