Authors:
afm <afm2@duck.com>
plebhash <plebhash@proton.me>
Abstract. Bitcoin can be used to create incentives for privacy providers of message-based applications and services. Mixpleb creates a network of mix-nodes that obfuscates traffic to protect users from metadata-based de-anonymization techniques. Mixpleb is also a federated sidechain with inspiration from Blockstream's Liquid, providing a 2-way peg to Bitcoin and carries the State Transition Function for staking, credential issuance and reward distribution. Mixpleb design is heavily inspired by NYM, while explicitly avoiding the introduction of a new token.
Chaum introduced the concept of mixnet in 1981 [1]. Similarly to Tor, a mixnet consists of an overlay network of mixnodes that routes messages anonymously. Each Sphinx packet is encrypted multiple times and sent through a sequence of mixnodes. Each mixnode removes a layer of encryption, until the last mixnode routes the message to its final destination. Each individual packet is routed independently. Differently to Tor, mixnets are designed to protect traffic from metadata-based de-anonymization attacks from global network adversaries. Aside from reordering packets on the temporal dimension, mixnodes also transform them cryptographically. Resulting traffic is untraceable in terms of metadata and timing.
On one hand, Mixpleb is inspired by Nym [4], in that it tries to be a general-purpose incentivized mixnet architecture. On the other hand, Mixpleb avoids NYM's drawback (an independent blockchain with its own native token) by using Blockstream's Liquid concepts of federated 2-way-peg (2WP) sidechain.
As a sidechain of Bitcoin, Mixpleb provides a 2WP with the Bitcoin blockchain. The amount of mBTC circulating on Mixpleb is always verifiably equal to the amount of BTC locked on the Bitcoin blockchain.
mBTC is created when BTC is moved to the Mixpleb sidechain, and destroyed when BTC is moved back the original blockchain.
The Federated Mixpleb Sidechain design is heavily inspired by Liquid Network [1].
The Mixpleb federation is composed of different entities that have some vested interest in privacy preserving infrastructure for Bitcoin.
The federation performs tasks that are essential to the Mixpleb sidechain operation, and are responsible for running the nodes that execute the Byzantine Fault Tolerant consensus along with the State Transition Function (STF).
Functionaries are a subset of the Mixpleb federation. They perform two roles:
A peg-out requires two confirmations on the Mixpleb sidechain, after which the BTC can be sent from the Mixpleb Federation's mainchain multisig wallet to a whitelisted address held by the federation member performing the peg-out.
Mixpleb federation members can also provide peg-out services.
Mixpleb enables privacy-preserving applications and services. Users have cryptographic guarantees that their communications will not be de-anonymized by proving the "right to use" these services. mBTC is used to fund operational costs, dynamically scale the mixnet to meet bandwidth demand, and reward mixnodes for their work.
The Mixpleb infrastructure is composed of three types of nodes:
The information included in the sidechain State consists of:
The sidechain's State Transition Function (STF) allows for:
In practice, Bandwidth credentials can be implemented as Coconut Credentials (as proposed by NYM [3]).
What if a mixnode goes malicious? Or if they are providing low quality service? Mixpleb establishes a reputation system for mixnodes. The set of active mixnodes is finite, and its size is determined by market demand for bandwidth. Mixnode operators and general users stake mBTC on mixnodes as an attestation of their trust in such mixnode.
The more mBTC is staked in a single mixnode, the higher is their reputation, and they're more likely to be (randomly) picked for the active mixnode set.
A Mixnode's quality of service (QoS) is objectively measured in a fair and decentralized manner by leveraging the "proof of mixing" scheme proposed by NYM [4].
Mixnodes that misbehave or provide low QoS will eventually lose their reputation because users will move their stake to other mixnodes.
Every epoch (X sidechain blocks), the set of active mixnodes is renewed. Mixnodes above a reputation threshold are eligible, and the miner determines the new active set based on a Verifiably Random Function (VRF).
Mixpleb took initial inspiration from NoTrustVerify's Oheka's work on routing Nostr traffic over NYM [4]. A Proof of Concept based on the original Golang codebase [5] is being implemented by the authors using Nym's Rust SDK[6] to gain familiarity with the topic.
In conclusion, Mixpleb integrates the robust privacy-preserving capabilities of mixnets with the financial incentives and security of Bitcoin. The federated sidechain approach, inspired by Blockstream's Liquid, offers a seamless 2-way peg to Bitcoin, fostering a decentralized environment where mBTC serves as both a utility and a reward token within the ecosystem.
Our design addresses the limitations of previous systems by avoiding the need for a native token, and the federated sidechain plays a role in maintaining the network's integrity. The reputation system for mixnodes ensures that only trustworthy and high-performing nodes are selected, fostering a self-regulating network where quality of service is paramount. As we move towards an era where privacy is increasingly under threat, Mixpleb expectes to offer a scalable and incentivized solution in alignment with Bitcoin's principles.