Date: Mon, 23 Nov 2020 00:40:56 +0000
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
Subject: [bitcoin-dev] Bulletin boards without selective censorability for
	bitcoin fungibility markets
Precedence: list

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.