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
|
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 1589F17ED
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Feb 2018 07:30:32 +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 3C918F6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Feb 2018 07:30:31 +0000 (UTC)
X-AuditID: 12074424-cc9ff700000034a6-99-5a7d4e13d220
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])
(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 4F.C4.13478.41E4D7A5; Fri, 9 Feb 2018 02:30:29 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11])
by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w197UOag026038
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Feb 2018 02:30:25 -0500
Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com
[209.85.161.174]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w197ULVt001997
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Feb 2018 02:30:23 -0500
Received: by mail-yw0-f174.google.com with SMTP id m84so4492766ywd.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 08 Feb 2018 23:30:22 -0800 (PST)
X-Gm-Message-State: APf1xPBx6MZzPObC4ePGqZrbswww0QnlgXYGMG3YxI7CSx4es+OtGkwF
ggMtIj1PY6ep75AwS9aS4JrpNT1djSud+kNYxu4=
X-Google-Smtp-Source: AH8x226ULtc0WHpFGI/WUKrP82gQa7dcDC7l2pBxFR3GVlV1/phO8sXMNQXMNmN8HhMMCa/7gdza52TUJWsct2MG00w=
X-Received: by 10.37.129.210 with SMTP id n18mr1099370ybm.413.1518161421655;
Thu, 08 Feb 2018 23:30:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.235.138 with HTTP; Thu, 8 Feb 2018 23:29:58 -0800 (PST)
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
X-Gmail-Original-Message-ID: <CAD5xwhiqcHjy2bFcCzNue+M92z3_QHZra801c6Kx7OBf=68sRw@mail.gmail.com>
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"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHKsWRmVeSWpSXmKPExsUixG6noivqVxtlcO+0uEXTa1sHRo/fPyYz
BjBGcdmkpOZklqUW6dslcGVsPbefvWCHesWLFZtZGxgXKHUxcnJICJhI7Dn1jbmLkYtDSGAx
k8SVy00sEM4dRom1N+YyglQJCXxmkjj4iw/CXsAoceoNN0R3ucT1K52sEHaRxNxfk9gh7BKJ
ZX+fsIDYvAKCEidnQthCAl4Sexf8ZAOxOQUCJT7+X8EKt+zptnVAzRwcbAJyEh9+mYLUsAio
SBx4upcJYmaixLV7LYwgJbwCARKne5NAwsICORKNex8zg9giAoUSi3/3gtnMAuoSP84eZ4Ww
fSQ+TT7OPoFRZBaSi2YhSUHYmhKt239D2RoSC+7sY4SwtSWWLXzNvICRdRWjbEpulW5uYmZO
cWqybnFyYl5eapGuuV5uZoleakrpJkZwhLio7GDs7vE+xCjAwajEwzshpiZKiDWxrLgy9xCj
JAeTkijv5l6gEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHePJPaKCHelMTKqtSifJiUNAeLkjiv
h4l2lJBAemJJanZqakFqEUxWhoNDSYJ3hi9Qo2BRanpqRVpmTglCmomDE2Q4D9DwpSA1vMUF
ibnFmekQ+VOM4RwfPt9rY+b4NusBkJwwH0Q+2wsiv017DiS3PHoJJA+AyRsvXrcxC7Hk5eel
SonzOoOMEwAZl1GaB7cRlCwvhi5c94pRHBgAwrxbfICqeICJFm7nK6BzmIDOuesAdk5JIkJK
qoHRau/eiUsOWHOELreR7Dnp7cy4Jm/W68IbWTUBX402eTL5rsxbqRsZenlllKHiDkXDR/Ly
O0zvn9yRqM2+rDdsc8gSu4hfHFye+jWPJuSUHJs6T7x4r9Gi8OnbzQTs6h8pnbD91/jzTuOU
jsOfEl59cxPg1tnRqcrw0+BV8CKHb8dPzvnixT9DiaU4I9FQi7moOBEAoZdJlXEDAAA=
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
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:30:32 -0000
--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'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"><<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio=
n.org</a>></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 <<a href=3D"mailto:bitc=
oin-dev@rgrant.org">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"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--
|
