Scaling the P2P network: enable order gossip

[kilrau]

From the original issue: https://github.com/ExchangeUnion/xud/issues/1219

Current status:

Lightning’s protocol as a model for xud: The Lightning code implementation (in Go) is clear and has some anti-abuse features. Like Bitcoin, Lightning uses a hybrid push/pull gossip protocol, i.e. every node can both push updates to peers and request updates from peers. Lightning only gossips between peers that it has an open channel with, so xud’s situation is not identical unless trading occurs in small “walled garden” cliques or member nodes are configured to trade with only a select group of nodes in some other way.

Attacks we need to worry about: “An eclipse attack is when most (if not all) of your peers are malicious and they basically prevent you from being well-connected to the network to obtain information about transactions you're interested in. An eclipse attack is particular useful when a payer has sent some Bitcoins to you in some transaction, then decides to also doublespend the same Bitcoins. The doublespender (or payer) will use the eclipse attack to prevent you from knowing that there is also a doublespend transaction out in the open, so you get misled into believing that there's only the original transaction.

A sybil attack on the other hand is where a malicious actor is trying to spam the network with nodes that they control attempting to subvert the network's reputation system. For example, false signalling of support using version bits.” [https://bitcoin.stackexchange.com/questions/61151/eclipse-attack-vs-sybil-attack]

In order to prevent eclipse attacks we should use a stochastic address manager like Bitcoin’s. This is separate from the gossip protocol; it determines only which peers to gossip with, not how.

Information we want to gossip: order updates (lots) peer updates (fewer)

Unlike Bitcoin’s gossip protocol, which provides a lot of functionalities e.g. serving blocks, we only need to gossip of these two types of data.

The website says that xud provides “A global order book amongst exchanges combines and improves liquidity in the market.“ If we want to provide a global order book then we cannot employ a walled-garden system so that peers only gossip with a trusted set of trading peers.

Currently xud already gossips about orders and peers. This means that replacing xud’s fully connected broadcast network with a scalable alternative is simply a matter of preventing xud from updating all peers, i.e. only sending updates to the cryptographically-random bucket of peers selected for this round by the address manager. This is as simple as adding a helper function call to the relevant event emitter functions in Pool.ts and OrderBook.ts.

Fortunately, I have worked with the address manager in the past (network enumeration and security testing in 2014) so I am familiar with Bitcoin’s addrman.h. We would basically just have to port this algorithm to TypeScript and plug it in to the live system, it would not break backward compatibility with previous xud versions using the original full connectivity (those nodes would just still be sending to the entire network upon every update).

Bitcoin address manager: "Design goals:

* Keep the address tables in-memory, and asynchronously dump the entire table to peers.dat.

* Make sure no (localized) attacker can fill the entire table with his nodes/addresses.

To that end:

* Addresses are organized into buckets.

  * Addresses that have not yet been tried go into 1024 "new" buckets.
  * Addresses of nodes that are known to be accessible go into 256 "tried" buckets.
  * Bucket selection is based on cryptographic hashing, using a randomly-generated 256-bit key, which should not be observable by adversaries.
  * Several indexes are kept for high performance. Defining DEBUG_ADDRMAN will introduce frequent (and expensive) consistency checks for the entire data structure.

The address manager also keeps track of when each peer was last heard from. Timestamps are only updated on an address and saved to the database when the timestamp is over 20 minutes old.“ Source

Proposed new order format: https://github.com/opendexnetwork/opendex/issues/22

[hatmer]

Here is a design document for the project so far. Contributions welcome.

[initCCG]

If it's feasible, could you create a proposal for the Bisq DAO to integrate its app into OpenDex, with an estimate how much it would cost to code?

[BitcoinOG]

PR implementing this: https://github.com/opendexnetwork/opendexd/pull/6