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
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
|
Return-Path: <guido.dassori@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id CC0BFC000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Mar 2021 13:33:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 7EE7840EAD
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Mar 2021 13:33:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id q0-jAOTyTByu
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Mar 2021 13:33:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com
[IPv6:2607:f8b0:4864:20::52d])
by smtp4.osuosl.org (Postfix) with ESMTPS id D2A8C40EAA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Mar 2021 13:33:18 +0000 (UTC)
Received: by mail-pg1-x52d.google.com with SMTP id v2so14642232pgk.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Mar 2021 06:33:18 -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;
bh=4Jr0vPnF8+IvxInSX+OsJJ7ICZrYcgrkySjDasNrowU=;
b=E6/vPnqm8qaKnQLqE3MlxuWGN3ktZm/cJadXxkghxWsQLsF6MMrSwQ/++LCn6KjO6N
cxHFWdgv//kCAAT5MlVzwfiruKd8IST+iorOf74tz0iXzTuTKHo8jDkkwy0BTaKwBKxt
nCARpeDvztJLaNA6cqZJaAaa5wiVxmHdkMx0ZG0ZLV27FFM8wPweYnxJjfP6hb9O44sV
rlj/9UMRj07DuD4JVEol/ZA1ZeioCVxMlwSFV4OYXw1Vn+nQG0nIE0cFMbEPIdHekDF7
Oxoj/wXxMcnxhfBDs0HnPZdDO/d+sLnpk6j3JXszzVMhviBc2O2V+sB16p1AvXJETANY
kKXQ==
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;
bh=4Jr0vPnF8+IvxInSX+OsJJ7ICZrYcgrkySjDasNrowU=;
b=jTQPQNo+9rgV0np0tSWM94xp7+GMTA3khB2oHH6FRTHEghjqtbv9KxbWfpoTPMsEbn
brrw//wVBB23fAY1d698RbsC6OVQyLd81g4J+ZePkp0Qd/4yRASR4Ntd7QdUUSuWDM5a
ik3M/U9NUJ6jPDIQEksI6wOA2igyul6oRgMrmCRO+GfnDuvogOVzp666G+eLIw5UPYFQ
ZeVAofI7s+fRLadsukyMRRkxB/9b+8tEdTUcNHePRMcrXNVvq4I9MD8584gfL5f/n+g0
2X2B7OJBCzt9HwoXf89EcOaR+OV+arLP9p9U4XoninSxemQdZWkHjsXDWwkKNpxvLKKL
/Bww==
X-Gm-Message-State: AOAM532gNaDIZ9Y6pOe+G/qzLFrAqe3ke3qUIij5EVJV/LUMRQHEK4rR
VeTQDGnVePwtfDbQFpgDy3kOCQV3gfcOrShfZrU=
X-Google-Smtp-Source: ABdhPJxTMRgPeHU+Ym+n1tF4HmjX6+hzGJ7xzeasJgdDokQuBmZpW+JzgeGEusJNjgqChWr+YYFPkBW7s9iu0U+rrm8=
X-Received: by 2002:a62:e708:0:b029:1f8:c092:ff93 with SMTP id
s8-20020a62e7080000b02901f8c092ff93mr3236633pfh.21.1616592798156; Wed, 24 Mar
2021 06:33:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhhC1Y13p7KazfUOXFZ5vi5MA9EQ-scyafv4aNkjskoXBg@mail.gmail.com>
<plFEi9xoSnZ0TDJ7wH2dJx1F727FCSBrPsa2-26AXtveHKolt9bzTE1tiGIoPSjhgBfToVID2YHEaMGwwVU5dZ3Sozmz9UO-6HvbEDmm67I=@protonmail.com>
<CAD5xwhhMjsYMRebN4Td614qOyAey24h7vQAjZjP_ETzvXJQBLw@mail.gmail.com>
<_SJunY4b2FhUkCj49-C_D7Uj1VYlS8qqZuO2-NIAEAIkCIfWEWVVgx-pNN0ZXlujGKUiU_hfcV-aq9yK6LHjHoK_5E0pYncVWtW99regZnE=@protonmail.com>
<CAD5xwhj73Uq6j_Wu2e6-4VA_-=50mwK4G-Mf24mC87CFvF-LnA@mail.gmail.com>
In-Reply-To: <CAD5xwhj73Uq6j_Wu2e6-4VA_-=50mwK4G-Mf24mC87CFvF-LnA@mail.gmail.com>
From: Guido Dassori <guido.dassori@gmail.com>
Date: Wed, 24 Mar 2021 14:33:07 +0100
Message-ID: <CAJ_Ap8g6-TR0k7g9-KbxW-4N92kyL6yktVN2jboVNo8sPj7a9w@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007b09cd05be48574a"
X-Mailman-Approved-At: Wed, 24 Mar 2021 14:19:41 +0000
Subject: Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing
rules, no fork required
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Wed, 24 Mar 2021 13:33:22 -0000
--0000000000007b09cd05be48574a
Content-Type: text/plain; charset="UTF-8"
Hello Jeremy,
I find this a very interesting idea :-)
Actually I implemented something similar a bit ago in a POC, available on
GH since a while: https://github.com/gdassori/btc-bargain
At this very moment we're working to make it production ready and cut our
transaction fees (we run a 2-on-3 wallet with buy\sell features) down to
~5%.
Guido
https://twitter.com/khs9ne
Il giorno mer 17 mar 2021 alle ore 07:30 Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> ha scritto:
> ZmnSCPxj,
>
> The chief reason to use SIGHASH_NONE (or SIGHASH_SINGLE for partial funds
> delegations) is to make it so that the delegator can dynamically choose
> things like a change output. Otherwise you need to know exactly what you
> want beforehand.
>
> I'd note that you can also achieve a decent amount of scripting capability
> for fully pre-signed transactions using layered encryption. E.g., given
> script Checksig(Alice) and Checksig(Bob), you can delegate to
> 2 of CheckMulti(Carol, Dave, Eve) by (for example) encrypting either a
> presigned txn or the actual sk's themselves with enc(Carol, enc(Dave, m)),
> enc(Carol, enc(Eve, m)), enc(Dave, enc(Eve, m)). This allows you to
> post-hoc delegate a presigned (or the keys -- which may or may not be safe
> if they are from a HD wallet mind you). You can also do a variant of
> timelock encryption by encrypting m using a verifiable delay function (this
> actually permits a new kind of relative lock, depending on where you layer
> the VDF enc, which would be N seconds from when the two parties agree to
> decrypt). The general protocol can also be optimized by giving Carol
> enc(Dave, m) and enc(Eve) but then you have to have a confidential channel
> to each delegate. You can also do a ZKCP type thing if you prove that a txn
> matching a specific format is encrypted with the preimage to a hash.
> There's a lot you can do as improvement on simple "hand the key" -- this
> sounds kinda similar to scriptless scripts?
>
> W.r.t. privacy, it certainly is a hit. But I think in situations where
> privacy is a goal, then the delegation can contact the original signer and
> ask to cooperate. However in some circumstances that won't be viable given
> access to keys or whatnot. I would suggest in these cases that you can do a
> hybrid: delegate to a script and provide a default sighash_all txn, and a
> modifiable sighash_none/single. Then the delegates can decide what is best
> to use and optimistically get the originals to sign off.
>
> Interestingly, there is a subset of cases where it is desirable to have
> privacy *from the original script holder*. Conceivably the tx does need to
> be public at some point, but for interest, once delegated to from S to S',
> S' could show a signature covering a txn hash from S', and request that S
> sign it. S' can reveal partial information -- e.g., which inputs are being
> spent, but not which outputs are being created. Maybe not super useful, but
> it is interesting to note of course.
>
> Best,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Tue, Mar 16, 2021 at 1:36 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
>> Good morning Jeremy,
>>
>> Thank you.
>>
>> Assuming only keys, an easier way of delegating would be simply to give a
>> copy of the privkey outright to the delegatee.
>>
>> However, an advantage of this technique you described is that the
>> delegator can impose additional restrictions that are programmable via any
>> SCRIPT, an ability that merely handing over the privkey cannot do.
>> Thus the technique has an ability that mere handover cannot achieve.
>>
>> If the delegatee is a known single entity, and S is simply the delegatee
>> key plus some additional restrictions, it may be possible to sign with
>> `SIGHASH_ALL` a transaction that spends A and D, and outputs to a singlesig
>> of the delegatee key.
>> This would avoid the use of `SIGHASH_NONE`, for a mild improvement in
>> privacy.
>> The output would still allow the delegatee to dispose of the funds by its
>> unilateral decision subject to the fulfillment of the script S (at the cost
>> of yet another transaction).
>> On the other hand, if S is unusual enough, the enhanced privacy may be
>> moot (the S already marks the transaction as unusual), so this variation
>> has little value.
>>
>> In terms of offchain technology, if the delegator remains online, the
>> delegatee may present a witness satisfying S to the delegator, and ask the
>> delegator to provide an alternate transaction that spends A directly
>> without spending D and outputs to whatever the delegatee wants.
>> The delegator cannot refuse since the delegatee can always use the
>> `SIGHASH_NONE` signature and spend to whatever it decides provided it can
>> present a witness satisfying S.
>> This is basically a typical "close transaction" for layer 2 technology.
>> On the other hand, one generalized use-case for delegation would be if
>> the delegator suspects it may not be online or able to sign with the
>> delegator key, so this variation has reduced value as well.
>>
>> Regards,
>> ZmnSCPxj
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000007b09cd05be48574a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello Jeremy,=C2=A0<div><br></div><div>I find this a very =
interesting idea :-)<div>Actually I implemented something similar a bit ago=
in a POC, available on GH since a while: <a href=3D"https://github.com/gda=
ssori/btc-bargain">https://github.com/gdassori/btc-bargain</a>=C2=A0</div><=
div><br></div><div>At this very moment we're working to make it product=
ion ready and cut our transaction fees (we run a 2-on-3 wallet with buy\sel=
l features) down to ~5%.</div><div><br></div></div><div>Guido</div><div><a =
href=3D"https://twitter.com/khs9ne">https://twitter.com/khs9ne</a></div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Il =
giorno mer 17 mar 2021 alle ore 07:30 Jeremy via bitcoin-dev <<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfound=
ation.org</a>> ha scritto:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)">ZmnSCPxj,</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,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;fon=
t-size:small;color:rgb(0,0,0)">The chief reason to use SIGHASH_NONE (or SIG=
HASH_SINGLE for partial funds delegations) is to make it so that the delega=
tor can dynamically choose things like a change output. Otherwise you need =
to know exactly what you want beforehand.<br></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)">I'd note that=
you can also achieve a decent amount of scripting capability for fully pre=
-signed transactions using layered encryption. E.g., given script Checksig(=
Alice) and Checksig(Bob), you can delegate to <br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">2 of CheckMulti(Carol, Dave, Eve) by (for example) encrypt=
ing either a presigned txn or the actual sk's themselves with enc(Carol=
, enc(Dave, m)), enc(Carol, enc(Eve, m)), enc(Dave, enc(Eve, m)). This allo=
ws you to post-hoc delegate a presigned (or the keys -- which may or may no=
t be safe if they are from a HD wallet mind you). You can also do a variant=
of timelock encryption by encrypting m using a verifiable delay function (=
this actually permits a new kind of relative lock, depending on where you l=
ayer the VDF enc, which would be N seconds from when the two parties agree =
to decrypt). The general protocol can also be optimized by giving Carol enc=
(Dave, m) and enc(Eve) but then you have to have a confidential channel to =
each delegate. You can also do a ZKCP type thing if you prove that a txn ma=
tching a specific format is encrypted with the preimage to a hash. There=
9;s a lot you can do as improvement on simple "hand the key" -- t=
his sounds kinda similar to scriptless scripts?<br></div><div class=3D"gmai=
l_default" 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-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">W.r.t. priv=
acy, it certainly is a hit. But I think in situations where privacy is a go=
al, then the delegation can contact the original signer and ask to cooperat=
e. However in some circumstances that won't be viable given access to k=
eys or whatnot. I would suggest in these cases that you can do a hybrid: de=
legate to a script and provide a default sighash_all txn, and a modifiable =
sighash_none/single. Then the delegates can decide what is best to use and =
optimistically get the originals to sign off.</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)">Interestingly, th=
ere is a subset of cases where it is desirable to have privacy *from the or=
iginal script holder*. Conceivably the tx does need to be public at some po=
int, but for interest, once delegated to from S to S', S' could sho=
w a signature covering a txn hash from S', and request that S sign it. =
S' can reveal partial information -- e.g., which inputs are being spent=
, but not which outputs are being created. Maybe not super useful, but it i=
s interesting to note of course.<br></div><div class=3D"gmail_default" styl=
e=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:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)">Best,</div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Jeremy<b=
r clear=3D"all"></div><div><div dir=3D"ltr"><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><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Tue, Mar 16, 2021 at 1:36 AM ZmnSCPxj <<a href=3D"mailto:Zmn=
SCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.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">Good morning=
Jeremy,<br>
<br>
Thank you.<br>
<br>
Assuming only keys, an easier way of delegating would be simply to give a c=
opy of the privkey outright to the delegatee.<br>
<br>
However, an advantage of this technique you described is that the delegator=
can impose additional restrictions that are programmable via any SCRIPT, a=
n ability that merely handing over the privkey cannot do.<br>
Thus the technique has an ability that mere handover cannot achieve.<br>
<br>
If the delegatee is a known single entity, and S is simply the delegatee ke=
y plus some additional restrictions, it may be possible to sign with `SIGHA=
SH_ALL` a transaction that spends A and D, and outputs to a singlesig of th=
e delegatee key.<br>
This would avoid the use of `SIGHASH_NONE`, for a mild improvement in priva=
cy.<br>
The output would still allow the delegatee to dispose of the funds by its u=
nilateral decision subject to the fulfillment of the script S (at the cost =
of yet another transaction).<br>
On the other hand, if S is unusual enough, the enhanced privacy may be moot=
(the S already marks the transaction as unusual), so this variation has li=
ttle value.<br>
<br>
In terms of offchain technology, if the delegator remains online, the deleg=
atee may present a witness satisfying S to the delegator, and ask the deleg=
ator to provide an alternate transaction that spends A directly without spe=
nding D and outputs to whatever the delegatee wants.<br>
The delegator cannot refuse since the delegatee can always use the `SIGHASH=
_NONE` signature and spend to whatever it decides provided it can present a=
witness satisfying S.<br>
This is basically a typical "close transaction" for layer 2 techn=
ology.<br>
On the other hand, one generalized use-case for delegation would be if the =
delegator suspects it may not be online or able to sign with the delegator =
key, so this variation has reduced value as well.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000007b09cd05be48574a--
|