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 17:15:51 -0400
Message-ID: <CAMZUoKmrD78naPBcfGsfr_OxyYiWM+G47sWtpNGP+u-9r4MjXA@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="0000000000001cb04505a4b0ce8b"
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

--0000000000001cb04505a4b0ce8b
Content-Type: text/plain; charset="UTF-8"

On Sat, May 2, 2020 at 10:26 AM Anthony Towns <aj@erisian.com.au> wrote:

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

To add to this point, the height of the coin is something that is *not*
currently covered by any signature mode and including it would constitute a
change of an entirely different  caliber; a change that I would strongly
caution against for your above reason and more.

The coinbase output flag is currently covered by the signature as the
outpoint hash has the required information (its prevout index of 0xFFFFFFFF
is only legal in a coinbase transaction).  While I'm not particularly
enthusiastic about making it easier to distinguish coinbase outputs from
other outputs, and I worry a little about alternative designs for
implementing the Bitcoin protocol where this information is not so readily
available, I suppose I won't really oppose adding it.  However, I don't
think anyone is seriously proposing it.
-

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Sat, May 2, 2020 at 10:26 AM Anthony Towns &lt;<a href=3D"mailto:=
aj@erisian.com.au">aj@erisian.com.au</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><br>
except that we&#39;d arguably still be missing:<br>
<br>
=C2=A0 =C2=A0 is this a coinbase output? (Coin.fCoinBase)<br>
=C2=A0 =C2=A0 what was the height of the coin? (Coin.nHeight)<br>
<br>
Maybe committing to the coinbase flag would have some use, but committing<b=
r>
to the height would make it hard to chain unconfirmed spends, so at<br>
least that part doesn&#39;t seem worth adding.<br></blockquote><div><br></d=
iv><div>To add to this point, the height of the coin is something that is *=
not* currently covered by any signature mode and including it would constit=
ute a change of an entirely different=C2=A0 caliber; a change that I would =
strongly caution against for your above reason and more.</div><div><br></di=
v><div>The coinbase output flag is currently covered by the signature as th=
e outpoint hash has the required information (its prevout index of 0xFFFFFF=
FF is only legal in a coinbase transaction).=C2=A0 While I&#39;m not partic=
ularly enthusiastic about making it easier to distinguish coinbase outputs =
from other outputs, and I worry a little about alternative designs for impl=
ementing the Bitcoin protocol where this information is not so readily avai=
lable, I suppose I won&#39;t really oppose adding it.=C2=A0 However, I don&=
#39;t think anyone is seriously proposing it.<br><li></li></div></div></div=
>

--0000000000001cb04505a4b0ce8b--