# PlebHash: a trustless and decentralized protocol for pooled Bitcoin mining

# Introduction

Bitcoin mining is a highly competitive environment, and individual miners working alone have very low chances of achieving any kind of profit. Miners collaborate to form mining pools, combining their hashing power and sharing their rewards.

Most mining pools rely on some centralized authority to keep track of the individual miner shares. The coinbase in the mined block actually rewards this central authority, which later redistributes them across the individual miners according to their own criteira. This introduces the possibility of unilateral decisions taken by this central authority that could go against individual miner interests.

PlebHash is a trustless and decentralized protocol for pooled Bitcoin mining that aims to solve this problem.

# Pre-requisites

In order for PlebHash to be successful, the following requisites must be satisfied:
- There's no central authority.
- No single miner has more power over the protocol, when compared to every other miner, regardless of their hashing power. The only exception is the fact that propagating more shares allows bigger rewards as coinbase outputs.
- Game theory is sufficient to enforce that miners are disincentivized to misbehave in every possible way.
- Networking and computation delays do not prevent the protocol from working as expected.
- Miners don't need expensive hardware to run the protocol (aside from the ASIC itself).
- No modifications are necessary to the Bitcoin protocol.

# Design

The central idea behind the protocol is the fact that every miner agrees to mine a block whose coinbase outputs distribute rewards proportionally to each miner's hashrate.

## Mining Shares

Shares are defined in the same fashion as in traditional pooled mining: low difficulty blocks are mined as proof that each miner is contributing to the pool's hashing power. The more shares some individual miner finds, the bigger hashrate he is able to prove.

Each miner is rewarded proportionally to how many shares he finds.

As miners find new shares, they broadcast them to their peers. Miners can choose which difficulty they will use to mine their shares, in order to reduce the bandwidth requirements for broadcasting them to their peers.

Every miner keeps an internal representation of the hashrate ranking of all miners, which is based on the shares that are gossipped over the network. The hashrate is calculated based on the shares created for past blocks.

## Work Assignment

Every miner runs a full node, so they can eventually propose candidate blocks (they're called block proposer when performing such role). The block proposer watches the transaction pool, and as soon as a new block is added to the chain, they build a new block on top of it. Miners alternate for the block proposer role in a round-robin fashion, for each new block.

When the block proposer creates a new block, they prepare a coinbase with multiple outputs. The coinbase rewards every miner proportionally to their shares.

The block proposer also splits the nonce search space across the miners proportionally to their hashrate.

The proposed block is propagated to all miners in the pool. Upon receiving the candidate block, every miner checks the protocol criteria for block validity:
- If the blockspace is being reasonably consumed (e.g.: there's no empty space, or fees aren't lower than they could be).
- The fairness of the coinbase distribution. Every miner keeps an internal ranking of reported hashrate, so they know if the reward distribution is really fair, thus being able to catch a block proposer that is trying to cheat.

If the miner finds that the proposed block is not following the protocol criteria, they move on to the block that was proposed by the next block proposer in the round robin queue. As soon as a miner agrees to mine some specific block, they advertise this to their peers.

All miners are incentivized to agree on the same proposed block, otherwise their shared hashing efforts would be wasted. Therefore, it's in every miner's best interest to agree on some protocol level criteria for global agreement on the same block.

If some block proposer proposes a block that diverges from the agreed protocol creteria, that means they simply lost their turn and no one is going to waste efforts on the bad proposed block.

## Maximum Pool Size

In order to achieve a fair distribution of rewards, the coinbase needs to have as many outputs as there are miners. But the coinbase cannot have an unlimited number of outputs, otherwise it would take a prohibitive amount of space in the block.

Therefore, the pool cannot have an unlimited number of miners. The pool needs to have a maximum number of miners, which would generate a coinbase of maximum allowed size.

Although each pool can only accomodate a limited amount of individual miners, that doesn't mean the protocol should only enable one single pool to exist. Multiple pools can co-exist under the PlebHash protocol.

Since this is a decentralized and permissionless protocol, there's no way to prevent a new miner from joining a pool. But when the coinbase is being built, it ranks the miners by hashrate in a descending manner. Miners that are left out of the coinbase due to not having enough hashing power to compete with the others will no longer have incentives to stay in the pool, and will simply leave.

## Engineering Considerations

[`libp2p`](https://libp2p.io/) is a state-of-the-art open source modular networking protocol for creating distributed applications. It provides protocol primitives such as:
- [`rendezvous`: Rendezvous Protocol for generalized peer discovery](https://github.com/libp2p/specs/blob/master/rendezvous/README.md)
- [`gossipsub`: An extensible baseline PubSub protocol ](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)

These primitives can be used as the building blocks for the PlebHash protocol.

ToDo: which ZK primitives should be used?
https://crypto.stackexchange.com/questions/108060/zero-knowledge-proof-for-sha256-preimages?noredirect=1#comment231094_108060

# Challenges and open questions

- What does resource consumption look like for each miner (for running the protocol, not mining)? How does it grow in relation to the total number of miners in the pool?
- Can ZKPs computational effort become a limiting factor?
- ZKPs generation and gossip will introduce considerable delays. How will they impact the protocol? Are there ways to mitigate that?
- Can we remove the need for every miner to run a full-node (and be a block proposer)?
- Is it possible to perform an eclipse attack where miners collude while refusing to propagate the shares of some specific miner?
- Is it possible for miners to diverge on the candidate block?
- Can big miners collude to exclude specific miners from the coinbase?
- How to deal with conflict resolution for duplicated shares?

# ToDo

- comparison with StratumV2
- comparison with SmartPool
- comparison with P2Pool
- comparison with Braidpool

https://github.com/mcelrath/braidcoin/blob/master/braidpool_spec.md