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

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

I'm also highly interested in the case where you sign a delegate
conditional on another delegate being signed, e.g. a bilateral agreement.

In order for this to work nicely you also need internally something like
segwit so that you can refer to one side's delegation by a signature-stable
identity.

I don't have a suggestion of a nice way to do this at this time, but will
stew on it.

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

On Thu, Feb 8, 2018 at 11:29 PM, Jeremy <jlrubin@mit.edu> wrote:

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

--089e0832c24838160d0564c2ae5c
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)">I&#39;m also highly in=
terested in the case where you sign a delegate conditional on another deleg=
ate being signed, e.g. a bilateral agreement.</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">In order for this=
 to work nicely you also need internally something like segwit so that you =
can refer to one side&#39;s delegation by a signature-stable identity.<br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)">I don&#39;t have a suggestion of a nice way to do this at this =
time, but will stew on it.<br></div></div><div class=3D"gmail_extra"><br cl=
ear=3D"all"><div><div class=3D"gmail_signature" data-smartmail=3D"gmail_sig=
nature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" =
target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubi=
n" target=3D"_blank"></a></div></div></div>
<br><div class=3D"gmail_quote">On Thu, Feb 8, 2018 at 11:29 PM, Jeremy <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:jlrubin@mit.edu" target=3D"_blank">jlru=
bin@mit.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)">This might be unpopular becau=
se of bad re-org behavior, but I believe the utility of this construction c=
an be improved if we introduce functionality that makes a script<i> </i>inv=
alid after a certain time (correct me if I&#39;m wrong, I believe all curre=
nt timelocks are valid after a certain time and invalid before, this is the=
 inverse).</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)">Then you can exclude old delegates by timing/block h=
eight 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 100=
0 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:small;co=
lor: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"m_-5054630071886368334gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a h=
ref=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div><=
/div>
</div><div><div class=3D"h5">
<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.<wbr>linuxfoun=
dation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On=
 Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant &lt;<a href=3D"mailto:bitcoin-dev@=
rgrant.org" target=3D"_blank">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"m_-5054630071886368334HOEnZb"><div class=3D"m_-50546300718863=
68334h5">______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>

--089e0832c24838160d0564c2ae5c--