From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id DFB79C0052 for ; 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 ; 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 ; 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 ; 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 From: AdamISZ Reply-To: AdamISZ Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.