1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
Return-Path: <aj@erisian.com.au>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id A3DC3C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 May 2020 15:07:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 94BCD8832F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 May 2020 15:07:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id EHHEt7f1gaPS
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 May 2020 15:07:26 +0000 (UTC)
X-Greylist: delayed 00:41:12 by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by whitealder.osuosl.org (Postfix) with ESMTPS id 7C74F8832E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 May 2020 15:07:26 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1jUt5j-00073Z-Qx; Sun, 03 May 2020 00:26:09 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Sun, 03 May 2020 00:26:02 +1000
Date: Sun, 3 May 2020 00:26:02 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.com>
Message-ID: <20200502142602.rj7q2m32ew6trh6u@erisian.com.au>
References: <CACvH2e=3s2kZWnytMySTv8U4pny3i0rEWas7NxzLxf5J7BewTg@mail.gmail.com>
<CAMZUoKm9sogtKS0YqOz8JNNbiiwBdkPbdEvf67yzcJr1BZ7_wA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMZUoKm9sogtKS0YqOz8JNNbiiwBdkPbdEvf67yzcJr1BZ7_wA@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score-int: -18
X-Spam-Bar: -
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 02 May 2020 15:07:27 -0000
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
|
