design decentralized network protocol for joinmarket

[undeath]

There has been some informal discussion about designing a truely decentralized
network for joinmarket (see JoinMarket-Org/joinmarket#248)
but so far no specific protocol design efforts have been made.

In this issue I would like to discuss and design a specification for such a
decentralized protocol for joinmarket.

The below is a proposal draft. It is not perfect yet. Please review it
and share any thoughts or issues on it.

Goal

Design a secure, decentralized protocol suitable for joinmarket. Makers must be
able to publish their coinjoin offers, Takers must be able to retrieve a list
of all available Makers' offers and information on how to contact them.

Specific design goals:

• not less secure than the current IRC-based protocol
• decentralized
• providing strong anonymity for all parties

Protocol Idea

All communication must happen over Tor onion v3 services using WebSocket
connections.

We assume three different roles in the network:

Directory Server

• Maintains list of available offers from all Makers
• Maintains list of other Directory Servers
• Uses a gossip protocol to share new offers/Directory Servers with other known Directory Servers
• Shares above lists with interested parties on demand (most importantly Takers)
• Registers itself periodically with other Directory Servers
• Has a (preferably) long-lived onion address

Maker

• Publishes coinjoin offers periodically to Directory Servers
• Has an ephemeral onion address linked to their offers

Taker

• Bootstraps with a JM-shipped list of available Directory Servers
• Retrieves additional servers from known Directory Servers
• Retrieves Maker offers from known Directory Servers
• Contacts Makers based on the received offers to carry out coinjoins

Protocol Details

Directory Server

• Runs a (non-TLS) WebSocket server behind a Tor onion v3 service, running on
  port (55000,60000(

  Rationale:
  Tor onion services provide fail-safe anonymity for all parties with strong
  e2e encryption. Moreover, Tor onion services provide reliable message
  routing and basic network-level attack defenses.
  WebSocket is a relatively low-overhead network protocol with broad support
  in not only all major programming languages but also web browsers. This
  may allow running a full JM client in a (tor-capable) browser.
  Ports are limited to avoid abusing the network for DDoS against unrelated
  onion services (eg web services).

• Provides pluggable modules (or features) that can be used to share information.
  Basic modules shipped with joinmarket at the current stage could be
  directory_servers, jm_offers and a base module to list
  available modules. Module names must match ^[a-z_]+$.

  Additional modules could be: snicker, tx_broadcast

  Rationale:
  Keeping the features explicitly modular makes it easy to deploy new features.
  The implementation overhead should be negligible.

• Modules provide an unauthenticated way to add new entries. Old entries will time
  out after a certain time (1h?). New entries will be forwarded to other known
  Directory Servers.

  Open question: Verify submitted entries to some extend?

  Open question: How to design the gossip protocol to allow renewing timeouts
  without flooding the network? Attach a timestamp? How about attacks?

  Rationale:
  All Directory Servers should always be able to accurately reflect the
  current state of the network.

• Exact data submitted/provided by each module depends on the module:

  directory_servers

  • onion v3 hostname (without .onion)
  • supported modules

  jm_offers

  • onion v3 hostname (without .onion)
  • same data as current IRC offer implementation
  • (possibly switch out [sw](rel|abs)offer with some kind of flags system);
    each offer could allow to attach a list of arbitrary flags like [name[=value],…]
    where name and value match ^[A-Za-z0-9_]$ with flags like
    type=lsw or type=sw (for legacy/p2sh segwit or native segwit offers).
    This also easily allows backward-compatible extensions, eg for better sybil
    resistance. Flag names must be sorted by ascii value and each name must only
    occur at most once. This reduces leaking identifying information. There should be
    a length restriction of (100?) characters.

Maker

• Runs a (non-TLS) WebSocket server behind a Tor onion v3 service, running on
  port (60000,65000(

• Provides interface to initiate coinjoins with this Maker, similar to the
  existing IRC protocol.

  Todo: Update existing protocol to strip out unneeded encryption/authentication

Taker

• Contacts hardcoded Directory Servers for more Directory Servers
• (?maintains own list of Directory Servers after initial bootstrap?)
• Contacts a random subset of (3?) known Directory Servers to retrieve offers
• Selects appropriate makers based on existing selection algorithms and contacts
  them to do coinjoins

Todo: Individual protocol messages

The current protocol is documented at https://github.com/JoinMarket-Org/JoinMarket-Docs/blob/master/Joinmarket-messaging-protocol.md

Suitable protocol messages need to be designed for each known IRC command.

Currently no data serialization format is defined for the data sent through the
WebSocket connection. I think protobuf would fill this gap nicely.

Related Projects

Several interesting projects have been mentioned in JoinMarket-Org/joinmarket#248
and I would like give a short rationale on why I excluded the other mentioned projects
from this design draft.

Subspace

dead, could be used by Takers to contact Makers but would seemingly make things only
more difficult to implement while not providing an obvious benefit.

Not suited for collecting list of Maker offers.

Bittorrent DHT

not dead, but otherwise same as Subspace

np1sec

just looks complicated, haven't tried to understand how exactly it works.
Don't know if suited at all.

Matrix

centralized infrastructure? could work but seems kludgy for joinmarket's purposes

ZeroNet

seems to be designed for running a centrally managed service in a decentralized manner

Further Thoughts

This is somewhat related to #371 but not necessarily dependant on it. The protocol should be designed in a way that makes it easy to extend.

Are there any known shortcomings in the protocol messages we have right now that should to be addressed in a protocol upgrade?

[chris-belcher]

If anybody is free to set up a Directory Server and have them spread by gossiping, then the system will be vulnerable to sybil attacks. An attacker could set up unlimited Directory Servers, have them spread throughout the network and then they'll be a high chance that the taker's 3 random choices of servers will all be controlled by the attacker, who can feed the taker only the attacker's own sybil makers. So the list of Directory Servers needs to be hard to join; for example, by having them in a configuration file which few people ever change.

One difference between your proposal and the proposal here JoinMarket-Org/joinmarket#248 (comment) is that in your proposal the list of all offers is hosted by the Directory Servers themselves, instead of each maker hosting their own offers. Can you explain this decision? It seems to me that since Directory Servers are run on a voluntary basis (compared to makers who earn income from their activities) then the costs to Directory Server operators should be kept as low as possible. Makers should pay for their own hosting as much as possible. So Directory Server should only host links to maker (ephemeral onion addresses) and not the offers of the makers.

In terms of attacks; A simple DDOS (where the attacker has more bandwidth/IP addresses than the defender) is probably impossible to prevent, although the existing JoinMarket over IRC is completely vulnerable to this attack too, as is the bitcoin p2p network and essentially every website (note that basically the whole web uses cloudflare). To stop the Directory Servers being flooded, I think this section of the snicker bip covers all the options: https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#anti-spam-prevention

[undeath]

Fair point on the sybil attack on Directory Servers. However, I am strongly opposed to having a hand-picked list of trusted Directory Servers. It adds centralization, both in the servers and the people selecting those servers (jm maintainers). I believe a nice solution to this problem would be Directory Servers committing a proof of age using OpenTimestamps (OTS), which we currently use for signing our commits, and their onion identity. That way the list could be limited to at most x (lets say 50) active Directory Servers with a preference for older servers. If one of those old servers turns evil it would be feasible to maintain a hardcoded blacklist to permanently exclude them.

I don't think having Directory Servers host a list of active offers would impose unbearable costs. Assuming a rather pessimistic space requirement of 1kb per offer, saving 2000 offers would require 2mb of RAM. Such a limit could (and should, probably) be added and would not cause any problems to joinmarket in its current activity state. There are roughly 100 active offers on IRC. If the offer lists are not hosted by the Directory Servers that means a Taker would have to establish potentially hundreds of TCP connections over Tor to retrieve each Maker's offers. This would probably be quite slow and might impose non-negligible resource requirements for Takers and Makers.

On the other hand, having Directory Servers host the list of active offers does cause some difficulties on its own. Sybil attacks are of course a thing, but those do not seem to be more problematic than with the current IRC protocol. Solutions to that are discussed in #371 and would apply just the same if lists were hosted by Directory Servers. A different problem is a Maker's ability to update their offers. Without any protection to this an attacker might just ask Directory Servers to de-list some (or all) offers, effectively DoS'ing joinmarket. I imagine a solution where a Maker signs their offer(s) using their onion identity. The onion v3 identity is a full public ed25519 key which can be re-purposed for this¹ (I have already done some preliminary tests to verify this). Add an hour-accurate time stamp (more accuracy is not needed and may add identifying information if someone has an inaccurate system clock) and a strictly monotonically increasing counter, allowing a Maker to update their offers while preventing everyone else from doing so. Additionally this would prevent replay attacks that flood Directory Servers with outdated offers of inactive Makers.

¹ Ideally this would not use the public identity master key for signing but a derived blinded ed25519 key, but this would be a little complicated to implement in python and the only implementation I have found is the one Tor is using itself. See Appendix A [KEYBLIND] at https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt

[chris-belcher]

The solution to Directory Server sybil attacks using proof of age assumes that old guys can't be bad guys. The sybil attacker could create many Directory Server names and then age them (spammers already today age reddit and twitter accounts). For example, let's say the value of a Directory Server is linearly proportional to age, say the honest servers were 6 months old when a sybil attack happens. The sybil attacker creates a million directory servers and waits, after 2 years the sybil servers will be worth 2 and the honest servers will be worth 2.5 (2 years and 6 months), so there'd only be a 20% difference in value between honest and sybil servers, and given that sybil servers outnumber the honest servers it would still be quite likely that the taker's 3 random choices all land on the sybil servers.

It's worth noting that decentralization isn't an end in itself. The end is censorship resistance, permissionlessness and robustness. JoinMarket would likely still have those things with a small number of Directory Server hidden behind tor. Bitcoin itself is centralized on one implementation (which is fine because its open source) and it uses DNS seeds for new peers to bootstrap (which admittedly are different from the Directory Server scheme from this thread).

The issue with having the orderbook hosted on Directory Servers isn't about unbearable costs, but about skin in the game. Directory Servers would be run by volunteers. Having makers host their own offers would cost them more resources, but they earn an income from their activities and takers also get a privacy benefit from using joinmarket. Also the cost would be distributed amongst all the makers and takers rather than concentrated on the relatively fewer number of Directory Servers. Finally, the cost isn't just storage and bandwidth, but also connections and uptime. Consider that if the Directory Server system goes down for a few hours one day (maybe because it got DDOS'd?), JoinMarket would stop working for those few hours if the orderbook is hosted by Directory Servers. Not so if makers themselves hosted the orderbook, then takers which have already downloaded the list of maker's onion addresses could continue connecting to them and creating coinjoins. So the system's robustness would be improved. Also maker's self-hosting simplifies the issue with modification and expiry of offers.

I appreciate that makers self-hosting their own offers requires takers to make lots of TCP/tor connections, but I wonder if there's a way to filter them beforehand. For example if the taker wants to make a coinjoin for 10btc it can exclude makers who advertise a very small fidelity bond (fidelity bonds can be kept in cold storage so can expect the bond value to be higher than the hot wallet funds available for coinjoining). I know all the connections would be slow, but bitcoin itself is kind of slow anyway since the block interval is 10 minutes, so it's probably fine for other parts of the system to be slow too. Also, having Directory Servers host the orderbook instead requires them to deal with lots of incoming connections which happen very often (the current tumbler script requests the orderbook before every coinjoin IIRC, that would all have to go through Directory Servers instead)

[undeath]

Directory Servers would be run by volunteers. Having makers host their own offers would cost them more resources, but they earn an income from their activities and takers also get a privacy benefit from using joinmarket. Also the cost would be distributed amongst all the makers and takers rather than concentrated on the relatively fewer number of Directory Servers.

Actually, I would expect most Makers to host a Directory Server themselves, probably making up the main part of the set (they have a huge incentive to do so, namely the robustness of the network they rely on). The system merely offers the possibility of hosting Directory Servers without being a Maker.

But your comments did bring me to a slightly different, yet related question: couldn't we do without Directory Servers and centralised entities altogether? By reversing the roles of Takers and Makers in the protocol, we could have a very basic gossip network where Takers broadcast their orders (cj amount), tied with a ephemeral onion v3 identity, and are contacted by Makers. This would be extremely simple, yet removes a lot of attack vectors. No directory servers that can be attacked, no makers that can be attacked, sybil attacks would be much harder to conduct (as is proven by the existence of other basic p2p networks such as bittorrent DHT or bitcoin). Every network participant would have open connections to something like 10 to 50 other nodes, sharing known nodes on request and other than that just forward broadcasted messages (cj orders). What do you think about that?

The only downside I can think of is the higher complexity for being a Taker: you'd have to have a Tor control connection for the ability to dynamically create hidden services.

[chris-belcher]

If directory servers are mostly run by makers then we fall into the same old trap with incentive problems: JoinMarket-Org/joinmarket#248 (comment) Market-makers-as-transport-peers have an incentive to censor their competitors offers, in the directory servers setup they also have an incentive to not gossip the peering information, because that can limit takers seeing their competitors offers. That's why I've always been thinking of schemes where Directory Server operators are somehow different to makers, it's also why I imagined they'd be volunteers presumably motivated by being true believers in bitcoin privacy.

Some thoughts on the takers-as-peers idea:

• Even though there's no directory services or makers to be attacked, the takers themselves could be attacked (I assume we're talking about a DDOS attack where the attacker just has more bandwidth than the defender). Also the network might be attacked by flooding, how do you rate limit the taker's offers? Takers won't really have the option of fidelity bonds like makers do. Note that in bitcoin's p2p network flooding requires either spending lots of PoW or spending lots of bitcoin UTXOs. Bittorrent doesn't have fast flooding, instead all the connections are throttled by users because bandwidth is by far the scarcest resource.
• It would require takers to be online all the time, which is not really compatible with takers as regular bitcoin users. I'd imagine takers as regular people who are using bitcoin to buy bread and eggs and whatever, but now their wallet (which could be in the third world, or be a smartphone that enters into a tunnel at the wrong moment) requires them to be online nearly 24/7 and be well-maintained enough to accept connections and possibly resist attacks? That doesn't sound very good.

[undeath]

Market-makers-as-transport-peers have an incentive to censor their competitors offers, in the directory servers setup they also have an incentive to not gossip the peering information, because that can limit takers seeing their competitors offers.

It would be fairly easy for Directory Servers to check if other Directory Servers refuse to include some or all external entries after having been notified about them and block such servers.

I assume we're talking about a DDOS attack where the attack just has more bandwidth than the defender

I'd assume Taker identities to be very short-lived (in the range of few minutes <<10min) and for a single cj only. I guess it would be hard to spin up DDoS attacks quickly enough to prevent Takers from receiving enough offers from Makers.

It would require takers to be online all the time

Not at all. See above. Taker broadcasts the order, waits a short time for the Makers to contact them and can go offline again.

Also the network might be attacked by flooding

That's a valid concern. The same question arises in basically every gossip-based protocol. This does include the discussed Directory Server network (with or without hosted offers).

[chris-belcher]

It would be fairly easy for Directory Servers to check if other Directory Servers refuse to include some or all external entries after having been notified about them and block such servers.

OK but how do they stop takers from using those bad Directory Servers? Imagine if the honest Servers and sybil Servers all block each other and partition the Server network, with each partition claiming to be the honest one. How is an ordinary taker who just started using JoinMarket meant to know which partition is honest and isn't all run by the same person. The root of the problem is that anyone can run a Server with little cost and takers consider them basically equal.

I'd assume Taker identities to be very short-lived (in the range of few minutes <<10min) and for a single cj only.

If the p2p network is entirely made up of takers then at least some takers have to be online all the time, so that they can accept new connections.

I guess it would be hard to spin up DDoS attacks quickly enough to prevent Takers from receiving enough offers from Makers.

This doesn't seem hard at all, the DDOSer (say they have a botnet or lots of big servers) only needs to pretend to be a maker and listen for taker announcements, then when one arrives they immediately send a flood of requests to the taker's tor hidden service, stopping real makers from being able to connect.

That's a valid concern. The same question arises in basically every gossip-based protocol. This does include the discussed Directory Server network (with or without hosted offers).

This is true, but I'd argue using maker fidelity bonds as in #371 solves this. The same fidelity bonds used by makers to prove they're not sybils can also be used to rate-limit flooding. So that means that makers should be the ones who broadcast something and everyone else only listens, because makers already have fidelity bonds.

[3nprob]

Have you guys looked at existing initiatives? Seems like all the L2/offchain DEXes are essentially all solving for the exact same problem of relaying orders, perhaps there's a good implementation that can be forked/extracted, or at least taken as inspiration?

I haven't done an exhaustive research , but maybe it's worth looking closer at 0x protocol. It's transport agnostic and from a glance shouldn't by tricky to break apart from the Ethereum-specific things.

https://github.com/0xProject/0x-mesh

[3nprob]

Some more thoughts:

I think it could be helpful to qualify or specify "decentralized" in the goals - it can be considered in different levels and dimensions.

• Matrix: Arguably at least as decentralized as the proposed model. If I get the current proposal right, it's federated in a similar way to Matrix (Homeserver <> Directory server).
  • I think for the short- to mid-term, matrix is not ideal even if the protocol itself is a great fit, though - the currently only stable homeserver implementation synapse is surprisingly resource-hungry even for smaaller servers.. Not something you'd like to run on a raspberry pi or smaller t2/t3 instance. Federation over tor is also not in place yet, so homeserver would either have to be centralized, or federating over clearnet. Clients can still connect over tor, though. I'd happily make it happen on mine if you'd ;like to try it, though!
• Desired qualities from my PoV (anything to consider for Goals? Some of these already look to be fulfilled by your proposal; but it can be good to list them if agreed so it doesn't get lost doen the road):
  • Makers or takers don't rely on a single (or hardcoded list of) Directory Servers but can discover new ones over the network. This is an important part of the censoirship resistance mentioned.
  • Takers don't need to accept incoming traffic (motivation here being to make JM clients for e.g. smartphone apps easy to implement)

The sybil problem is tricky though - how to square censorship resistance wrt makers but still protect against spam of orders killing the network. I've been loosely thinking if protocols like SSB can be used for this but it could be a dead end and I haven't explored the idea deeper.

Even if that last point can't be solved to 100% at the protocol level and #371 is the main construct for it, I think it's still important that the protocol does what it can in that regard

[chris-belcher]

There was a productive discussion about this on IRC: http://gnusha.org/joinmarket/2021-02-18.log

[undeath]

A summary of the IRC log @chris-belcher linked above: a draft for a protocol that is easy enough to implement/deploy while offering a reasonable improvement over the current IRC protocol. This is neither truely decentralized nor perfectly trustless.

Overview:

JM ships with a (fixed but user-modifyable) set of trusted directory servers (DS), run by volunteers. DS don't communicate with each other. Makers register at a DS by supplying a proof-of-stake (UTXO). Takers contact all/some DS, receive back all registered makers and then contact each maker to receive their offers.

Directory Server:

• host onion service to receive requests on
• allow makers to register by providing proof-of-stake, valid for a certain time frame. Suggestion: one month
• expected to keep proof secret (not enforcable) [1]
• expected to not censor makers, mitigated by having several DS
• internally order makers by size of proof to prevent spam, drop "lowest" makers if needed
• distribute list of makers on request (usually by takers)

[1] A huge improvement would be using ring signatures. See taproot (mentioned in the IRC log) and also https://gist.github.com/AdamISZ/52aa2e4e48240dfbadebb316507d0749

Maker:

• host onion service, waiting for taker requests
• send own offers on request
• do coinjoins

Taker:

• connect to DS to receive list of makers (over tor)
• contact makers to receive offers (over tor)
• do coinjoins

Proof of Stake:

Maker sends to the DS:

• utxo
• matching public key
• maker onion identity
• timestamp
• sign_utxo(ds onion identity, maker onion identity, timestamp)

DS verifies:

• utxo validity
• utxo value
• timestamp freshness
• signature validity (by using its own known onion identity)

[chris-belcher]

This whole plan seems to rely on Tor hidden services right now.

Back in January 2021 all tor v3 onions went down for a few days, reminding us that Tor is semi-centralized and that it wont survive in a very adversarial environment. Here are some links on this:

• https://www.reddit.com/r/TOR/comments/kualce/all_v3_onion_addresses_down_after_attack_on_the/
• https://www.reddit.com/r/deepweb/comments/kv1z8o/11_jan_2021_v3_onion_services_should_be_reachable/
• https://darknetdaily.com/?p=1094

The fix used was that Tor heavily weakened their consensus criticality so services would function in the presence of instability in the network: https://gitlab.torproject.org/tpo/core/tor/-/commit/04b0263974c7ad1327e7a193884cf31d55f7949a

So it could be good to think long-term about alternative anonymity dark nets.

Alternative anonymity dark nets

I2P.

As of March 2021 Bitcoin Core also supports i2p, presumably also in response to the January 2021 onion downtime.

https://bitcoin.stackexchange.com/questions/103402/how-can-i-use-bitcoin-core-with-the-anonymous-network-protocol-i2p

However someone on IRC said this about i2p, which doesnt look good for it:

<ircuser> I2P isn't nearly as secure; i2p has no unbroken line of release keys; i2p's main devs went to zcash; major aspects of i2p have been broken for long periods of time; i2p is easily sybil'able; i2p is so unreliable that long-term nodes that have been up for weeks still can't connect to many of the sites inside the network; some of the people who contributed to i2p are straight up horrid people
<ircuser> (left long ago though); i2p depends on code that either can't, or at the very least is VERY DIFFICULT to, be compiled from source and so other safer platforms are essentially barred from running it; i2p documentation for its internal protocols is so shitty that writing i2p support for things is basically impossible; etc.
<ircuser> simple tools and utilities to debug i2p problems are totally hidden and unknown. etc etc etc.

Freenet

I don't know much about this but it's another dark net.

Clearnet server + VPN

Might be appropriate for some people. During the January 2021 downtime people could still access the joinmarket IRC servers over a VPN.

Fundamentally, using the internet anonymously is very hard. If Tor ever stops working then we're in a tough spot.

[kristapsk]

I remember experimenting with I2P IRC (Irc2P) back when we had been left with only one reliably working Tor IRC server for a brief period of time. Had some issues, don't remember details, want to have look at it at some point again. Especially after Bitcoin Core added support for it. Should not hurt as just additional alternative with current multiple IRC server setup, if could get it working with JM bots.

i2p is so unreliable that long-term nodes that have been up for weeks still can't connect to many of the sites inside the network

I think I was having such problems too. Not for a weeks, but definitely long time after starting I2P software. Couldn't get it working using Gentoo wiki guide at all, ended up running manually.

There is also old Feb 2015 newsitem from hackint:

Access from i2p is no longer possible. This is due to the resource hungry i2p software, compared to other parts of the IRC ecosystem, as well as due to very low usage, averaging only about five users. We're sorry for this and hope to remedy the situation in the future; at present, however, due to resource shortage this step has become necessary.

[kristapsk]

Another network likely worth looking at is Nym (currently work in progress).

[xanoni]

This is due to the resource hungry i2p software

This should be much better with the C++ implementation (apt get install i2pd instead of apt get install i2p)

[kristapsk]

About alternative privacy networks, here's some initial research by @prayank23 about CJDNS, GNUnet and Yggdrasil. https://blockchaincommons.github.io/Bitcoin-Camouflage//blog/cjdns/

[chimp1984]

@undeath @chris-belcher

At Bisq we are working on a new Bisq version with a new P2P network codebase. Maybe there is some overlaps in goals...

The main features are:

• Multiple transport types (Clearnet, Tor, I2P)
• Peer management to build a gossip overlay network. Using seed nodes for bootstrapping.
• Distributed data storage for 4 different types of data:
  • Authenticated data (e.g. offers). Only the data creator can remove it.
  • Authorized data (e.g. filter, mediator). Similar to above, but only authorized users can publish such data (e.g. using bonded roles).
  • Mailbox messages: Only receiver can remove the data.
  • Append-only data: Only hash is used for storage. Data cannot be removed (e.g. trade statistics)
• Preparation for PoW based DoS protection (not implemented yet but the layer is already integrated)
• Sending and receiving confidential messages (encrypted, signed messages). Also supports handling of mailbox messages.
• Data retrieval at startup from other nodes
• Support for isolated identities for E2E messaging

Support for network types is configurable. So one user could run only Tor and another could run only I2P and they still could communicate as long there are any common nodes in between which understand both networks (default config). This works by the mailbox message concept. If you send a message to a peer which is not online or has another network type the connection attempt fails. In that case you encrypt the message as mailboxmessage and broadcast it to the network. The peer will receive via the gossip protool the new mailbox message (in our example via the I2P transport) decrypt it and apply the message. If the peer was offline it will request the network data from their peers and if there was a mailbox messge for them decrypt and process it.

The Tor binaries are shipped with the Bisq app so that the user does not need to install Tor. I2P is also started by Bisq if not already running (WIP).

It is still in development but at least the Tor and clearnet transports are pretty stable already.
It is written in Java and the network module could be extracted rather easily from the overall application. Maybe we extract it as library at some point ourself.

Here is a technical overview:
https://github.com/bisq-network/bisq2/blob/main/network/src/main/java/bisq/network/specification.md

General about Bisq 2:
https://github.com/bisq-network/bisq2

[AdamISZ]

Hi @chimp1984

Just so you know, #1182 is implemented and in the latest release, it addresses most of these goals (i.e. the goals laid out in this Issue). See the latest release notes and the docs linked from there for details. It is certainly not pure P2P but rather has a P2P element, pretty much as discussed here.

I agree there could well be some overlap in thinking. DOS resistance is an open issue, I see you have a strategy for that.

[kristapsk]

@chimp1984 I'm wondering couldn't fidelity bonds, as used in JoinMarket, be somehow useful for Bisq? So that pseudonymous identities aren't free...

[chimp1984]

@chimp1984 I'm wondering couldn't fidelity bonds, as used in JoinMarket, be somehow useful for Bisq? So that pseudonymous identities aren't free...

We prefer to stick with PoW as a more fundamental tool to apply costs and its easier to dynamically adjust to the network status.
Another reason is that we prefer to no add dependencies to external systems.

Basic idea is that each message type has a cost factor and each node measures its own load and exchange that regularily with its peers. So if node A wants to send a message m to node B it uses the cost of message m multiplied by the load factor of node B to calculate the required difficulty for the the PoW. Then creates the PoW and attaches it to the message. This is constantly adjusted to the nodes load. E.g. if a node gets dos attacked its load cost rise and sending them still messages will raise the costs for the attacker.
In normal operation the PoW cost should be close to zero to not add unnecessary delays and energy costs.

So for that concept it would be much harder to apply that with bonds which are rather static and cannot scale down to tiny costs as easily.

But we use fidelity bonds in other areas (for a reputation system in a trade protocol context).

[AdamISZ]

I don't know if it's relevant or not; but a few years back when nopara asked me about PoW for SNICKER, I expressed doubts like this: https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79?permalink_comment_id=3135371#gistcomment-3135371

Funnily enough I did actually implement PoW (rudimentary) in the implementation of that system we put in the Joinmarket code (though it was never activated by default and, I think, never used by anybody, so that doesn't help much!).

TLDR I'm quite skeptical about it if there isn't an obvious attacker/defender asymmetry (or perhaps there are two asymmetries and one of them points the wrong way!), but I'm betting you've put quite a bit more thought into it, from what you said :)

[AdamISZ]

But we use fidelity bonds in other areas (for a reputation system in a trade protocol context).

Are you aware of @chris-belcher 's proposal on standardization of these?

BIP draft: https://gist.github.com/chris-belcher/7257763cedcc014de2cd4239857cd36e

Discussion thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020389.html

[chimp1984]

@AdamISZ Thanks for the links!

How well PoW will really protect in case of a motivated attacker is hard to predict.
But the trade-off for the added complexity to having at least some protection seems worth it. As said we have not implemented it yet so I cannot really judge if the complexity is rather limited (as I expect). I think the hardest part is to collect meaningful metrics for the nodes load (number/size of messages, frequency, memory usage, CPU usage,...). Also we use Equihash (memory hard) and not SHA256.

But this use case is focussed on the low level network layer, not to protect offer spam or the like. That is more difficult to protect with PoW (we do it for BSQ swap offers, but its an open question how much it would really help in case of a spam attack). To have some fidelity bond or any financial burden is for sure a much stronger protection in that use case.

Btw. also Tor seems to move in direction. Have not followed updates on it but at least they considered a while back using PoW for dos protection purposes.

Regarding fidelity bonds:
We use burning BSQ (the Bisq DAO colored coin on BTC) which has an advantage over burning BTC as the burned BSQ are kind of a fee payment to the Bisq DAO and therefor a source of revenue. That way we can bake in the fee payment without having explicit trade fees in that reputation-based trade protocol (which is intended for newbies who don't have Bitcoin, so a fee payment would be a hurdle).

[3nprob]

Thanks everyone for the insights.

I'd also be a bit hesitant on adding PoW - may be hard to strike a balance where it both gives practical protection from an attacker as well as not becoming a hurdle for existing nodes on resource-constrained environments (think like an older-generation Raspberry Pi or similar)

Bisq seems to have a bit different parameters there being mostly and manually trading desktop users (base requirements are already higher; latency is less of an issue)

@kristapsk FWIW creator of Yggdrasil is now working on an inspired new protocol for use in Matrix-P2P called pinecone, quite a lot of overlap there as well. FOSDEM talk

Separately, cjdns is now working on PKT (btc+lnd fork for making a bandwidth/route lease market - seems to me like filecoin/pkt <=> ipfs/cjdns ). Supposedly Yggdrasil/Pinecone people are involved there as well.

Bottom note, there seems to be some upcoming momentum in cjdns development and adoption. Could be worth looking at how PKT are doing things but other than that it seems premature to seriously consider integrating with it (considering the separate blockchain and token etc). OTOH Yggdrasil/Pinecone are "more decentralized" and resilient to shifting topologies in absence of "supernodes" or logically centralized lookup (e.g. DHT) than cjdns.

[chris-belcher]

I don't think fidelity bonds are appropriate for bisq.

Bonds work well when one side is very long-running (on the timescale of months). This is because the bonds themselves generally only make sense if the locktime is more than a few months (because any reasonable interest rate will be a few % at most). That just doesn't happen with bisq, both sides of the trade might just be doing that one trade and then never again.

[kristapsk]

Can this be closed as completed (#1182)?

[Fonta1n3]

Has anyone looked at nostr? To me it seems like a great way for makers/takers to communicate.

[kristapsk]

Closing this as resolved by #1182. Additional messaging protocols can be added independently.