From: Anthony Towns <aj@erisian•com.au>
To: Russell O'Connor <roconnor@blockstream•com>
Cc: jonasd.nick@gmail•com,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Pieter Wuille <pieter.wuille@gmail•com>
Subject: Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message
Date: Sun, 3 May 2020 00:26:02 +1000 [thread overview]
Message-ID: <20200502142602.rj7q2m32ew6trh6u@erisian.com.au> (raw)
In-Reply-To: <CAMZUoKm9sogtKS0YqOz8JNNbiiwBdkPbdEvf67yzcJr1BZ7_wA@mail.gmail.com>
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
next prev parent reply other threads:[~2020-05-02 15:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 14:57 Andrew Kozlik
2020-05-01 6:57 ` Jeremy
2020-05-01 8:48 ` Andrew Kozlik
2020-05-01 12:23 ` Russell O'Connor
2020-05-01 12:25 ` Greg Sanders
2020-05-02 4:35 ` Jeremy
2020-05-02 14:26 ` Anthony Towns [this message]
2020-05-02 14:43 ` Russell O'Connor
2020-05-02 21:15 ` Russell O'Connor
2020-05-04 15:48 ` Andrew Kozlik
2020-05-02 12:53 ` David A. Harding
2020-05-05 10:20 ` Jonas Nick
2020-05-11 22:12 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200502142602.rj7q2m32ew6trh6u@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jonasd.nick@gmail$(echo .)com \
--cc=pieter.wuille@gmail$(echo .)com \
--cc=roconnor@blockstream$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox