diff options
| author | AdamISZ <AdamISZ@protonmail.com> | 2020-11-23 00:40:56 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-11-23 00:41:05 +0000 |
| commit | cf190e2087177f6aa4c9a85d6b818eaec89d8b68 (patch) | |
| tree | 65ed8f136e75bdd07421672dad048341e19cebc2 | |
| parent | e0d442165aa455a9151995ad6ce923742996e079 (diff) | |
| download | pi-bitcoindev-cf190e2087177f6aa4c9a85d6b818eaec89d8b68.tar.gz pi-bitcoindev-cf190e2087177f6aa4c9a85d6b818eaec89d8b68.zip | |
[bitcoin-dev] Bulletin boards without selective censorability for bitcoin fungibility markets
| -rw-r--r-- | 2d/515815b67d4ed734698111092ba9b979467072 | 111 |
1 files changed, 111 insertions, 0 deletions
diff --git a/2d/515815b67d4ed734698111092ba9b979467072 b/2d/515815b67d4ed734698111092ba9b979467072 new file mode 100644 index 000000000..b56da1671 --- /dev/null +++ b/2d/515815b67d4ed734698111092ba9b979467072 @@ -0,0 +1,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. + + + |