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
|
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 A8DD2CBB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Aug 2019 00:09:16 +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 84F6A829
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Aug 2019 00:09:15 +0000 (UTC)
Date: Thu, 08 Aug 2019 00:09:11 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1565222952;
bh=zZpaXmuEjwbnZnp33LEbe6wBJLIUFy1bQi4mUvWr+sE=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=XiFdLKk2pNuCTBuJXNZJ3x99IExsDYUDU7lUGY/4LAnAOBjSNLtBpXKicmiCv76fT
FF9H8wPt/vIV9DfCf+RpwPr4FxIc4GnoaO4/Nc28dPkPWNdlm+qCaSa3A1LLJx6TVd
fO4QHKLd4kU1YrmCqlvdTu9TqbicQC77jbZnbsoM=
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: <jyEbDqD57bjrjd1QF72bLHmubrQxdc-WVqONP0gx-PjixLnQrLwWn9A2W_MkWwkTi_aJHSuUcLfxh2JnRp71110TtNNv8ZoDIhWAXFmuT5c=@protonmail.com>
In-Reply-To: <20190807201017.2a03b971@simplexum.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>
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 00:09:16 -0000
Good morning Dmitry,
> The first scheme - 'allow revocation of the whole bond by the key
> controlling even a single TXO in a bond' - might be more promising.
Is it?
I imagine any key can secretly be a MuSig or aggregated ECDSA key, with the=
aggregator being a signatory.
>
> > 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 op=
erations in order to decrypt.
https://www.gwern.net/Self-decrypting-files
This basically allows us to encrypt some data in such a way that its decryp=
tion is timelocked, by requiring a large number of sequential operations to=
decrypt.
It also seems to me (I am not a cryptographer) that it may be possible to p=
resent a ZKP that an encrypted text, encrypted using the above timelock dec=
ryption, is a signature of a particular message with a particular public ke=
y.
Thus, we can change the ritual to this:
1. I contact two lessors to aggregate their coins into a larger UTXO and t=
hus break V^2.
2. We create a funding transaction that pays to a locked bond address, wit=
h a pubkey equal to a MuSig among us.
This spends the TXOs they want to lease out, as well as some of my fund=
s to be used for paying for rent.
We do not sign this yet.
3. We create a backout transaction that returns the bond to both lessors, =
plus their rent.
We partly perform the MuSig ritual to sign this transaction, with me as=
the last step.
4. Instead of providing the completed signature to the lessors, I encrypt =
it using the above timelocked encryption.
I provide this encryption and a zero-knowledge proof that I have actual=
ly completed the signature ritual correctly and that the timelocked-encrypt=
ed text has the signature as plaintext.
5. The lessors now know they can acquire the signature by simply grinding =
the timelocked encryption.
This allows them to recover their money by the appointed time.
6. We then exchange signatures for the funding transaction and broadcast a=
nd confirm it.
Now, the lessors cannot provide a valid timelocked transaction, as they do =
*not* yet have a complete signature; thus they cannot snitch about my aggre=
gation of their funds.
At the same time, they know that the timelocked encryption allows them to e=
ventually get a complete signature and recover their funds.
I can defray this cost of processing by increasing my rent slightly.
Now of course we can just go one step further and also allow bonds to be sn=
itched by presenting the timelocked-encrypted text and the ZKP that it cont=
ains the signature for a timelocked transactions.
But it seems to me that there is more than one way to skin this particular =
cat, thus unless all ways to create provable timelocked encryptions are enu=
merable, it would be possible to get around.
(though of course it is dependent on a ZKP being possible for a timelocked =
encryption)
Finally, aggregation is still possible to insure by off-blockchain agreemen=
ts, possibly with legal consequences, and thus entities like exchanges migh=
t still be able to aggregate funds and acquire an undeservedly large weight=
in the fidelity bond system.
Regards,
ZmnSCPxj
|
