From: Pieter Wuille <bitcoin-dev@wuille•net>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message
Date: Mon, 11 May 2020 22:12:33 +0000 [thread overview]
Message-ID: <nBFUYhh-NT7PgBCGMWz2S41WT_NJqs7KTapXjwTCqXf8HrPAIEDm_zrpU_02RwO-eTEp5ocyWgkEtuYe7kvY2C7OTZi4ruL9xCXpga-a3BU=@wuille.net> (raw)
In-Reply-To: <1a8f1b92-e965-c1b3-b554-600541c8bac9@gmail.com>
Hi all,
On Tuesday, May 5, 2020 3:20 AM, Jonas Nick via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> This is a reasonable suggestion. Committing to every spent scriptPubKey and
> therefore every element of the TxOut instead of just the amount makes sense
> conceptually. And it would be a small diff (~4 lines + rationale) compared to
> the current bip-taproot version.
I agree.
There have been several steps so far towards making it possible for signers to determine whether they can safely sign with just O(1) information per input. This was initially attempted in BIP141 (by committing to spent input, to thwart the ability to lie about fees to ofline signers), and is improved in the current BIP341.
I think the CoinJoin + offline signer model indeed shows that is still incomplete, as it is yet another example where a signer may need to be provided with the entire creating transaction, which would be very unfortunate.
It's also counter to the model proposed by BIP147 (PSBT) workflows: the assumption is effectively already that it is sufficient to provide signers with just amount + scriptPubKey of the spent outputs. It feels very natural that signatures then indeed also need to commit to all that data; otherwise there should be ways that this information can be undetectably wrong.
AJ's approach seems great. It means not increasing the per-signature hashing, while retaining the ability to cache information across BIP141/BIP341.
As for coinbaseness and height: these are indeed also things currently kept track of in the UTXO set, but I don't think any signer is using this information to determine whether to sign or not (which I think is the minimum requirement for it to be included in a signature hash, see above). Signing height would cripple the ability to spend unconfirmed outputs, or force signers to reveal they're doing so (if done through a separate sighash flag) - both of which would be undesirable. That leaves coinbaseness, but I think the utility is very low.
The only downside is that this potentially slows down review, but I agree with earlier comments that it's hard to see how this would hurt. I also think it's important to get these things right from the start. Many things inside BIP341/BIP342 are extensible with future softforks, but signature hashes for key-path spends is not one of them (the set of potential signature hash semantics must be committed to directly by the output, so changing them requires a new output type - which would be highly unfortunate for fungibility reasons).
Thus, unless there are objections, I'd like to go through with this and make the suggested changes.
Thoughts?
--
Pieter
prev parent reply other threads:[~2020-05-11 22:12 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
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 [this message]
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='nBFUYhh-NT7PgBCGMWz2S41WT_NJqs7KTapXjwTCqXf8HrPAIEDm_zrpU_02RwO-eTEp5ocyWgkEtuYe7kvY2C7OTZi4ruL9xCXpga-a3BU=@wuille.net' \
--to=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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