A trustful blockchain-based token economy to prevent bandwidth free-riding

[devos50]

This issue will be the main discussion place for our ongoing project: "A blockchain-based token economy to prevent bandwidth free-riding" (the title is open for discussion). The basic idea is to create a micro-economy within the Tribler platform for earning, spending and trading bandwidth tokens. This brings together various research topics, including blockchain-powered decentralized market, anonymous downloading and hidden seeding. Trustworthy behavior and participation should be rewarded while cheating should be punished. A basic policy should prevent users from selfishly consuming bandwidth without giving anything back. This directly addresses the tragedy-of-the-commons phenomena.

Our initial release should provide basic primitives to earn, trade and spend tokens. Our work could be extended with more sophisticated techniques like TrustChain record mixing, multiple identities, a robust reputation mechanism for tunnel selection, global consensus and verifiable public proofs (proof-of-bandwidth/proof-of-relay).

High-level overview:

Initial architecture diagram:

Related issues:

• (anonymous) payouts: A State-based CRDT without Infinite Growth #2571
• earn bandwidth tokens: Operational credit mining branch, Gumby scenario and multichain #1842
• spend bandwidth tokens: Perfect Darknet Roadmap Ticket #3
• trade tokens: blockchain-regulated markets #2559
• small-scale mining pool: TORrentcoin #3326

Related work:

