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: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1AAF3FC3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 May 2019 21:15:22 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5E0ADF4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 May 2019 21:15:21 +0000 (UTC)
Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com
[209.85.208.49]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4OLFIEv030252
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 May 2019 17:15:19 -0400
Received: by mail-ed1-f49.google.com with SMTP id b8so16068654edm.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 May 2019 14:15:19 -0700 (PDT)
X-Gm-Message-State: APjAAAVvqckTz8WHaS2rG9X1h5LQp9/otW1ZtFUDBSBN4BXgb2Gmn9bQ
zO1DvK4bukg7EUPoIjUJYvOrtlGiq/43rwuASuE=
X-Google-Smtp-Source: APXvYqy3k5dsHl13jZf+tRgJs+BQwd68pw48yAxdEGHqjb8BjeH3LmhM1sATXiiDtfyIE1jGP/60vkSC5q5I3/L4dxM=
X-Received: by 2002:a50:b662:: with SMTP id
c31mr108977040ede.252.1558732518531;
Fri, 24 May 2019 14:15:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
<VU6YVz_dc9U4BhGd6WWNvYLS-DI1lBE14tpYdXEyIufTZ2OvqQfcWh6RVelCLWTQMWqiNsSf_AM3Pq2hzn3G62RIQwceLx54rRmD-zHCdNU=@protonmail.com>
<CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@mail.gmail.com>
<CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com>
<CAD5xwhiHHemzaRLC7WMeXQ5hgu0rwMKMUym34xTxWO81qqf-oQ@mail.gmail.com>
<vbL4Nj9knpm6GMzS3wfTOcDPz9F6RoStna3mDwgJmmvYa1mPWa62x_atF3kBXjajlTDIxerTsYRr5pzI3xC3eSM_ssffsrXESqoNqMSg2h4=@protonmail.com>
In-Reply-To: <vbL4Nj9knpm6GMzS3wfTOcDPz9F6RoStna3mDwgJmmvYa1mPWa62x_atF3kBXjajlTDIxerTsYRr5pzI3xC3eSM_ssffsrXESqoNqMSg2h4=@protonmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 24 May 2019 14:15:07 -0700
X-Gmail-Original-Message-ID: <CAD5xwhgN23tXDHx6rB3vspswaq8-QyPjFkgmXcPY_R83gUe54Q@mail.gmail.com>
Message-ID: <CAD5xwhgN23tXDHx6rB3vspswaq8-QyPjFkgmXcPY_R83gUe54Q@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000011286a0589a8b28e"
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 25 May 2019 12:07:05 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY
proposal
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, 24 May 2019 21:15:22 -0000
--00000000000011286a0589a8b28e
Content-Type: text/plain; charset="UTF-8"
ZmnSCIPxj,
I think you're missing the general point, so I'm just going to respond to
one point to see if that helps your understanding of why OP_COSHV is better
than just pre-signed.
The reason why MuSig and other distributed signing solutions are not
acceptable for this case is they all require interaction for guarantee of
payout.
In contrast, I can use a OP_COSHV Taproot key to request a withdrawal from
an exchange which some time later pays out to a lot of people, rather than
having to withdraw multiple times and then pay. The exchange doesn't have
to know this is what I did. They also don't have to tell me the exact
inputs they'll spend to me or if I'm batched or not (batching largely
incompatible with pre-signing unless anyprevout)
The exchange can take my withdrawal request and aggregate it to other
payees into a tree as well, without requiring permission from the
recipients.
They can also -- without my permission -- make the payment not directly
into me, but into a payment channel between me and the exchange, allowing
me to undo the withdrawal by routing money back to the exchange over
lightning.
The exchange can take some inbound payments to their hot wallet and move
them into cold storage with pre-set spending paths. They don't need to use
ephemeral keys (how was that entropy created?) nor do they need to bring on
their cold storage keys to pre-sign the spending paths.
None of this really works well with just pre-signing because you need to
ask for permission first in order to do these operations, but with OP_COSHV
you can, just as the payer without talking to anyone else, or just as the
recipient commit your funds to a complex txn structure.
Lastly, think about this in terms of DoS. You have a set of N users who
request a payment. You build the tree, collect signatures, and then at the
LAST step of building the tree, one user drops out. You restart, excluding
that user. Then a different user drops. Meanwhile you've had to keep your
funds locked up to guarantee those inputs for the txn when it finalizes.
In contrast, once you receive the requests with OP_COSHV, there's nothing
else to do. You just issue the transaction and move on.
Does that make sense as to why a user would prefer this, even if there is
an emulation with pre-signed txns?
--00000000000011286a0589a8b28e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default">ZmnSCIPxj,</div><div s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,=
0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"=
>I think you're missing the general point, so I'm just going to res=
pond to one point to see if that helps your understanding of why OP_COSHV i=
s better than just pre-signed.<br></div><div style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"=
><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)" class=3D"gmail_default">The reason why MuSig and oth=
er distributed signing solutions are not acceptable for this case is they a=
ll require interaction for guarantee of payout.</div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"g=
mail_default"><br></div><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">In contrast, I =
can use a OP_COSHV Taproot key to request a withdrawal from an exchange whi=
ch some time later pays out to a lot of people, rather than having to withd=
raw multiple times and then pay. The exchange doesn't have to know this=
is what I did. They also don't have to tell me the exact inputs they&#=
39;ll spend to me or if I'm batched or not (batching largely incompatib=
le with pre-signing unless anyprevout)<br></div><div style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_=
default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)" class=3D"gmail_default">The exchange can tak=
e my withdrawal request and aggregate it to other payees into a tree as wel=
l, without requiring permission from the recipients.</div><div style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">They can a=
lso -- without my permission -- make the payment not directly into me, but =
into a payment channel between me and the exchange, allowing me to undo the=
withdrawal by routing money back to the exchange over lightning.<br></div>=
<div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_de=
fault">The exchange can take some inbound payments to their hot wallet and =
move them into cold storage with pre-set spending paths. They don't nee=
d to use ephemeral keys (how was that entropy created?) nor do they need to=
bring on their cold storage keys to pre-sign the spending paths.<br></div>=
<div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_de=
fault">None of this really works well with just pre-signing because you nee=
d to ask for permission first in order to do these operations, but with OP_=
COSHV you can, just as the payer without talking to anyone else, or just as=
the recipient commit your funds to a complex txn structure.</div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">La=
stly, think about this in terms of DoS. You have a set of N users who reque=
st a payment. You build the tree, collect signatures, and then at the LAST =
step of building the tree, one user drops out. You restart, excluding that =
user. Then a different user drops. Meanwhile you've had to keep your fu=
nds locked up to guarantee those inputs for the txn when it finalizes.<br><=
/div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gma=
il_default">In contrast, once you receive the requests with OP_COSHV, there=
's nothing else to do. You just issue the transaction and move on.</div=
><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_d=
efault"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Does that make sense =
as to why a user would prefer this, even if there is an emulation with pre-=
signed txns?<br></div></div>
--00000000000011286a0589a8b28e--
|
