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
|
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 63A94DA6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Aug 2019 09:35:33 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1987214D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Aug 2019 09:35:31 +0000 (UTC)
Date: Thu, 08 Aug 2019 09:35:24 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1565256928;
bh=M6bbsk67nb65FSFWDZ5zfDvmZwXcR2ISA41nIgr9gxM=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=J58e8cQXgi09mesphMbz4pbqJgY94PwcNNJRqEj/3PLX4QnU8e1Hd95a6/3aoUouS
P6O5oakrK0GMcglhooJxYJi+BRvjt1pSjaLyjLW5Js/KKMZE9wxYJk0/a0pWTpi1bh
W2OkcvOv9gvS8Ad9dsTtHAHYfdCg6G5PNvs6qoZc=
To: Dmitry Petukhov <dp@simplexum.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <-6u9Ut_oYRThO21GIO1G8u4LpKavq2okw0Z7KoIM0tgwg4mAYXt2TP-SgiigMofdvLhvRuwX_q7Op6DUDM_eWUCjGmIEL_VTLpAeYDNOl5c=@protonmail.com>
In-Reply-To: <jyEbDqD57bjrjd1QF72bLHmubrQxdc-WVqONP0gx-PjixLnQrLwWn9A2W_MkWwkTi_aJHSuUcLfxh2JnRp71110TtNNv8ZoDIhWAXFmuT5c=@protonmail.com>
References: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net>
<20190731205018.10ed4302@simplexum.com>
<ae32dcbb-c950-3b3f-22b9-d152d6b221cb@riseup.net>
<20190802145057.7b81c597@simplexum.com>
<ad501873-8912-765e-8df5-c9b0451fcd0a@riseup.net>
<20190807015541.3d8aa849@simplexum.com>
<20190807023742.73750ba3@simplexum.com>
<483af6d0-ac5a-0e22-da29-af0be5196c15@riseup.net>
<20190807201017.2a03b971@simplexum.com>
<jyEbDqD57bjrjd1QF72bLHmubrQxdc-WVqONP0gx-PjixLnQrLwWn9A2W_MkWwkTi_aJHSuUcLfxh2JnRp71110TtNNv8ZoDIhWAXFmuT5c=@protonmail.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
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil
attacks using fidelity bonds
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: Thu, 08 Aug 2019 09:35:33 -0000
Good morning Dmitry, and list,
> > > I wonder if there's a cryptographic way to prove that muSig and
> > > 2P-ECDSA have not been used to create a certain pubkey/signature.
> >
> > In the second scheme, to revoke/spoil the bond, the entity that
> > controls one TXO participating in this bond needs to simply prove that
> > it somehow controls/have the ability to spend that TXO.
> > In shared ownership rent scheme that ZmnSCPxj described in [1],
> > the 'TXO rentier' has a signed timelocked 'backout' transaction that
> > spends the locked TXO, and assigns the reward to rentier.
> > If we say that any transaction that spends any TXO in the bond
> > (ignoring the timelock), invalidates the bond when presented to
> > takers, then TXO rentier can revoke the bond by simply
> > publishing this transaction (not to the blockchain, but by some other
> > means so that takers can receive it).
> > The transaction validity can be verified, with the relaxed rules that
> > ignores the timelock. After it is verified, takers mark the whole
> > bond as revoked and will not consider it when chosing makers.
> > One inconvenience here is that takers need to store the
> > data about revoked bonds. But it seems to me that there's no need
> > for that information to be synchronized between the participants
> > instantly. It is enougth for takers to get the revoked-set eventually.
> > The rentier are still incentivized to not spoil the bond, to receive
> > the profit. Their funds are locked anyway.
> > But if the goal of the 'rentier' is to attack the attacker, the
> > opportunity cost of these locked funds is the cost of the attack.
> > If the renter rents TXOs from several entities to include in one bond,
> > revocation by one rentier spoils whole bond, and the total loss for all
> > participants is bigger than the oportunity cost of locked funds of a
> > single rentier that made the revocation.
> > The possibility of such revocation increases risk for the renter and
> > would-be co-rentiers, and is likely limit the possible scale of such
> > TXO-renting operation.
>
> This is quite a clever solution.
>
> Let me then attempt to break it.
>
> It is possible to encrypt data in such a way that it requires sequential =
operations in order to decrypt.
> https://www.gwern.net/Self-decrypting-files
I apologize, I was being daft.
There is a simpler way to break this, involving such Lightning Network trop=
es as revocation and punishment schemes.
Truly, Lightning Network is a great great thing.
First, we should always consider, that due to the V^2, consolidated bonds a=
re always higher weight than unconsolidated bonds.
Thus, even without considering motives to spy on CoinJoins, the existence o=
f the V^2 tweak implies that there will be fewer larger makers and thus eas=
ier to take over the JoinMarket system.
So, let us focus on the backout transaction.
Under a consolidated bond, this requires an n-of-n.
Now, suppose we want to identify the snitch who reports our consolidation s=
cheme to the takers.
This can be done easily by performing n MuSig n-of-n rituals, with each rit=
ual using different `r` nonces.
We arrange this by having each of the n consolidators be the last signers i=
n the second round of the MuSig, and have each signer keep their own unique=
version of the signature for the backout, with their own unique `r` nonce.
Each participant will want to keep its own version of the signature private=
, because if it gives out this signature to another participant in the cons=
olidated bond scheme, the other participant can frame them for snitching.
We can now identify the snitch, by recognizing which signature was used in =
the transaction that was reported to the takers.
But we have not yet identified how we can punish the snitch.
As it happens, MuSig allows Scriptless Script.
This means, it is possible for one participant in the MuSig to provide an a=
daptor signature.
This adaptor signature commits to a particular point.
When the MuSig is completed and the participant (who is the last signer in =
the second round of MuSig) reveals the completed signature, the scalar that=
generates the commited point can be computed by anyone who knows the adapt=
or signature.
This is our next step in our scheme to identify and punish snitches.
In addition to putting up their funds in a consolidated bond, each of the p=
articipants in the consolidation scheme put up a fraction of the value into=
revocable bonds.
This revocable bond is a Taproot with a known-NUMS point as internal Taproo=
t key, and the script alternatives below:
<bond_time - 1> OP_CHECKLOCKTIMEVERIFY OP_DROP <participant_key> OP_CHE=
CKSIG
and
<MuSig(all participants *except* this participant)> OP_CHECKSIGVERIFY <=
participant_snitch_key> OP_CHECKSIG
A punishment transaction spends from the revocable bond via the second alte=
rnative above, and divides it equally among the *other* participants.
THis is signed using the MuSig above (where all participants except the own=
er of this revocable bond are part of).
Then, before starting the n rituals to sign the backoff transaction, the pa=
rticipants provide adaptor signatures to their own `participant_snitch_key`=
, such that if they publish the backoff transaction to the takers, any of t=
heir co-participants that masquerades as a taker can find out about this an=
d derive the private key to the `participant_snitch_key`.
So:
1. In case all the participants cooperate with the other consolidators, th=
en just before the bond expires, each participant can recover their revocab=
le bond via the first alternative shown above.
Once the revocable bond is spent back to an address they solely control=
, the `participant_snitch_key` is worthless.
Then any participant can publish onchain the backoff transaction withou=
t repercussion.
2. In case a participant snitches and reveals a pre-signed backoff to the =
takers before the end of the bond period, they can only reveal their own ve=
rsion of the signature of the backoff transaction.
In that case, their previously-shown adaptor signature can be used to r=
eveal the private key behind their `participant_snitch_key`.
Then any one of the other participants in the consolidation scheme can =
complete the punishment transaction.
We can even ensure that setup of the whole system is atomic, by unironicall=
y CoinJoining the creation of the consolidated JoinMarket V^2 fidelity bond=
, in the same transaction that creates the revocable bonds that can be used=
to ensure that snitches are punishable.
Now you might say, "well now the bond they can put into the JoinMarket fide=
lity bond is smaller because of the need to put a revocable bond".
And that is right.
It also shows that the V^2 tweak is broken.
Suppose there are two makers with 1.0 BTC each.
They decide to consolidate their bond in order to increase their consolidat=
ed weight in the JoinMarket fidelity bond system.
They decide to put up 0.25BTC each for the revocable bonds, and 0.75BTC eac=
h into the consolidated JoinMarket V^2 fidelity bond.
The total consolidated bond is 1.5BTC, which has a weight 2.25x the weight =
of one 1.0BTC bond, or 1.125x the weight of 2x 1.0BTC bonds.
Thus consolidation pressure still exists strongly (and I would think that l=
osing as little as 5% of your total bondable funds would be enough to disco=
urage snitches: this example is 25%).
The scheme would not be broken if there was no V^2 tweak, and would have wo=
rked perfectly to disable consolidation, if not for the V^2 tweak.
Regards,
ZmnSCPxj
|