• joystream (http:https://joystream.co)
• privatix (https://privatix.io) - an ERC20 bandwidth token on top of the Ethereum blockchain. Their project has no code and a rather weak whitepaper.

Open tasks (subject to change):

Must have:

• Token Mining. Earn tokens by donating bandwidth. Credit mining effortlessly converts idle bandwidth into tokens. The mining boosts the health of the network. Underseeded swarms and popular swarms are identified and helped out. Dead swarms and spam are correctly dealt with. Users need to select a channel with content to boost. This signal from the user prevents spam. In a later stage we will auto-boost swarms in general (implemented in Refactored Credit Mining #3390 by @egbertbouman).
• Token mining by relaying Tor-like encrypted traffic (implemented in Implemented tunnel payouts #3492).
• Get tokens for hidden seeding and being an exit node (implemented in Implemented tunnel payouts #3492).
• Market. Sell and buy on our integrated decentralised marketplace. Convert bandwidth tokens into Ethereum or Bitcoin. Your karma as a merchant grows with each successful trade. Part of our Internet-of-Trust research (Various bug fixes and improvements for the market #3502).
• Coin wallet. Move coins between a Tribler PC and Android devices. Offline storage inside Android smartphones. Transfer securely and effortlessly using simple QR codes without the need for Internet access. Focus on the "you can see it, you can spend it" security model (implemented in One-way communication offline funds transfer using QR-code #3358).
• Basic verification experiment on DAS5. To verify the correctness and get initial result about the effectiveness of our bandwidth tokens, we should set up a basic DAS5 experiment that incorporates and tests all of the tasks above. (I've set up my own testnet with exit nodes, a tracker and Tribler runners on our Proxmox servers)
• Basic freeride policy. When downloading, freeriders (users with a negative bandwidth token balance) should get lower priority until they have restored their balance again. See also Free-ride policy: give users with lower token balances less priority at the exit nodes #3573

Should have:

• Write a reliable TrustChain crawler so we can get a dataset. It is important to get an overview of our network and activity, therefore we need a reliable crawler. Implemented in Changed TrustChain so it's a single chain instead of multiple fragmented communities #3572: this crawler crawls from the genesis block onwards and tries to fill any gaps in trustchains when it can.
• Double-spend detection of TriblerChain records. A Client should be able to detect whether a malicious user has reused his prior records and keep a list of such events. Tribler should be able to act accordingly with users that (recently) performed a double-spend, like refusing services to them for a few days (ON HOLD: Double spending prevention using Secp256k1 keys on TrustChain py-ipv8#68).

[devos50]

@synctext I've 'refactored' this issue as we discussed last week.

[devos50]

I've verified the basic setup using an isolated exit node, an isolated Dispersy tracker and a single Tribler instance, that anonymous downloading is working well and the exit nodes are paid correctly. I will now scale up the experiment and add more nodes. This allows me to explore a basic freeride policy, in the case of oversupply and undersupply.

[devos50]

After #3502 is merged, the market is production-ready 👍

[synctext]

"Our live token economy: measuring and mitigating real-world attacks"
Detection of fraud on our live network and attacking our own network with live Sybil attacks could be The Big Next Paper... Cue "incremental personal PageRank". Merge trust of barter, voting, and trade transaction graphs.

[devos50]

Small game fallacy: http:https://unenumerated.blogspot.com/2015/05/small-game-fallacies.html?m=1

[devos50]

Current status:

• TrustChain has been extended with a block type and a timestamp.
• a TrustChain crawler is setup and running to fetch blocks created on the testnet. See https://github.com/devos50/py-ipv8/tree/trustchain_crawler for the code.
• an explorer has been setup to make it easier for me to debug what happens on the network. See http:https://130.161.119.212 (this only shows block on the testnet).
• worked on a testnet with some dedicated tunnel helpers.

I think the code is ready for an experimental release. I will do some more testing and work towards structural end-to-end testing on our testnet network. This also allows me to analyze the efficiency of our scheduling algorithms at the exit node/relay nodes and get some insights into the efficiency of our free-rider prevention mechanism overall.

[devos50]

Now that direct payouts are working (see #3776), I will focus on end-to-end integration experiments. I will start building these experiments in isolation but eventually, they will join the TrustChain testnet. Scientific goal: experimentally prove that free-riders are allocated less resources at exit nodes/relays.

[ichorid]

Oops, misclick on the Projects page... 🤕

[devos50]

Proof-of-Work as Anonymous Micropayment: Rewarding a Tor Relay

In this work, the authors propose a mechanism to reward Tor relay nodes, based on Proof-of-Work requirements by cryptocurrencies. Tor clients obtain Proof-of-Work shards and can turn them in later for preferential treatment.

They also propose a hierarchical token bucket algorithm to ensure QoS for "free" and "paying" clients. This is related to our slotted mechanism implemented in relay and exit nodes.

[synctext]

Thesis final chapter brainstorm (updated with estimated importance to the lab as a whole):

1. Trustchain: measuring the emergence of trust in Markets, Money, and Media.
   (e.g., trader reputations and/or advanced exit node rejection policies).
   (or shorter: Trustchain: measuring the emergence of trust)
2. Trustworthy decentral exchange market for bandwidth tokens
   (or broader: for bandwidth tokens and cybercurrency)
3. Trustworthy blockchain-based decentral markets
4. BTC-ETH: Global decentral marketplace for cybercurrency
5. Comparing numerous blockchain solutions (including EBSI)

[devos50]

Final thesis chapter idea (as also briefly discussed yesterday): Tribler: 15 years of research on managing the Internet commons. Also, see here. This will be a journal paper, suitable for a single-blind review policy.

What problem did we solve? We design, implement and evaluate a fully decentralized infrastructure to address free-riding behaviour in shared-resource systems, oriented around three key components: community accounting, reputation mechanisms and resource allocation. These three components together are capable of detecting fraudulent behaviour, e.g., record withholding and the Sybil Attack.

Key contributions:

• The system architecture of Tribler, our infrastructure for tragedy-of-the-commons experimentation.
• A light-weight, scalable accounting mechanism for community contributions, resistant against record withholding and manipulation.
• Large-scale experiments, exploring the effect of different reputation algorithms and scheduling policies under different treats.
• A longitudinal deployment trial, involving over 80.000 Internet users, demonstrating that Tribler effectively detects and punishes free-riding behaviour.

[synctext]

Related work on decentral marketplace with tokens: FileBounty: Fair Data Exchange

Their system uses Semi-trusted third party, Merkle-Damgård and Sponge Construction, Boneh-Lynn-Shacham signature scheme, and obviously zkSNARKs. This is a fascinating theoretical result. However, "an Ethereum smart contract serves for dispute mediation" and all these complex components are not suitable for real-world usage at "Facebook" deployment levels.

[devos50]

I have started a write-up on this ecosystem here. Using this issue as a place-holder for the images in the document.

[synctext]

Reacting to: #5689 and #5676. Much progress towards freeriding prevention 🥇

• Scientific grounding
  • surrounded by uncertainty, no ground truth
  • avoid single-event truthfulness
  • avoid the worst (avoid making a perfect ranking)
• Big Tech alternative storyline
  • mainstream computer science work?
  • adversarial streaming algorithm
  • Need for results
  • Deployment numbers
  • What graphs?
  • mechanism for distributed power
  • "Too much power in the hands of the few"
• "Eventual Publishable Thesis Chapter" (EPTC)
• its a network crawler run by every Tribler peer
• the term "query" could imply a local SQL cmd
• "Adds functionality where the transactions of a random peer are periodically queried"
  • why collect random info?
  • we need to optimise collecting useful info
  • maximize "cache hit"
• This is a full network crawler, not just a remote query
• shows how the above wording can be confusing to even Tribler developers
• security analysis (this is just a path-finding version)
  • This is tentative version, starting point for incremental improvement
  • full pull-based
• How many UDP packets into a single transaction
  • How many BAMI records collected?
  • How to fit into packets
  • How many seconds interval
  • How can we see database filling up?
  • is there a measurement plan?
    • ground truth (amount of records at each peer)
    • recall and precision (what are we seeing at single central crawler)
• Exit nodes use reputation
  • observe and evaluate
  • data logging with respect for privacy

[devos50]

This issue has most likely been deferred in favour of tag-related improvements so I'm un-assigning myself for now 👍