Tribler: blockchain-regulated markets

[synctext]

Marketplace with blockchain based reputation system supporting bid,ask, and cancel messages.

Our previous running code, needs work: http://repository.tudelft.nl/islandora/object/uuid:c1816da8-c82e-47bc-bde2-4f35b9a3e775

[synctext]

• [ ] 0) connectable ! Control of wallet! New message order-match-made
• [ ] 1) orderbook realtime updates. Closed trades, buy/sell bid/ask open orders
• [ ] 2) 'place order NOW' price, amount. Either bid or ask. Calculate estimated average cost, estimate in Euro. Fixed price bid/ask may block, long unfilled state.
• [ ] 3) Close trade, match in orderbook, fill at various price points, incremental settlement.
• [ ] 4) bid/ask rating, filtering, and ranking. Reputation calculation. MarketOfLemmons problem. Score based on 'Temporal PageRank'. Simple threshold score filtering. Rank score to stars. This makes it a blockchain-regulated market?
• [ ] 5) market supply bot. Always sell Delft credits against Bitcoin. Only when having supply. Machine buys computational power. run exit, sell and earn.
• [ ] 6) market making bot. Daily fund of buying Delft coins. Try to be unpredictable for cheaters? Bug bounty program.

[synctext]

Existing literature (no code, just ideas):

• Beaver: A Decentralized Anonymous Marketplace with Secure Reputation
• Measuring the longitudinal evolution of the online anonymous marketplace ecosystem
• TUDelft running prototype code

[synctext]

Economic theory foundation: https://scholar.google.nl/citations?view_op=view_citation&hl=en&user=ZEDUm5UAAAAJ&citation_for_view=ZEDUm5UAAAAJ:2osOgNQ5qMEC

[synctext]

Ongoing 15 pages of decentral markets survey .tex : https://github.com/Tribler/tribler/issues/2535

[synctext]

Related implementation on central server from 2011 that can handle 6 million orders per second on a single thread on a 3 GHz machine.

[synctext]

Getting started with coding:

• PyCharm or something
• http://tribler.readthedocs.io/en/latest/
• https://dispersy.readthedocs.io/en/devel/
• https://github.com/jarradh/DispersyExample (broken, since a year)

[devos50]

Additional resource: https://github.com/Tribler/dispersy/pull/517

[synctext]

The decentral market is now smoothly operational in Gumby:

[devos50]

Gumby experiment link: https://jenkins.tribler.org/job/pers/job/market_experiment_devos50/

Like the AllChannel experiment, this can (should?) become a performance/health indicator for our decentralised market.

[synctext]

Current survey draft. .pdf

Suggestions:

• _15 years_ challenge of _trustworthy_ decentralized marketplaces
• Use historical approach
• add various picture like this into report: "Figure 1: PeerTrust System Architecture"
• make it concrete:
  
  
  
  • either filter bad or promote the good
  
  
  • formula to calculate
  
  
  • how to display reputation (_screenshots_)
  
  

Sections:

• Intro, problem description
• Proposed architectures (5+ pictures)
• Approaches to trust
• 15 years of design sketches
• Roadmap for progress (Ledger,Sybil, engineering effort)
• Conclusions

related work: evolution over past 15 years:

