Canvassing opinions/critiques from those working on bitcoin and related protocols.
See the attached gist for a write-up of an outline of an idea, which is conceived for joinmarket but can apply in other scenarios where there is market for liquidity and in which privacy is a very high priority (hence 'bitcoin 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 use of redundancy. In particular, 2 or sometimes 3 independent IRC servers are used simultaneously, and the makers and takers use digitial signatures to ensure that spoofing other users is not possible. This model is limited however; not only because IRC servers are not ideal for this purpose (being principally 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) over Tor, to the hidden service / onion of the IRC servers. Still, since these bots persist and use the same nick over multiple servers, and since their offering amounts, fees etc. may sometimes fingerprint them, selective censorship is possible, again, if there is collusion. In this document I present a sketch of an approach to make such selective censorship very difficult using cryptographic blinding as well as a proof-of-misbehavior approach; the former making selective censorship very difficult to achieve, and the latter strongly disincentivising it. Note that here "selective" is a very important word, but total censorship and random censorship should also be ineffective and disincentivised, for fairly obvious reasons, although I will outline them. If the desired effect is achieved, we can reasonably run Joinmarket or a similar system on a single bulletin board server, with the caveat that it will need to be sufficiently easy to stand up a new instance; this should be true as long as the code is open source and the resource requirements are not excessive. It should also be noted that the design here is of course not specific to CoinJoin, but would also work the same way for CoinSwap (so "bitcoin fungibility markets") and perhaps other similar bitcoin-native systems whenever the concept of a "liquidity maker" (henceforth "maker") applies, so perhaps second layer also (this has not been investigated). Regards, waxwing Sent with ProtonMail Secure Email. _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
