MIME-Version: 1.0
References: <CAPg+sBgKY-nmL=x+LVubtB0fFBAwd-1CDHT7zhidX8p9DLSGyg@mail.gmail.com>
In-Reply-To: <CAPg+sBgKY-nmL=x+LVubtB0fFBAwd-1CDHT7zhidX8p9DLSGyg@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 24 May 2018 00:06:31 +0200
Message-ID: <CAAt2M1-DTzKct-NU9TotxDve8vLe5HFYxHZbq+t_A69C1nL-PA@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000fc6efd056ce6bfe4"
Subject: Re: [bitcoin-dev] Should Graftroot be optional?
Precedence: list

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

Den tis 22 maj 2018 20:18Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> skrev:

> Hello all,
>
> Given the recent discussions about Taproot [1] and Graftroot [2], I
> was wondering if a practical deployment needs a way to explicitly
> enable or disable the Graftroot spending path. I have no strong
> reasons why this would be necessary, but I'd like to hear other
> people's thoughts.
>

I'm definitely in favor of the suggestion of requiring a flag to allow the
usage of these in a transaction, so that you get to choose in advance if
the script will be static or "editable".

Consider for example a P2SH address for some fund, where you create a
transaction in advance. Even if the parties involved in signing the
transaction would agree (collude), the original intent of this particular
P2SH address may be to hold the fund accountable by enforcing some given
rules by script. To be able to circumvent the rules could break the purpose
of the fund.

The name of the scheme escapes me, but this could include a variety of
proof-requiring committed transactions, like say a transaction that will
pay out if you can provide a proof satisfying some conditions such as
embedding the solution to a given problem. This fund would only be supposed
to pay out of the published conditions are met (which may include an expiry
date).

To then use taproot / graftroot to withdraw the funds despite this
possibility not showing in the published script could be problematic.

I'm simultaneously in favor of being able to have scripts where the usage
of taproot / graftroot isn't visible in advance, but it must simultaneously
be possible to prove a transaction ISN'T using it.

>

--000000000000fc6efd056ce6bfe4
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 tis 22 maj 2018 20:18Pieter Wuille via bitcoin-dev &lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; skrev:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
Given the recent discussions about Taproot [1] and Graftroot [2], I<br>
was wondering if a practical deployment needs a way to explicitly<br>
enable or disable the Graftroot spending path. I have no strong<br>
reasons why this would be necessary, but I&#39;d like to hear other<br>
people&#39;s thoughts.<br></blockquote></div></div><div dir=3D"auto"><br></=
div><div dir=3D"auto"><span style=3D"font-family:sans-serif">I&#39;m defini=
tely in favor of the suggestion of requiring a flag to allow the usage of t=
hese in a transaction, so that you get to choose in advance if the script w=
ill be static or &quot;editable&quot;.=C2=A0</span><br></div><div dir=3D"au=
to"><span style=3D"font-family:sans-serif"><br></span></div><div dir=3D"aut=
o"><font face=3D"sans-serif">Consider for example a P2SH address for some f=
und, where you create a transaction in advance. Even if the parties involve=
d in signing the transaction would agree (collude), the original intent of =
this particular P2SH address may be to hold the fund accountable by enforci=
ng some given rules by script. To be able to circumvent the rules could bre=
ak the purpose of the fund.=C2=A0</font></div><div dir=3D"auto"><font face=
=3D"sans-serif"><br></font></div><div dir=3D"auto"><font face=3D"sans-serif=
">The name of the scheme escapes me, but this could include a variety of pr=
oof-requiring committed transactions, like say a transaction that will pay =
out if you can provide a proof satisfying some conditions such as embedding=
 the solution to a given problem. This fund would only be supposed to pay o=
ut of the published conditions are met (which may include an expiry date).=
=C2=A0</font></div><div dir=3D"auto"><font face=3D"sans-serif"><br></font><=
/div><div dir=3D"auto"><font face=3D"sans-serif">To then use taproot / graf=
troot to withdraw the funds despite this possibility not showing in the pub=
lished script could be problematic.=C2=A0</font></div><div dir=3D"auto"><fo=
nt face=3D"sans-serif"><br></font></div><div dir=3D"auto"><font face=3D"san=
s-serif">I&#39;m simultaneously in favor of being able to have scripts wher=
e the usage of taproot / graftroot isn&#39;t visible in advance, but it mus=
t simultaneously be possible to prove a transaction ISN&#39;T using it.=C2=
=A0</font></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
</blockquote></div></div></div>

--000000000000fc6efd056ce6bfe4--