blockchain-regulated markets

[synctext]

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

Our previous running code, needs work: http:https://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 : #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:https://tribler.readthedocs.io/en/latest/
• https://dispersy.readthedocs.io/en/devel/
• https://github.com/jarradh/DispersyExample (broken, since a year)

[devos50]

Additional resource: Tribler/dispersy#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:https://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 #2535 (comment) 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:https://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:https://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.

[ghost]

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?

[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:https://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 👍 .