MIME-Version: 1.0
References: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
	<japBRkZAIadJ9g0xOFbixrzJv4hk67ONKrjO6QuWARaeMtdIhNb7rDT_8NroxDCIVKFTjcAqukSt4sApPsJ0U9ori3bkCKmEW_jJMcXWMqc=@protonmail.com>
In-Reply-To: <japBRkZAIadJ9g0xOFbixrzJv4hk67ONKrjO6QuWARaeMtdIhNb7rDT_8NroxDCIVKFTjcAqukSt4sApPsJ0U9ori3bkCKmEW_jJMcXWMqc=@protonmail.com>
From: Bryan Bishop <kanzure@gmail.com>
Date: Wed, 7 Aug 2019 20:16:42 -0500
Message-ID: <CABaSBay8hBkStv5rLPhHMmwnGjMhEjwdR_LeovQ8GMqRg0vxMA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	Dustin Dettmer <dustinpaystaxes@gmail.com>, 
	Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000015bfc5058f90d61d"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback
	mechanisms
Precedence: list

--00000000000015bfc5058f90d61d
Content-Type: text/plain; charset="UTF-8"

Replying to two emails below.

On Wed, Aug 7, 2019 at 7:27 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> > -   Re-vaulting transaction. This is where the magic happens. The
> re-vaulting
> >     transaction is signed during transaction tree setup, before
> constructing the
> >     delayed-spend transaction for the parent vault. The re-vaulting
> transaction is
> >     broadcasted when someone wants to prevent a coin withdrawal during
> the public
> >     observation delay period. The re-vaulting transaction spends the
> delayed-spend
> >     transaction outputs. It has a single output with a script created by
> running
> >     the entire vault setup function again. Hence, when the re-vaulting
> transaction
> >     is confirmed, all of the coins go back into a new
> identically-configured vault
> >     instead of being relinquished through the delayed-spend transaction
> timeout for
> >     hot wallet key signing.
>
> As transactions need to be signed in reverse order, it seems to me that
> there is a practical limit in the number of times a vault can be used.
> Basically, the number of times we run the vault setup function is the
> limit on number of re-vaultings possible.
>
> Is my understanding correct?
>

Yes, that is correct. When setting up the vault, plan it "all the way to
the end" like next 100+ years. With exponential backoff on the relative
timelock values, the total number of pre-signed transactions isn't really
that high. With a few thousand pre-signed transactions (more than enough),
you can have high resolution timelocks well into the future.

On Wed, Aug 7, 2019 at 4:19 PM Dustin Dettmer <dustinpaystaxes@gmail.com>
wrote:

> Does revaulting vault up with the same keys, or new ones?
> Are they new derivation paths on the same key?
>

Honestly, no idea. The answer to that might depend on each individual vault
user. If the user doesn't want to deal with the expense of managing a bunch
of unique keys and other data, then it might make more sense to use the
same values and have a small blob that has to be stored for a long time,
rather than many different blobs stored in different places to deal with.

- Bryan
http://heybryan.org/

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

<div dir=3D"ltr"><div>Replying to two emails below.</div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Aug 7, 2019 at 7=
:27 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@pro=
tonmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">
&gt; -=C2=A0 =C2=A0Re-vaulting transaction. This is where the magic happens=
. The re-vaulting<br>
&gt;=C2=A0 =C2=A0 =C2=A0transaction is signed during transaction tree setup=
, before constructing the<br>
&gt;=C2=A0 =C2=A0 =C2=A0delayed-spend transaction for the parent vault. The=
 re-vaulting transaction is<br>
&gt;=C2=A0 =C2=A0 =C2=A0broadcasted when someone wants to prevent a coin wi=
thdrawal during the public<br>
&gt;=C2=A0 =C2=A0 =C2=A0observation delay period. The re-vaulting transacti=
on spends the delayed-spend<br>
&gt;=C2=A0 =C2=A0 =C2=A0transaction outputs. It has a single output with a =
script created by running<br>
&gt;=C2=A0 =C2=A0 =C2=A0the entire vault setup function again. Hence, when =
the re-vaulting transaction<br>
&gt;=C2=A0 =C2=A0 =C2=A0is confirmed, all of the coins go back into a new i=
dentically-configured vault<br>
&gt;=C2=A0 =C2=A0 =C2=A0instead of being relinquished through the delayed-s=
pend transaction timeout for<br>
&gt;=C2=A0 =C2=A0 =C2=A0hot wallet key signing.<br>
<br>
As transactions need to be signed in reverse order, it seems to me that the=
re is a practical limit in the number of times a vault can be used.<br>
Basically, the number of times we run the vault setup function is the limit=
 on number of re-vaultings possible.<br>
<br>
Is my understanding correct?<br></blockquote><div><br>Yes, that is correct.=
 When setting up the vault, plan it &quot;all the way to the end&quot; like=
 next 100+ years. With exponential backoff on the relative timelock values,=
 the total number of pre-signed transactions isn&#39;t really that high. Wi=
th a few thousand pre-signed transactions (more than enough), you can have =
high resolution timelocks well into the future.<br><br><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Wed, Aug 7, 2019 at 4:19 PM Dustin Dettmer &lt;<a href=
=3D"mailto:dustinpaystaxes@gmail.com">dustinpaystaxes@gmail.com</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div di=
r=3D"auto">Does revaulting vault up with the same keys, or new ones?</div><=
/div><div dir=3D"auto">Are they new derivation paths on the same key?</div>=
</blockquote><br>Honestly, no idea. The answer to that might depend on each=
 individual vault user. If the user doesn&#39;t want to deal with the expen=
se of managing a bunch of unique keys and other data, then it might make mo=
re sense to use the same values and have a small blob that has to be stored=
 for a long time, rather than many different blobs stored in different plac=
es to deal with.<br><br></div></div><div dir=3D"ltr" class=3D"gmail_signatu=
re">- Bryan<br><a href=3D"http://heybryan.org/" target=3D"_blank">http://he=
ybryan.org/</a><br></div></div>

--00000000000015bfc5058f90d61d--