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
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E99DC137A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Feb 2018 07:43:20 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu
[18.7.68.36])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 05BE3F6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Feb 2018 07:43:19 +0000 (UTC)
X-AuditID: 12074424-cc9ff700000034a6-8e-5a7d5115ea0c
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])
(using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP
id 7F.05.13478.5115D7A5; Fri, 9 Feb 2018 02:43:18 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11])
by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w197hFnq000973
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Feb 2018 02:43:15 -0500
Received: from mail-yw0-f170.google.com (mail-yw0-f170.google.com
[209.85.161.170]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w197hDLx006790
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Feb 2018 02:43:14 -0500
Received: by mail-yw0-f170.google.com with SMTP id b129so4508263ywa.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 08 Feb 2018 23:43:14 -0800 (PST)
X-Gm-Message-State: APf1xPBdKZjsjiAF5HyrV6vcXoeseNQqWllqd1sp3pWPiN1MiA3TUkRS
SvAA2k6PvCP0uFcN0L52/JYYu4XxmiOYCBdO6dc=
X-Google-Smtp-Source: AH8x226GTwWZbuaCNCtb8ON9nUssWyrcvZC1FCF1l8IGrkHoIBEiCvkclmiBOfRYNI3weM9aD6DJAcqEK2Uszfqtp3s=
X-Received: by 10.37.133.133 with SMTP id x5mr1066255ybk.367.1518162192894;
Thu, 08 Feb 2018 23:43:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.235.138 with HTTP; Thu, 8 Feb 2018 23:42:52 -0800 (PST)
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
X-Gmail-Original-Message-ID: <CAD5xwhgYAN9RFWBfJjr7BMeZM1SWbKtuTEknzBqZnpaR-ihsGg@mail.gmail.com>
Message-ID: <CAD5xwhgYAN9RFWBfJjr7BMeZM1SWbKtuTEknzBqZnpaR-ihsGg@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="089e0832c24838160d0564c2ae5c"
X-Brightmail-Tracker: H4sIAAAAAAAAA01SbUhTURjm7G7ubO7acX7saBq1JCrRjNRKSoT6IZXkRCuWUFd3c6PtKvfO
T5JMyB+aKUiigzAVCz/K0FIzV7J+KWRaEAVzioWZklmaWAZ2jxe1Pw/PeZ/nfd6Xcw6ktOOK
YGjh7CzPMVa9l1quVQWERwQaio1REx0BR0rnjieAxNWVGpAMjOpjJtZqyWP5A/GX1ebupVZF
zpu4gol3v+Ul4O6hcqCCGEXjha5mRTlQQy1qluGBtl5KOrgBfljpAMSlRYsy3DRtkIRGgAee
TwKpPR93Oj1KifP4Z/sKJXEBV4zWeRFOI188VP9ZLgWdwr+GK2SEq5ABV/XMyzZHT8w9EJsh
9EI78MKfGOKRozBc6n4pI2WMGOz+foFQGiXjwQmGOPyQFd9wflqf6o9C8Ot5z3oihRoAbl97
ryR+Cp3Bna+Kq4G/47+FHFsKKVNoH77Zu6qU+F58z/0CSDwc32+co+4BRRsINdmKImyMxSqw
mRFCJsNxLB9xONJmsUeyptwuQN5DeTKsD1TcOu0CCAK9hq5Ov2bUKpg8odDmAkFQpg+guyvF
kk9GtqnQzAjmS3yulRVcAENK70+PJhUbtbSJKSxi+ewNaTuU63V0YnS4UYuyGDt7lWVzWH5D
DYFQj+ndyWKjL89msQVXLFb7liyDKhKuEcOPEg8t5DA2wZIl6cPgPFxY9JRRcNkxKWJ1A8Fp
J8Hl2i8iPpn6KuLgOn6YmSujtHIum2ODdbSOxCESZ87lNieSXzmW1tg2C3TiBfjR18+KLo34
ZzdnzorryMR1xhPW17EzW1JwCbBE0QH2ztjK1EB5lLezyrcmP2vKPjlaPtJdyj1b80QvXfTZ
5ixTnAvLUO480f+2W43jAn+glMZHPWuhvZqMINhhjedG0ltvN4WMZ8yYak2uQptjjzIl7fFI
zOxfmBD/0eVOrKuPxan9+WO7vq21qA1Dfpl9LXeGvZ8mtTQU6eWCmTm4n+IF5h9MVc+VcAMA
AA==
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_MED,T_RP_MATCHES_RCVD 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] Graftroot: Private and efficient surrogate
scripts under the taproot assumption
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: Fri, 09 Feb 2018 07:43:21 -0000
--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'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'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'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"><<a href=3D"mailto:jlrubin@mit.edu" target=3D"_blank">jlru=
bin@mit.edu</a>></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'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"><<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoun=
dation.org</a>></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 <<a href=3D"mailto:bitcoin-dev@=
rgrant.org" target=3D"_blank">bitcoin-dev@rgrant.org</a>> wrote:<br>
> Am I reading correctly that this allows unilateral key rotation (to a<=
br>
> previously unknown key), without invalidating the interests of other<b=
r>
> parties in the existing multisig (or even requiring any on-chain<br>
> transaction), at the cost of storing the signed delegation?<br>
<br>
</span>Yes, though I'd avoid the word rotation because as you note it d=
oesn'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--
|