• reputation book from 2010
• multisided markets
• picture with trust model from 2004
• PeerMart from 2005
• Stanford 2016 math model of decentral market
• outdated overview of related work (ftp://ftp.cs.huji.ac.il/adir/users/jeff/amec2004.pdf):

Some of the first research concerned with P2P agent-based marketplaces is that of
Youll [27]. In this work, a framework for an agent-mediated P2P marketplace was
suggested and implemented in Java using a centralized trader registry. Searching for
potential traders is done using an adaption of the Contract Net protocol [5]. The use of
Web Services that are based on standard protocols, e.g., WSDL and SOAP, along with a
decentralized registry implemented over a P2P network such as Gnutella (as suggested
in [17]) seems a more suitable choice for P2P marketplace implementations. The important
issue of traders’ trustworthiness was briefly mentioned in Youll’s work, but not
really handled. Coalitions between traders were not checked. In addition, no simulations
or analysis of experimental results were provided to justify why decentralized
marketplaces might be better than centralized ones.
Another justification for decentralized marketplaces can be derived from [16], where
a P2P-agent double continuous auction was presented. It was shown that such a decentralized
auction displays price convergence behavior similar to that of the centralized
auction. However, the P2P auction outperforms the centralized auction in the sense that
it has a constant cost in the number of message rounds needed to find the market equilibrium
price when the number of traders increases, whereas a central auctioneer incurs a
linear cost in this case. It would be interesting to extend this work and introduce quality
of products or trustworthiness of agents into the simulation.
Turner et al. describe in [23] a P2P resource market where buyers and sellers trade
their surplus resources, e.g., CPU cycles, storage, and bandwidth. They suggest that
each entity in the market might issue its own currency, and propose the Lightweight
Currency Protocol as a standard protocol for the interaction between users and currency
issuers. This protocol might be a building block on top of which P2P marketplaces
could be implemented.
The theoretical work of Neeman et al. [15] shows that when buyers and sellers
are given the opportunity to choose between trading through a centralized market or
through a decentralized one, they would both prefer the centralized option. However,
they assume in their work that a homogeneous product is traded and that the centralized
market incurs no costs. We are interested (by contrast) in the case where the product
traded is not necessarily homogeneous; products from different sellers may have different
qualities. Furthermore, not all trading partners can be assumed to be trustworthy.
This might lead to the emergence of coalitions based on trading relationships, explored
for example in [2].

[devos50]

@basvijzendoorn these tickets seems to have overlap, see https://github.com/Tribler/tribler/issues/2535#issuecomment-260346273 for another table of content.

[synctext]

• first known (distributed) accounting paper from 2002: Policies in Accountable Contracts
• Dated 2003 vision on building trust: Using Trust for Secure Collaboration in Uncertain
  Environments; Please copy this picture in your report - "Figure 3: The framework for one party to a computing interaction. (Large arrows signify data flows, and thin arrows signify control flows."

[synctext]

http://www.the-blockchain.com/2017/02/26/0x-open-protocol-decentralized-exchange-ethereum-blockchain/

[synctext]

ToDo Bas, read and run the code :

• self-replicating code: http://repository.tudelft.nl/islandora/object/uuid%3Aa1b443c7-8b37-4263-ae96-d38bc8b8f397
• this seems to be the bleeding edge code: https://github.com/devos50/tribler/tree/market_community

[synctext]

THE Core economic theory of markets from 1970: https://github.com/dmvaldman/library/blob/master/economics/Akerlof%20-%20The%20Market%20for%20Lemons.pdf

[devos50]

Worked on a first very basic version of a Trustchain credits <-> BTC market in Tribler. I've integrated the Bitcoin wallet and made an API endpoint to get the balance, both confirmed and unconfirmed using the Electrum wallet. Note that the asks and bids are requested using the RESTful API. In addition, when Tribler discovers a new ask/bid, the list in the GUI is automatically updated and sorted accordingly.

TODO (GUI-related):

• make it possible to create a new ask or bid
• wallet management
• transaction history overview
• accepting trades
• cancelling trades? (tentative, requires more work in the market community)

[synctext]

good screenshot. will include it in grant submission for Tuesday.

[devos50]

I've rewritten some of the wallet logic. We now support more than one wallet and each wallet has a short identifier. The main idea is that we have various wallets that holds assets, i.e.:

• Trustchain reputation wallet
• Bitcoin wallet

More wallets can easily be added in the future.

Also, some of the API endpoints have been rewritten. One can query all the wallets available with a call to GET /wallets. This returns a list of identifiers of each wallet (i.e. btc and mc). Each wallet has various methods that should be implemented:

• get_identifier
• get_balance
• transfer (TODO)

This allows us to get rid of the PaymentProviders in the current decentralised market code and use wallets that are integrated in Tribler instead.

Finally, the GUI has to be redesigned slightly to support multiple wallets and multiple assets.

[synctext]

Good progress. If now API access is hacked, wallet access is possible. Needs to be hardend.

[basvijzendoorn]

Privacy of Traders problem description
https://www.sharelatex.com/project/58c7d6390d2b81b36b2736a3

[synctext]

0) connectable ! Control of wallet! New message order-match-made

