MIME-Version: 1.0
References: <CACvH2e=3s2kZWnytMySTv8U4pny3i0rEWas7NxzLxf5J7BewTg@mail.gmail.com>
 <CAMZUoKm9sogtKS0YqOz8JNNbiiwBdkPbdEvf67yzcJr1BZ7_wA@mail.gmail.com>
 <20200502142602.rj7q2m32ew6trh6u@erisian.com.au>
In-Reply-To: <20200502142602.rj7q2m32ew6trh6u@erisian.com.au>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Sat, 2 May 2020 10:43:13 -0400
Message-ID: <CAMZUoK=g-mtoxSpTc5BmhxFaoJK9n7-Q28o9LUzx4prVgd3WZA@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="000000000000f9215005a4ab5186"
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
Precedence: list

--000000000000f9215005a4ab5186
Content-Type: text/plain; charset="UTF-8"

> 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?
>

You are right of course.  I was thinking of cases where you only care about
where some of the outputs go but not all.  But of course, even in that case
you will need to wade through all of the output ScriptPubKeys anyways.
The current design shares the hashOuputs value with the one computed with
BIP-143, and that is a somewhat valuable property to keep.

Thanks for setting me straight.

--000000000000f9215005a4ab5186
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">
If you didn&#39;t verify the output scriptPubKeys, you would *only* be able=
<br>
to care about fees since you couldn&#39;t verify where any of the funds wen=
t?<br>
And you&#39;d only be able to say fees are &quot;at least x&quot;, since th=
ey could be<br>
more if one of the scriptPubKeys turned out to be OP_TRUE eg. That might<br=
>
almost make sense for a transaction accelerator that&#39;s trying to increa=
se<br>
the fees; but only if you were doing it for someone else&#39;s transaction<=
br>
(since otherwise you&#39;d care about the output addresses) and only if you=
<br>
were happy to not receive any change? Seems like a pretty weird use case?<b=
r></blockquote><div><br></div><div>You are right of course.=C2=A0 I was thi=
nking of cases where you only care about where some of the outputs go but n=
ot all.=C2=A0 But of course, even in that case you will need to wade throug=
h all of the output ScriptPubKeys anyways.</div><div>The current design sha=
res the hashOuputs value with the one computed with BIP-143, and that is a =
somewhat valuable property to keep.</div><div><br></div><div>Thanks for set=
ting me straight.</div></div></div>

--000000000000f9215005a4ab5186--