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