Bulletin boards without selective censorability for bitcoin fungibility markets

Bulletin boards without selective censorability for bitcoin fungibility markets
2020-11-23 12:24 ` AdamISZ
  
From: AdamISZ @ 2020-11-23  0:40 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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.




 permalink raw reply	[|nested]
2020-11-23  0:40 [bitcoin-dev] Bulletin boards without selective censorability for bitcoin fungibility markets AdamISZ

  2020-11-23 13:53   ` Ruben Somsen
  2020-11-25  1:52   ` yanmaani
  
From: AdamISZ @ 2020-11-23 12:24 UTC (permalink / raw)
  To: AdamISZ, Bitcoin Protocol Discussion

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, 23 November 2020 00:40, AdamISZ via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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

Greg Maxwell pointed out to me on IRC that this idea doesn't work: there is only a receipt on the commitment to the offer (message) from the maker, not on the plaintext version, hence there is nothing stopping the maker from falsely claiming censorship after not sending the plaintext.

Reflecting on this a bit more, my intuition is that this problem is much more difficult than I had hoped; if there is a solution I suspect it involves much more sophisticated ideas. Many solutions just end up begging the question by presuming the existence of an uncensorable BB in order to create a new one; and/or use the blockchain for that function, but that is too slow and expensive, usually. I'd be happy to be proved wrong, though :)

waxwing


 permalink raw reply	[|nested]
2020-11-23 12:24 ` AdamISZ

  2020-11-25  1:52   ` yanmaani
  
From: Ruben Somsen @ 2020-11-23 13:53 UTC (permalink / raw)
  To: AdamISZ, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2602 bytes --]

Hi Adam,

That's a tricky issue you're trying to tackle.

>and/or use the blockchain for that function, but that is too slow and
expensive, usually

While perhaps not the most easy/practical path to take, it IS possible to
create a custom blockchain for this specific purpose to use as a
censorship-resistant data layer via Blind Merged Mining:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017534.html

Note that while it's not described in detail in my post, there is a
(slightly suboptimal) way to do it without a soft fork.

And here are more details about the perpetual one-way peg mechanism (needed
to pay for fees without introducing speculation):
https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302

Cheers,
Ruben

On Mon, Nov 23, 2020 at 1:59 PM AdamISZ via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, 23 November 2020 00:40, AdamISZ via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> > 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
>
> Greg Maxwell pointed out to me on IRC that this idea doesn't work: there
> is only a receipt on the commitment to the offer (message) from the maker,
> not on the plaintext version, hence there is nothing stopping the maker
> from falsely claiming censorship after not sending the plaintext.
>
> Reflecting on this a bit more, my intuition is that this problem is much
> more difficult than I had hoped; if there is a solution I suspect it
> involves much more sophisticated ideas. Many solutions just end up begging
> the question by presuming the existence of an uncensorable BB in order to
> create a new one; and/or use the blockchain for that function, but that is
> too slow and expensive, usually. I'd be happy to be proved wrong, though :)
>
> waxwing
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3716 bytes --]

 permalink raw reply	[|nested]
2020-11-23 12:24 ` AdamISZ
  2020-11-23 13:53   ` Ruben Somsen

  
From: yanmaani @ 2020-11-25  1:52 UTC ( / )
  To: AdamISZ, Bitcoin Protocol Discussion

On 2020-11-23 12:24, AdamISZ via bitcoin-dev wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, 23 November 2020 00:40, AdamISZ via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 
>> 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
> 
> Greg Maxwell pointed out to me on IRC that this idea doesn't work:
> there is only a receipt on the commitment to the offer (message) from
> the maker, not on the plaintext version, hence there is nothing
> stopping the maker from falsely claiming censorship after not sending
> the plaintext.
> 
> Reflecting on this a bit more, my intuition is that this problem is
> much more difficult than I had hoped; if there is a solution I suspect
> it involves much more sophisticated ideas. Many solutions just end up
> begging the question by presuming the existence of an uncensorable BB
> in order to create a new one; and/or use the blockchain for that
> function, but that is too slow and expensive, usually. I'd be happy to
> be proved wrong, though :)
> 
> waxwing
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Blockchains are bad for this, because you don't want for it to cost 
money to use your bulletin board. However, the problem was solved more 
than a decade ago. Look into FMS, which combines Usenet/mailing lists 
with a web of trust for spam resistance.