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://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).