MIME-Version: 1.0
References: <CAPg+sBgKY-nmL=x+LVubtB0fFBAwd-1CDHT7zhidX8p9DLSGyg@mail.gmail.com>
	<CAPg+sBh4CESPV_5TpPn0H3Zpv2Ump_0txxS63W_S2f3Lxezq1A@mail.gmail.com>
	<CAAS2fgRXYtTyqqQp8Ehs_q_KsT7usA+vYSmngStnndd1rWNVNw@mail.gmail.com>
In-Reply-To: <CAAS2fgRXYtTyqqQp8Ehs_q_KsT7usA+vYSmngStnndd1rWNVNw@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 24 May 2018 11:44:16 +0200
Message-ID: <CAAt2M1_Kc5O062r2KOh2VWMUOv6itegvXwg87Ox+1Y2=mXMw8w@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000648c96056cf07ff2"
Subject: Re: [bitcoin-dev] Should Graftroot be optional?
Precedence: list

--000000000000648c96056cf07ff2
Content-Type: text/plain; charset="UTF-8"

Den tor 24 maj 2018 04:08Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> skrev:

>
> My understanding of the question is this:
>
> Are there any useful applications which would be impeded if a signing
> party who could authorize an arbitrary transaction spending a coin had
> the option to instead sign a delegation to a new script?
>
> The reason this question is interesting to ask is because the obvious
> answer is "no":  since the signer(s) could have signed an arbitrary
> transaction instead, being able to delegate is strictly less powerful.
> Moreover, absent graftroot they could always "delegate" non-atomically
> by spending the coin with the output being the delegated script that
> they would have graftrooted instead.
>
> Sometimes obvious answers have non-obvious counter examples, e.g.
> Andrews points related to blindsigning are worth keeping in mind.
>

As stated above by Wuille this seems to not be a concern for typical P2SH
uses, but my argument here is simply that in many cases, not all
stakeholders in a transaction will hold one of the private keys required to
sign. And such stakeholders would want a guarantee that the original script
is followed as promised.

I agree that such flags typically wouldn't have a meaningful effect for
funds from non-P2SH addresses, since the entire transaction / script could
be replaced by the very same keyholders.

I'm not concerned by the ability to move funds to an address with the new
rules that you'd otherwise graftroot in, only that you can provide a
transparent guarantee that you ALSO follow the original script as promised.
What happens *after* you have followed the original script is unrelated,
IMHO.

>

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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
Den tor 24 maj 2018 04:08Gregory Maxwell via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"norefer=
rer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; skrev:</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<br>
My understanding of the question is this:<br>
<br>
Are there any useful applications which would be impeded if a signing<br>
party who could authorize an arbitrary transaction spending a coin had<br>
the option to instead sign a delegation to a new script?<br>
<br>
The reason this question is interesting to ask is because the obvious<br>
answer is &quot;no&quot;:=C2=A0 since the signer(s) could have signed an ar=
bitrary<br>
transaction instead, being able to delegate is strictly less powerful.<br>
Moreover, absent graftroot they could always &quot;delegate&quot; non-atomi=
cally<br>
by spending the coin with the output being the delegated script that<br>
they would have graftrooted instead.<br>
<br>
Sometimes obvious answers have non-obvious counter examples, e.g.<br>
Andrews points related to blindsigning are worth keeping in mind.<br></bloc=
kquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">As stated =
above by Wuille this seems to not be a concern for typical P2SH uses, but m=
y argument here is simply that in many cases, not all stakeholders in a tra=
nsaction will hold one of the private keys required to sign. And such stake=
holders would want a guarantee that the original script is followed as prom=
ised.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">I agree that=
 such flags typically wouldn&#39;t have a meaningful effect for funds from =
non-P2SH addresses, since the entire transaction / script could be replaced=
 by the very same keyholders.=C2=A0</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">I&#39;m not concerned by the ability to move funds to an addres=
s with the new rules that you&#39;d otherwise graftroot in, only that you c=
an provide a transparent guarantee that you ALSO follow the original script=
 as promised. What happens *after* you have followed the original script is=
 unrelated, IMHO.=C2=A0</div><div dir=3D"auto"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--000000000000648c96056cf07ff2--