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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 561D8AA5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 May 2019 03:56:32 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C9D2AA9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 May 2019 03:56:30 +0000 (UTC)
Date: Sat, 25 May 2019 03:56:22 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1558756588;
bh=jEb/SIEZ523lLeXWIyOcRlIWDVITjfO4/nSgy1intlA=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=E4O1vvlkfe5AwpdA0qMtn4jDSkW8LVCFTq4gWZwAZ4g+XhQh/4TokxeOFaavUDLui
znaR9RqIf+F6mwQ2sSRycsY+6jHtmGOeeHjuKMOQARtthhVEkQzaZpLu6MTDfls7/q
FImwrGLVcyjgqt+cdod7Qsrybkidm3CqZId6toBE=
To: Jeremy <jlrubin@mit.edu>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <NtcMB87WFBKpIzRKHh5bbEeBFGITr2k0qAgmrSE97X30gYJI2RRldrNdeL8X3e50N9N-m6cbuPistWniu3gadi3LuF7oYLltuINj2heepVw=@protonmail.com>
In-Reply-To: <CAD5xwhgN23tXDHx6rB3vspswaq8-QyPjFkgmXcPY_R83gUe54Q@mail.gmail.com>
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>
<CAD5xwhgN23tXDHx6rB3vspswaq8-QyPjFkgmXcPY_R83gUe54Q@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW 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:05:39 +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: Sat, 25 May 2019 03:56:32 -0000
Good morning Jeremy,
I believe I have caught the general point.
Indeed, I agree that this is useful, but it is *not* useful for these cases=
:
1. CoinJoin - the initial funding transaction must be signed by the partic=
ipants anyway after checking that the output is correct.
Further any spend that is not a signature spend is going to defeat the =
purpose of CoinJoin trying to be private by imitating "typical" spends: if =
`OP_CHECKOUTPUTSHASHVERIFY` path is used, you have just lost the CoinJoin p=
rivacy by reducing anonymity set.
2. Channel Factories - the initial funding transaction must be signed by t=
he participants anyway after each initial sub-channel initial commitment / =
initial update+state transaction is signed.
In both above cases, the issue of users dropping out during the step of sig=
ning the initial funding transaction is unavoidable even with `OP_CHECKOUTP=
UTSHASHVERIFY`.
For congestion control, and for general "I promise to set this up later" as=
in c*stodial-service-directly-to-channel etc., I already agree this is use=
ful.
My objection lies *only* with the above two cases, wherein `OP_CHECKOUTPUTS=
HASHVERIFY` does not really improve things, as you *still* need to coordina=
te multiple signers anyway.
You have convinced me already that the other cases are good example usages =
of this opcode.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Saturday, May 25, 2019 5:15 AM, Jeremy <jlrubin@mit.edu> wrote:
> 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 bette=
r than just pre-signed.
>
> The reason why MuSig and other distributed signing solutions are not acce=
ptable for this case is they all require interaction for guarantee of payou=
t.
>
> In contrast, I can use a OP_COSHV Taproot key to request a withdrawal fro=
m an exchange which some time later pays out to a lot of people, rather tha=
n 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 inpu=
ts they'll spend to me or if I'm batched or not (batching largely incompati=
ble with pre-signing unless anyprevout)
>
> The exchange can take my withdrawal request and aggregate it to other pay=
ees into a tree as well, without requiring permission from the recipients.
>
> They can also -- without my permission -- make the payment not directly i=
nto 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 lightnin=
g.
>
> 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 r=
equest a payment. You build the tree, collect signatures, and then at the L=
AST step of building the tree, one user drops out. You restart, excluding t=
hat 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.
>
> 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?
|