@devos50 critical above item slipped of the roadmap. We need to detect if peer is connectable. Everything assumes full connectability.

[devos50]

A small update here. Last week, I've been working on writing a big integration test that tests the decentralized market from ask/bid dissemination up to and including making transactions (with real bitcoin!). This works well and the Jenkins job can be found here: https://jenkins.tribler.org/job/pers/job/market_community_btc_credits_test/. The wallets used in this test are encrypted.

In addition, I've spent some time improving the incremental payments system. Also, I've included a bloom filter in each introduction request so the order books are synchronized between two users. This addresses bootstrapping problems since we have no persistency of orders in our market.

Also, the timeout mechanism of asks and bids has been fixed and I've added an event so orders are dynamically removed from the GUI. This all works pretty neat.

@synctext regarding the connectability of peers, I rather implement a generic check in Tribler for this since there might be more components in the future that requires connectability. Do you agree if we just disable creating new orders and display a warning if a peer is not connectable for a first iteration?

[devos50]

BTC <-> Tribler reputation can now be exchanged without problems. In addition, I've added support for trading between multiple wallets, like a real currency exchange. This means that we can also add more types of wallets later.

[devos50]

Existing decentralized solutions:

• augur (prediction market)
• openbazaar (more an Ebay-like marketplace)
• Mercury (seems dead and very basic, https://github.com/mappum/mercury)
• waves (http://www.wavesplatform.com/downloads.html, they use a centralized clearing house for matching, matching as a service)
• bitmarkets, this one is quite similar to what we want but they have no reputation mechanism. I tried to get it working on my machine but syncing the order book is taking quite long and it also gave an error in the process.
• Bitsquare (https://bitsquare.io)
• Beaver (https://eprint.iacr.org/2016/464.pdf, no implementation and they use proof-of-work)
• BitShares (https://bitshares.org)
• BarterDEX (https://supernet.org/en/technology/whitepapers/barterdex-a-practical-native-dex) - no code yet, only the white paper
• Tesseract (https://eprint.iacr.org/2017/1153.pdf)
• NEX (https://neonexchange.org/pdfs/whitepaper_v1.1.pdf)
• Loopring (https://github.com/Loopring/whitepaper/blob/master/en_whitepaper.pdf)
• Etherdelta (https://etherdelta.com)
• KyberNetwork (https://home.kyber.network/assets/KyberNetworkWhitepaper.pdf)

Comparable centralized solutions for cryptocurrency trading:

• Coinbase (https://www.coinbase.com)
• Kraken (https://www.kraken.com)

More related work:

• an overview of flaws of 0x, EtherDelta and DEX design in general: http://hackingdistributed.com/2017/08/13/cost-of-decent/
• https://media.consensys.net/introducing-swap-a-protocol-for-decentralized-peer-to-peer-trading-on-the-ethereum-blockchain-d4058f3179cf
• https://www.youtube.com/watch?v=0Bzwayom_iA&feature=youtu.be
• https://0xproject.com/pdfs/0x_white_paper.pdf (P2P token trading protocol)
• http://www.ifex-project.org/our-proposals/ifex/2012-04-11-partial-draft
• http://infoshako.sk.tsukuba.ac.jp/~naoki50/veszteg.pdf (real-world evaluation of a decentralized market!)
• https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2785626 (on the business case of blockchain markets)
• http://web.stanford.edu/%7Eleinav/pubs/AR2016.pdf (math model of a P2P market)
• https://www.reddit.com/r/ethereum/comments/424r34/what_is_the_point_of_a_decentralized_uber_or/
• https://www.smithandcrown.com/sale/arcade-city/
• http://www.the-blockchain.com/docs/LaZooz%20Blockchain%20Taxi%20Whitepaper.pdf

(decentralized) matching:

• http://authors.library.caltech.edu/65543/1/an%20experimental%20study%20of%20decentralized%20matching.pdf (they used real people and observed their behavior, still quite different from what we do).
• https://www.econstor.eu/bitstream/10419/118137/1/NDL2003-114.pdf (theoretical)
• http://web.stanford.edu/~niederle/DecMarOpenAligned.pdf (math warning!)
• http://www.repository.utl.pt/bitstream/10400.5/2627/1/wp122006.pdf
• Effect of the Degree of Neighborhood on Resource Discovery in Ad Hoc Grids (made in Delft :)
• https://www.researchgate.net/profile/Huerevren_Kilic/publication/4253650_An_Investigation_about_Process_Matchmaking_Performances_of_Unstructured_and_Decentralized_Digital_Environments/links/09e4150b4dad9a3241000000/An-Investigation-about-Process-Matchmaking-Performances-of-Unstructured-and-Decentralized-Digital-Environments.pdf
• https://research.vu.nl/ws/portalfiles/portal/2449401 (this one is very related to what we do)
• http://ieeexplore.ieee.org/document/4233684/

This video explains why it's hard to build order books on the blockchain. I should note that they assume a "traditional" blockchain with proof-of-work consensus which causes latency and thus possibilities for market/order manipulation.

• (not very related but still fun): https://matchpool.co/wp-content/uploads/2016/12/Matchpool_Whitepaper_221216.pdf, "There is a tendency in blockchain development and systems design to lean heavily on boilerplate notions of “reputation” and “incentives”, while ignoring the fact that reputation is a complex, emergent property of other people’s subjective impressions and market decisions."

[devos50]

Must-read related work: http://www.econinfosec.org/archive/weis2014/papers/Clark-WEIS2014.pdf

[Jaapp-]

Beta testing branch market_community: no tracebacks and able to do some trading.

[MitchellHop]

able to create negative balance on my Tribler reputation credits. We conducted a collusion attack on the live network. We did several back and forth transactions to create an endless amount of reputation. Note the -1*10^12 reputation in the screenshot below.

[devos50]

Nashx: "NASHX is about enabling two untrusted parties to make safe exchanges online by putting them in a Mexican standoff. We put two untrusted parties into Nash equilibrium, through a military strategy called Mutually assured destruction so that neither party has anything to gain by scamming one another." (http://nashx.com/About)

They use a neat strategy but not decentralized. Also nice to read about http://en.wikipedia.org/wiki/Mexican_standoff and http://en.wikipedia.org/wiki/Mutually_assured_destruction :)

[devos50]

When running some experiments on a larger scale, it turned out that there were still some errors that occurred in very unlikely circumstances. It took me quite some hours to hunt these down and fix them since I had to go through many MBs of log files.

The experiment now seems to function as it should and I'm ready to extract the first graphs out of it.

[devos50]

First (very preliminary) results with an order book where the Google stock symbol is traded:

Note that the total quantity traded is barely affected when the network size increases. This is a promising result but the order book itself does not generate a very high load on the network. I will try with another order book that generates more traffic to see what happens.

[devos50]

TODO:

• [x] come up with a model to reconstruct an Uber dataset to a limit order book trace
• [x] ~make sure the market can handle any asset trading. This is slightly different from what I've implemented right now since it's not possible to define more complex matching rules (for instance, an Uber-like marketplace).~ not feasible to implement this since it requires major refactoring. For now, we can adjust the matching algorithm in a very basic manner.
• [x] implement a decentralization "fuzziness" (amount of matchmakers should be configurable, in fact, this is third-party matching)
• [x] write one page related work
• [x] write one page about the existing results

Progress: https://www.sharelatex.com/project/594baae7e341f31a47fc0a13

[devos50]

Update: first experiment with a third-party matchmaker succeeded, time to scale this up and test it better. In the image below, node 1 is the matchmaker that matches node 2 and 3 who have created an ask and bid respectively.

[devos50]

Taxi experiment using a real-world Uber dataset up and running: https://jenkins.tribler.org/job/pers/job/taxi_experiment_devos50/.

[synctext]

Related work bitsquare decentral market:
Redundant data storage (flooded to all peers) and
Resistant against spam/flooding
So please copy or try to understand their magical solution

[devos50]

First initial results of taxi-simulation using the market:

[devos50]

After considerable effort, I managed to compile and run bitshares on the DAS5 (so we can compare it against our own implementation). I had to compile my own version of GCC, OpenSSL, CMake and Boost but it seems to work now.

[devos50]

After some thinking, I feel that that the we are not really using the power of (our) blockchain (TradeChain) in the market implementation. Instead of using TradeChain as a post-market ledger, I envision it to be the core component of the market, used to account all ask/bid/order cancels, transactions and payments. In this scenario, the market becomes properly blockchain-regulated (or blockchain-powered I guess).

There are various advantages of doing this, the most obvious one being that all operations in the market become tamper-proof and irrefutable (this is already a property of the decentralized exchanges I’m comparing with, i.e. Waves and Bitshares). Making TradeChain an essential component in the market helps to make a more fair comparison with other blockchain-based exchanges. Another advantages is that we can combine gossiping of the blockchain and order synchronization between peers (currently, these are two separate processes, leading to increased communication costs). Finally, it provides more transparency since all market manipulations are recorded on TradeChain.

The only problem I foresee here is that some operations recorded on the TradeChain do not involve a transaction counterparty, for instance, cancelling one of your own orders. As a consequence, the block that captures the order cancellation only contains one signature, namely your own. To ensure entanglement, I propose to use one of the matchmakers as “witness node” that verifies that you have cancelled the order.

I think we have a strong platform to sell after we make TradeChain our core component: decentralized and scalable matchmaking, irrefutable and transparent transactions, zero transaction fees and near-instant clearing and settlement.

@synctext do you agree with this?

[devos50]

Got the experiment with the Waves platform completely working: https://jenkins.tribler.org/job/pers/job/waves_experiment_devos50/57/. However, it seems that they use a centralized matchmaker server so it's not as decentralized as they claim. Transfer of value is recorded on a global blockchain however. Also, for every new buy/sell order, a small transaction fee has to be paid to the matchmaker.

[devos50]

The Bitshares market is now also fully functional within Gumby (up to the point where I can make buy and sell orders): https://jenkins.tribler.org/job/pers/job/bitshares_experiment_devos50/116/. We are now ready to compare our implementation against these markets 👍

Next focus will be the refactoring of the market to make TradeChain our central component.

[synctext]

more related work, social markets: https://thenextweb.com/contributors/2017/08/29/can-blockchains-replace-retail-giants-like-amazon-ebay/#.tnw_tyPxx71b

[synctext]

Another ICO {scam} exchange market with low/no fees: https://bitcointalk.org/index.php?topic=2091630.0
Ready for business: 2019 :-)

[devos50]

Related work: https://ico.wcex.co/whitepaper?lang=en (centralized but low fees)

[devos50]

On the Impossibility of Fair Exchange Without a Trusted Third Party shows that it is impossible to facilitate a fair exchange without a TTP being involved. This is the reason why incremental payments should be used. Filecoin uses a similar philosophy, however, they consider this as future work while we have full support for incremental payments and transaction recording.

[synctext]

Bitcoin Historical Data - Bitcoin data at 1-min intervals from select exchanges, Jan 2012 to May 2017 and other datasets at that site.

[devos50]

Now that the market is functional and the first emulation results are available, I will focus on improving the security of our platform. This includes a (basic) defense against the Sybil-attack using Temporal Pagerank. The unique property of Temporal Pagerank is that it incorporates the notion of time. The temporal aspect is often disregarded when we consider defenses against the Sybil attack (see Exploiting Temporal Dynamics in Sybil Defenses). The structure of our transaction ledger (TradeChain) is used as input for this algorithm. It has been proven that Temporal Pagerank is resistant against historical Sybil attacks. Additionally, it is computationally cheap.

At this point, the algorithm has been implemented and integrated in Tribler (PR will be opened soon) and the performance of the mechanism will be evaluated using a real-world dataset.

[devos50]

The paper Bazaar: Strengthening user reputations in online marketplaces describes a novel technique to determine transaction risks in an online marketplace. The key idea is to create a _risk graph_ and perform a max-flow computation on it from a specific buyer to a seller to asses whether a transaction should be flagged as _fraudulent_ (or high-risk). Since max-flow computations is an expensive technique, they split up the complete graph into multiple, smaller graphs in a smart way. This provides a speedup of around 3x.

Their experiment is based on scraped eBay data, containing millions of purchases. The algorithm is driven by user-feedback where new feedback, either positive or negative, modifies the risk graph.

[devos50]

After a bit more research I realized that the problem is not about sybil _detection_ but rather about sybil _prevention_. Temporal Pagerank is not designed to detect Sybils since they are not guaranteed to be assigned a lower trust score than honest nodes, however, the effects of a Sybil attack on reputation are limited (but not as strong as NetFlow).

Fortunately, Temporal Pagerank is an asymmetric reputation system since it's personalized (the random walk starts from the set of your own half-interactions). This is beneficial since it has been proven that symmetric reputations mechanism cannot be Sybil-proof. Examples of symmetric algorithms are EigenTrust and regular PageRank.

I've considered various dataset to evaluate Temporal Pagerank, however, there have been some issues:

• most datasets do not have a ground truth and a true classification of Sybils/non-Sybils. This includes almost all dataset described in Sybil-detection algorithms (mostly social network graphs).
• Temporal Pagerank needs, as the name implies, a total order on the interactions. Unfortunately, all datasets I've seen are void of temporal information (this includes the dataset with 8000 fake twitter followers).
• it is beneficial to use a graph with weighted edges, however, only a few dataset have this property.

While I agree that using a social network dataset is nice, it lacks some desired properties that make Temporal Pagerank work. Additionally, I don't want to derivate much from the domain I've been exploring (peer-to-peer markets) so for now, I propose that I use my own scraped dataset with eBid transactions. This dataset contains 246.181 transactions, created by 13.955 users. Each transaction has a value (so it's a weighted graph) and a timestamp (so the set of transactions is ordered). So it contains all the properties we want and it's data from an e-commerce platform.

Next step is to perform a small (local) experiment with just the reputation algorithm to see how much influence Sybils have on their ranking (similar to the method described here). Next, we can emulate the market on the DAS-5, with crawling, and perform a Sybil attack to see how it works in a complete environment with nodes crawling the TradeChains of others.

[devos50]

I just realized that NetFlow will not work for computing reputations of traders. Imagine a transaction between user A and B where a total value is exchanged of 20 dollars. Now, this is represented as an edge from A -> B and with an edge from B -> A with a weight of 20. However, when performing the first step of the NetFlow algorithm, the capacities of all new edges will always be zero (since the maximum flow from A -> B is the same as the maximum flow from B -> A) and as a consequence, the final trust scores of all agents will be zero. In fact, NetFlow is based on inequality between consumption and contribution.

Update: this also holds for the BarterCast algorithm.

[devos50]

I've performed a few experiments with Temporal PageRank. First, I've rerun the experiment of Pim where he determined the computation time required for the algorithm. Instead of running it once, I've averaged the results over ten runs. We use the scraped data from eBid (described in one of my previous comments). The horizontal axis shows the total amount of transactions in the graph and the vertical axis the computation time. The results are shown for the preparation time of the data structure and the actual computation time for Temporal PageRank. We see that Temporal PageRank is a feasible algorithm, even for a graph with many traders and transactions.

However, a more interesting question is _how much reputation Sybil attackers are able to gain with Temporal PageRank_. To determine this, we perform an artificial Sybil attack as follows: first, we pick 100 random nodes who will become attackers. Each of these attackers introduce a varying amount of additional Sybil nodes and initiates a transaction with a value of 1.000.000 with this Sybil. It has been proven that this gives the maximum amount of reputation to an attacker. We consider different amounts of additional Sybils introduced; 1, 2, 3, ... 10. We are interested in the average increase of PageRank score and rank by attackers when they perform a Sybil attack (this metric is used by most papers I've found that evaluate Sybil Attacks on PageRank). We consider three (related) reputation mechanisms: PageRank, Personalized PageRank and Temporal PageRank. The results of this experiment are shown in the following figures. As we see, Temporal PageRank is more resistant against Sybil attacks than the other two algorithms (yay!).

[devos50]

I was thinking a bit about the current implementation of the decentralised market in Tribler. While it's working (https://jenkins.tribler.org/job/pers/job/market_experiment_devos50/732/) and contains an implementation of the Temporal Pagerank algorithm, next point of actions can be the following:

• global consensus on TradeChain records with CHECO. Since CHECO uses protobuf message serialisation, I argue that this, if we decide that we want to have this on top of TrustChain, should be implemented in the IPv8 library. I found out that there are some issues with CHECO if we want to implement this in a Tribler-like system (including transaction spam) but I will post these elsewhere since they are not relevant for this ticket. Note that global consensus is a must if I want to compare our market with other existing solutions like Bitshares, WAVES and/or OpenLedger, to ensure a fair comparison.
• solving transaction spam - Bitcoin and many other systems solve this with transaction fees which is undesirable for our market since it is built with the vision of having zero transaction fees. We might be able to exploit witnesses (witnesses are used to co-sign a TradeChain record that creates a new order), which are capable of refusing to sign a record that creates a new order in the market. On the other hand, users are able to simply create a new digital witness identity and use that identity to enforce a new order in the market. This might be addressed by introducing a separate reputation for witnesses?
• improve scalability with incremental Temporal Pagerank

[synctext]

ACM publication related work: decentralized blockchain-based electronic marketplaces. Discussion at YCombinator.

Very naive flow diagram, real inter-continental trade lanes are extremely difficult to track. Which person do you trust to track container contents in Singapore, Taiwan or Shanghai? Who is to blame for breakage?

[synctext]

Related work on market for labor and tasks:
"This article will provide a theoretical compass to assist in navigating the reinvention of the company. In the same vein, the seismic movements that have fractured the firm, hence redrawing labour law’s borders will be investigated. The exploration is organized as follows. First and foremost, attention will be devoted to the doctrinal debate on the fragmentation of the firm and the decentralisation of the production cycle. "
The Invention of the Future. Does ‘Platformisation’ Redefine the Notion of the Firm?

[devos50]

Bitshares live exchange (https://wallet.bitshares.org/#/explorer/blocks):

[synctext]

Really decentral related work? https://github.com/KomodoPlatform/BarterDEX "The Komodo security services are performed by notary nodes"
Docs: http://barterdex.readthedocs.io/en/latest/faq.html#how-to-get-listed-on-barterdex
cost: also called the taker fee. This is about 0.15%

[devos50]

I've listed BarterDEX already in my related work comment. At that time, there was no code. It seems that there's a beta available now. Their technology heavily relies on atomic swaps, a feature that requires BIP65 implemented. While this ensures that exchange of currencies is either executed or not at all, its functionality is limited to trading of cryptocurrencies.

Browsing a bit through their documentation, I found this comparison between state-of-the-art DEX platforms (the last row is quite arbitrary chosen):

I will try to get some more information about their decentralized matching algorithm. Curious to know how they implemented that.

[devos50]

They haven't done any scalability experimentation at all, after reading through their whitepaper. Also, some statements they make, are fuzzy:

With 100 full nodes, thousands of non-relay nodes can be supported, possibly tens of thousands, though that number has not been reached in practice, so we will have to wait and see what the real world limitations are.

... In practice, we are seeing the nearly instantaneous response when all the parameters are properly met.

[devos50]

I compiled BarterDEX and got it running on the DAS5, it's ready for some experiments 👍

[devos50]

Extracted from the IDEX whitepaper:

Due to the competitive nature of the space we are not revealing the exact proposed method for decentralizing the orderbook at this time

Also, according to the whitepaper, their distributed order book will be live in Q3 2018.

Even more fantasy and dreaming from their main project, Aurora (https://auroradao.com/assets/Aurora-Labs-Whitepaper-V0.9.5.pdf):

In addition to guaranteeing open access, operating the infrastructure in a distributed manner brings many additional benefits. [...] Additionally Aurora will be able to access computing power for the best rates possible. It is conceivable that Aurora will eventually incorporate machine learning algorithms operate an AI banker. Operating on a distributed network would give Aurora access to a lot of cheap computing power.

[synctext]

Epic text!

[devos50]

I might have fried the DAS5 cluster at the VU but I managed to reach over 30.000 trades/sec.

The following graph gives the relation between the total number of traders in the network and the average global throughput in trades per second. Each trader trades with another trader at a rate of 20 trades/sec, for a period of 30 seconds. The graph is made after optimizing the code and storing all Trustchain records in memory such that lookups are _very_ efficient.

Also, the graph strongly suggests horizontal scalability.

[devos50]

Repeated the OpenRide experiment, here are two rough plots (still needs some polish and I'm running it more times so I can add some error bars). During the experiment, I differ the broadcast settings, in particular, the fan-out _f_ and _TTL_. So when using _f = 10_ and _TTL=2_, each new ask/bid order reaches 10 + 10^2 = 110 nodes. As we see, lower values of _f_ and _TTL_ lead to suboptimal efficiency, in particular in the situation where _f = 5_ and _TTL = 2_. Also, note that increasing the broadcast range further doesn't really improve the matching efficiency anymore.

Average bandwidth usage per network participant:

[synctext]

https://en.m.wikipedia.org/wiki/Myerson–Satterthwaite_theorem
"there is no efficient way for two parties to trade a good when they each have secret and probabilistically varying valuations for it, without the risk of forcing one party to trade at a loss."

[zilveer]

Don't forget Bitbay #BAY (Bitbay.market which is also a decentralized market with smart contracts.

[devos50]

I now have a trading bot running on the market testnet, which periodically (every 35) creates an order, alternating between an ask and a bid. See here for the latest orders of this node. Note that these blocks are not dual-signed since they are source blocks (and can have any counterparty). I will run this overnight to see whether things work as expected.

Next step: add a second node to the testnet and let these two bots trade.

[synctext]

Nice! This could be the V7.2 key feature. A testnet wallet auto-activated and instant live animation would be cool TorrentFreak promo points.
Gigachannel feature will not be fully usable and have gossip updates for 7.2.

[devos50]

After some major refactoring, matchmakers no longer reserve some quantity in their order books when matching. Instead, any conflicts should be resolved between the two trading parties.

The motivation behind this change is that I noticed during my experiments that matchmaking becomes very inefficient if assets are reserved. By avoiding the reservation of assets in the order book, the same order can be matched against multiple other orders and a match message will be sent to all identities behind the matched orders now. Intuitively, this should lead to better matching efficiency but I should validate this with some experiments on my order datasets.

[synctext]

Lots of related work appearing. As discussed indeed 1 common theme. We need reputations, we are not working on it, and concrete plan is lacking.
https://hackernoon.com/dharma-protocol-tokenized-debt-and-funding-through-decentralized-systems-384527f1a75d

[devos50]

Since our market is mostly accountability-oriented, I think a reputation system is a valuable addition and a natural extension of this line of work.

[synctext]

Sorry, to clarify: common theme on these white papers: they have no reputation system, they critically need one, and are delaying work on it. Fundamental science: universal reputation system.

[synctext]

https://www.mariuszoican.org/blog/smart-settlement-on-the-blockchain

[synctext]

phd thesis outline, outcome of discussion:

• architecture of decentral marketplace and components (material finished, unpublished)
• matching of orders in decentral bid/ask orderbook (under submission)
• real-time clearing and settlement (Internet-of-Money at IFIP networking)
• accountability: using append-only individual ledgers (trustchain Journal by Martijn with contributions from Pim, Brusee, Veldhuisen)
• final chapter:
  
  
  
  • high impact topic
  
  
  • exposure for lab?
  
  
  • experimental validation, architectural validation, deployment results, experimentation and validation?
  
  

[devos50]

After (almost) a week of work, I have the following progress:

• Setup a standalone repository that stores all code related to the decentralised market, AnyDex.
• Setup some basic CI that runs when a new PR is made against the master branch.
• Merged my recent work of the last month regarding order matching into the main repository. As a result, matchmaking has superior scalability, fault tolerance and resistance against malicious matchmakers now. I consider the matchmaking algorithm finished.
• Updated Gumby to support experiments with Python 3. Specifically, it can now build a venv with Python 3 and run the AnyDex validation fully with Python 3. Not sure about any improvements regarding speed so far.
• Updated the IPv8 infrastructure to support Python 3.
• Worked on a first GUI prototype, based on HyperDEX.

Next, I will focus on some fundamental issues, namely counterparty fraud detection and improved trade accountability. Hopefully, I can make some progress with the GUI next week, and setup some unit tests for the REST API.

[devos50]

I think the issues raised in this ticket have been sufficiently addressed with the deployment of AnyDex and our upcoming journal article 👍 .