MIME-Version: 1.0
In-Reply-To: <CAAS2fgSVHfh2++JLCTOWVmMiwfqSkGgj4O+HR4wTYTXaZr6n9Q@mail.gmail.com>
References: <CAAS2fgSnfd++94+40vnSRxQfi9fk8N6+2-DbjVpssHxFvYveFQ@mail.gmail.com>
	<CAMnpzfphzviN9CqZaFa3P-U2OnHn56LYEtWtMktT1D37bPqvcQ@mail.gmail.com>
	<CAAS2fgSVHfh2++JLCTOWVmMiwfqSkGgj4O+HR4wTYTXaZr6n9Q@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Thu, 8 Feb 2018 23:29:58 -0800
Message-ID: <CAD5xwhiqcHjy2bFcCzNue+M92z3_QHZra801c6Kx7OBf=68sRw@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="089e08268c403fe64a0564c28082"
Subject: Re: [bitcoin-dev] Graftroot: Private and efficient surrogate
 scripts under the taproot assumption
Precedence: list

--089e08268c403fe64a0564c28082
Content-Type: text/plain; charset="UTF-8"

This might be unpopular because of bad re-org behavior, but I believe the
utility of this construction can be improved if we introduce functionality
that makes a script invalid after a certain time (correct me if I'm wrong,
I believe all current timelocks are valid after a certain time and invalid
before, this is the inverse).

Then you can exclude old delegates by timing/block height arguments, or
even pre-sign delegates for different periods of time (e.g., if this
happens in the next 100 blocks require y, before the next 1000 blocks but
after the first 100 require z, etc).


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

On Mon, Feb 5, 2018 at 11:58 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant <bitcoin-dev@rgrant.org> wrote:
> > Am I reading correctly that this allows unilateral key rotation (to a
> > previously unknown key), without invalidating the interests of other
> > parties in the existing multisig (or even requiring any on-chain
> > transaction), at the cost of storing the signed delegation?
>
> Yes, though I'd avoid the word rotation because as you note it doesn't
> invalidate the interests of any key, the original setup remains able
> to sign.  You could allow a new key of yours (plus everyone else) to
> sign, assuming the other parties agree... but the old one could also
> still sign.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">This might be unpopula=
r because of bad re-org behavior, but I believe the utility of this constru=
ction can be improved if we introduce functionality that makes a script<i> =
</i>invalid after a certain time (correct me if I&#39;m wrong, I believe al=
l current timelocks are valid after a certain time and invalid before, this=
 is the inverse).</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)">Then you can exclude old delegates by timing/=
block height arguments, or even pre-sign delegates for different periods of=
 time (e.g., if this happens in the next 100 blocks require y, before the n=
ext 1000 blocks but after the first 100 require z, etc).</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)"><br></div></div><div class=3D"gmail_extra"><br clear=
=3D"all"><div><br clear=3D"all"><div><div class=3D"gmail_signature" data-sm=
artmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitt=
er.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://tw=
itter.com/JeremyRubin" target=3D"_blank"></a></div></div></div>
</div>
<br><div class=3D"gmail_quote">On Mon, Feb 5, 2018 at 11:58 AM, Gregory Max=
well via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant &lt;<a href=3D"mailto:bitc=
oin-dev@rgrant.org">bitcoin-dev@rgrant.org</a>&gt; wrote:<br>
&gt; Am I reading correctly that this allows unilateral key rotation (to a<=
br>
&gt; previously unknown key), without invalidating the interests of other<b=
r>
&gt; parties in the existing multisig (or even requiring any on-chain<br>
&gt; transaction), at the cost of storing the signed delegation?<br>
<br>
</span>Yes, though I&#39;d avoid the word rotation because as you note it d=
oesn&#39;t<br>
invalidate the interests of any key, the original setup remains able<br>
to sign.=C2=A0 You could allow a new key of yours (plus everyone else) to<b=
r>
sign, assuming the other parties agree... but the old one could also<br>
still sign.<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<wbr>=
_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--089e08268c403fe64a0564c28082--