1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
Return-Path: <kanzure@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B072BD8B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Aug 2019 01:18:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com
[209.85.217.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4902082D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Aug 2019 01:18:34 +0000 (UTC)
Received: by mail-vs1-f53.google.com with SMTP id a186so4973565vsd.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 07 Aug 2019 18:18:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=0Ykk0A2wzzLAgxPVmppym1OV5aYyA5qU48W9JTJn2iw=;
b=blerPziY3Vr24b1RHZRgTIP1Hd2zhL6+PJYVavgR6PMf04mH8ZhxtpbN2G/KnMPI/g
8drBiIOLaiVqDkD2N6nR9R0midRq6vZZ4oP0GEEWBu5in5zz0eo1r/bE4D/L1/kNIPAb
lJZqTMZLx0d4+ufiLs8//l3hCXst+6h1Ltev7f1HrygaB8W5MsA4NRwu/roz3VvzNa/e
R7zD69KsXMHcPn0l/3vIOn45vFDuedRv6XBtNvDCvdiHulsemyd4NxZU/pf5uheSTMhH
l8yTEfllJJvL8N/g1r4dADlLcomMooU8LLIkWkOR76aHhsDWXdfV0lRKL2FgMjENzUG+
EOcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=0Ykk0A2wzzLAgxPVmppym1OV5aYyA5qU48W9JTJn2iw=;
b=l1ruLUekH0gIpIv8iVtMuSCNNFKQJ2c4tD87FB3tiINGZlSCS4re/c6epnO6QSDfmd
EW/fZPzzVN1VVBqc+PF3QnvQrAEMsB/3f+ueWC/2GaYxuy0QbQ8BWn+TZG+5/xDKZ0n0
oLMDgxchHs23B0pLJ0/ACiw8aKuHk3btWYmzs+LJ6KzEk/28WygwMzfaKWjyOwkEDqBv
SDUDFdeOcV+xOu60n9Ehp1Em6pBGIOJwmDLtRBKPRRBojikfGCU3L+p5Rwpn8LTZ09ph
ysMV8FOjRW2dLRUiO1KYZ1HWdq3l1RiLPPixjw0NDUCKtuK+XRswBkOsCP2Q+MVGHaoZ
2xIA==
X-Gm-Message-State: APjAAAXuecaTN8rLlXq2pMboboQuNbULmsqbL6NPkIQr+Lf3ywZnouXp
DixmwIrCo3h/1e589895oCwBWv4j8oEpozBFX/w=
X-Google-Smtp-Source: APXvYqygacCYDGyxw0ZNY/CmU7OYiip9M7Va957ZOGauzfKWOcQz3+jc9SjiCUfjN4spLl54fNMrMfMlQWuwZOYQsls=
X-Received: by 2002:a05:6102:3c5:: with SMTP id
n5mr8060829vsq.56.1565227113363;
Wed, 07 Aug 2019 18:18:33 -0700 (PDT)
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"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback
mechanisms
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Aug 2019 01:18:35 -0000
--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 <<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@pro=
tonmail.com</a>> 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">
> -=C2=A0 =C2=A0Re-vaulting transaction. This is where the magic happens=
. The re-vaulting<br>
>=C2=A0 =C2=A0 =C2=A0transaction is signed during transaction tree setup=
, before constructing the<br>
>=C2=A0 =C2=A0 =C2=A0delayed-spend transaction for the parent vault. The=
re-vaulting transaction is<br>
>=C2=A0 =C2=A0 =C2=A0broadcasted when someone wants to prevent a coin wi=
thdrawal during the public<br>
>=C2=A0 =C2=A0 =C2=A0observation delay period. The re-vaulting transacti=
on spends the delayed-spend<br>
>=C2=A0 =C2=A0 =C2=A0transaction outputs. It has a single output with a =
script created by running<br>
>=C2=A0 =C2=A0 =C2=A0the entire vault setup function again. Hence, when =
the re-vaulting transaction<br>
>=C2=A0 =C2=A0 =C2=A0is confirmed, all of the coins go back into a new i=
dentically-configured vault<br>
>=C2=A0 =C2=A0 =C2=A0instead of being relinquished through the delayed-s=
pend transaction timeout for<br>
>=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 "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. 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 <<a href=
=3D"mailto:dustinpaystaxes@gmail.com">dustinpaystaxes@gmail.com</a>> 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'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--
|
