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
|
Return-Path: <AdamISZ@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id DFB79C0052
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Nov 2020 00:41:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id BDA3E203B2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Nov 2020 00:41:05 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id vT7ORmcnZR1X
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Nov 2020 00:41:03 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by silver.osuosl.org (Postfix) with ESMTPS id EE10420010
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Nov 2020 00:41:02 +0000 (UTC)
Date: Mon, 23 Nov 2020 00:40:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1606092060;
bh=g2ILzfheSOeWQBLerf2YGeVLawNxUZUZmFwQbEqF0iM=;
h=Date:To:From:Reply-To:Subject:From;
b=PtqQTVbRTn8oZ0RcpF7WWjJvBarWl4IXY1dCPeVut9ZthTGEqf9u9+KdSOk3WNMxW
5MuY2d+0VjdupqaM7Y3yhZ5YefnXB4kF1Sf7aLsQMr1YSVbmkF+rLwIjps8o5Vj8PG
c4098yVMPAK9kRFDDhVcvtE+E0yXNQavQIRznzuQ=
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Reply-To: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <S5bq_TLMgPY9S40UFwJULeLvExJ5iZBBJL36n389k87KUVWDCn4WIeG9OE99H-8R-d7WOIHutp0l9AozitRtwPPN2O98EmC6wKXPS0W1g5U=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 23 Nov 2020 00:51:26 +0000
Subject: [bitcoin-dev] Bulletin boards without selective censorability for
bitcoin fungibility markets
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: Mon, 23 Nov 2020 00:41:06 -0000
Canvassing opinions/critiques from those working on bitcoin and related pro=
tocols.
See the attached gist for a write-up of an outline of an idea, which is con=
ceived for joinmarket but can apply in other scenarios where there is marke=
t for liquidity and in which privacy is a very high priority (hence 'bitcoi=
n fungibility markets' can certainly include coinswap along with coinjoin, =
but possibly other things):
https://gist.github.com/AdamISZ/b52704905cdd914ec9dac9fc52b621d6
Abstract reproduced below:
Makers need a reasonable guarantee that their offers will not be censored, =
and therefore will be available to any taker requesting the joining service=
.
This is today, in Joinmarket specifically, somewhat achieved through the us=
e of redundancy. In particular, 2 or sometimes 3 independent IRC servers ar=
e used simultaneously, and the makers and takers use digitial signatures to=
ensure that spoofing other users is not possible. This model is limited ho=
wever; not only because IRC servers are not ideal for this purpose (being p=
rincipally designed for human text chat, not bot traffic), but also because=
at the least, we trust that the IRC servers are not colluding together to =
selectively censor individual participants. The risk of censorship of that =
type is ameliorated by the fact that makers connect (almost exclusively) ov=
er Tor, to the hidden service / onion of the IRC servers. Still, since thes=
e bots persist and use the same nick over multiple servers, and since their=
offering amounts, fees etc. may sometimes fingerprint them, selective cens=
orship is possible, again, if there is collusion.
In this document I present a sketch of an approach to make such selective c=
ensorship very difficult using cryptographic blinding as well as a proof-of=
-misbehavior approach; the former making selective censorship very difficul=
t to achieve, and the latter strongly disincentivising it.
Note that here "selective" is a very important word, but total censorship a=
nd random censorship should also be ineffective and disincentivised, for fa=
irly obvious reasons, although I will outline them.
If the desired effect is achieved, we can reasonably run Joinmarket or a si=
milar system on a single bulletin board server, with the caveat that it wil=
l need to be sufficiently easy to stand up a new instance; this should be t=
rue as long as the code is open source and the resource requirements are no=
t excessive.
It should also be noted that the design here is of course not specific to C=
oinJoin, but would also work the same way for CoinSwap (so "bitcoin fungibi=
lity markets") and perhaps other similar bitcoin-native systems whenever th=
e concept of a "liquidity maker" (henceforth "maker") applies, so perhaps s=
econd layer also (this has not been investigated).
Regards,
waxwing
Sent with ProtonMail Secure Email.
|