{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-05-02\n📝 Original message:On Fri, May 01, 2020 at 08:23:07AM -0400, Russell O'Connor wrote:\n\u003e Regarding specifics, I personally think it would be better to keep the\n\u003e hashes of the ScriptPubKeys separate from the hashes of the input values.\n\nI think Andrew's original suggestion achieves this:\n\n\u003e\u003e The obvious way to implement this is to add another hash to the\n\u003e\u003e signature message:\n\u003e\u003e   sha_scriptPubKeys (32): the SHA256 of the serialization of all\n\u003e\u003e   scriptPubKeys of the previous outputs spent by this\n\u003e\u003e   transaction.\n\npresumably with sha_scriptPubKeys' inclusion being conditional on\nhash_type not matching ANYONECANPAY.\n\nWe could possibly also make the \"scriptPubKey\" field dependent on\nhash_type matching ANYONECANPAY, making this not cost any more\nin serialised bytes per signature.\n\nThis would basically mean we're committing to each component of the\nUTXOs being spent:\n\n  without ANYONECANPAY:\n    sha_prevouts commits to the txid hashes and vout indexes (COutPoint)\n    sha_amounts commits to the nValues (Coin.CTxOut.nValue)\n    sha_scriptpubkeys commits to the scriptPubKey (Coin.CTxOut.scriptPubKey)\n\n  with ANYONECANPAY it's the same but just for this input's prevout:\n    outpoint\n    amount\n    scriptPubKey\n\nexcept that we'd arguably still be missing:\n\n    is this a coinbase output? (Coin.fCoinBase)\n    what was the height of the coin? (Coin.nHeight)\n\nMaybe committing to the coinbase flag would have some use, but committing\nto the height would make it hard to chain unconfirmed spends, so at\nleast that part doesn't seem worth adding.\n\n\u003e I would also (and independently) propose\n\u003e separating the hashing of the output values from the output ScriptPubKeys in\n\u003e `sha_outputs` so again, applications interested only in summing the values of\n\u003e the outputs (for instance to compute fees) do not have to wade through those\n\u003e arbitrarily long ScriptPubKeys in the outputs.\n\nIf you didn't verify the output scriptPubKeys, you would *only* be able\nto care about fees since you couldn't verify where any of the funds went?\nAnd you'd only be able to say fees are \"at least x\", since they could be\nmore if one of the scriptPubKeys turned out to be OP_TRUE eg. That might\nalmost make sense for a transaction accelerator that's trying to increase\nthe fees; but only if you were doing it for someone else's transaction\n(since otherwise you'd care about the output addresses) and only if you\nwere happy to not receive any change? Seems like a pretty weird use case?\n\nThere's some prior discussion on this topic at:\n\nhttp://www.erisian.com.au/taproot-bip-review/log-2020-03-04.html\nhttp://www.erisian.com.au/taproot-bip-review/log-2020-03-05.html\n\nCheers,\naj"}