RFC: Lift mining off of Bitcoin

[jude]

Hey folks,

Thinking about what to do about Bitcoin MEV got me thinking about an even more radical proposal: lift mining off of Bitcoin altogether. Instead of Stacks miners individually producing block-commits, they would organize themselves as an open-membership mining pool natively supported by the consensus protocol. The miners would collectively control a single block-commit UTXO, such that the act of spending it to mine a new block requires a threshold signature weighted by BTC contributions.

A Unified Mining Pool for Stacks

What would this look like? The model for mining would no longer tie miners to a UTXO history. Instead, miners would work off-chain to collectively produce a block, and collectively announce it via a single, shared UTXO history. There would be only one UTXO history for Stacks at any point in time, except to recover from pool quorum failures.

Stacks miners would join the mining pool by sending some BTC to the pool – i.e. by creating a UTXO that the pool participants can spend. Then, when the pool produces a subsequent block-commit, it (1) consumes this UTXO and (2) grants the miner the ability to submit a portion of the signature for a given number of subsequent Bitcoin blocks. The Stacks miner would then be entitled to a pro-rata share of the STX earned by the production of each Stacks block mined in those Bitcoin blocks. For example, just to throw out some concrete numbers, a miner could create a UTXO to join the pool at Bitcoin block N with a redeem script that either allows the pool to spend it by Bitcoin block N+10, or allows the miner to reclaim the BTC after Bitcoin block N+11. If the pool picks up the UTXO, then the miner joins the pool and receives a pro-rata share of STX for the next 100 Bitcoin blocks. If the pool ignores the UTXO, then the pool is economically penalized – they forfeit a portion of the STX they would have earned based on the size of the UTXO ignored (more below).

Pool participants vote off-chain to select the transactions that will go into the block. Because everyone knows everyone else’s outstanding BTC contributions, we’d just have miners vote to include (or exclude) transactions based on their contribution weight. Once they’re done selecting transactions, they collectively spend the pool’s UTXO to produce a new block-commit that commits to the block and pays the PoX recipients. The Stacks blockchain itself would automatically disburse STX to the participants once the block rewards mature, and would require proof that miners did indeed vote on the transactions included in the block.

Adherence to the voting protocol is enforced by the threshold signature script: a block will only be produced if at least 66% of the signers, weighted by BTC contributions, approve of the block. The threshold can be made higher in practice, but it must be at least 66% to overcome Byzantine failures.

PoX itself would be lifted off of Bitcoin and into the block voting procedure. Each miner’s contribution to the pool would be doled out to PoX recipients in 1/100th increments (to use the example numbers from above). This way, miners must keep contributing BTC to the pool (and thus keep paying PoX payouts) in order to earn STX. Moreover, this ensures that the value of PoX payouts remains close to the value of the STX produced, even if there’s only one pool in operation.

Keeping the Majority Honest

The pool must pick up the UTXO from a miner wishing to join the pool. But what if the majority of miners want to exclude new participants? To address this, the Stacks blockchain consensus rules would be altered so that the act of ignoring a valid UTXO would be the act of forfeiting STX. I’d recommend a “penalty curve” that grew superlinearly in the ratio between the BTC ignored and the BTC the pool represents. For example, if the joining miner would increase the size of the pool’s BTC by X%, then the pool could reduce the STX payout to (1 - X)^2% of the baseline. Using some concrete numbers, if the UTXO would grow the pool’s BTC size by 5%, then the pool’s payout would go from 100% of the STX to (1 - 0.05)^2% or 90% of baseline if the pool ignored it. If the UTXO would grow the pool’s BTC by 10%, then the pool’s payout drops to 81% of the baseline.

Recovering from Pool Failure

If a pool fails to produce a block for more than X Bitcoin blocks in a row (where X is on the order of 10), then the system declares the pool as defunct and falls back to the sortition system we have today until the next PoX prepare phase. The miners who mine during that prepare phase would form a pool at the start of the subsequent reward phase, and resume operation.

How this Addresses Bitcoin MEV

By lifting mining off of Bitcoin and into a pool this way, we can ensure that PoX gets paid according to miners’ collective contributions, instead of according to the whims of the Bitcoin miners. In this system, we know how much BTC each pool participant contributed, the time at which they contributed, and the number of block-commits produced since each miners’ contribution was included. Therefore, we can calculate how much BTC the pool must pay out at each Bitcoin block. Miners cannot influence the amount the pool pays once their contribution is picked up. Therefore, a Bitcoin miner cannot get a discount on Stacks blocks – they can either participate honestly in a pool, or block the pool from mining in the blocks the produce.

How this Addresses Miner Centralization

The biggest barrier to entry today in Stacks mining is the requirement that miners pay a BTC transaction fee in each Bitcoin block. Mining in a protocol-supported pool like this removes this capital expenditure, meaning that the barrier to entry for mining is very low – all you’d have to do is submit enough BTC that it can be spent over the next e.g. 100 Bitcoin blocks in even chunks (so, batches bigger than 550,000 sats).

Within the pool, miners would use a conventional implementation of BFT agreement to decide on what transactions get included, and then use a form of weighted threshold FROST to produce block-commits such that each commit represents at least 66% of the miners by BTC weight (we can make the threshold higher, but it must be at least 66%). While this does require a transaction fee, the transaction fee itself would be debited from each miners’ contribution pro-rata, thereby allowing a large number of miners to share the burden of paying for the transaction.

Timeline

This would be a very complex undertaking and would likely not see the light of day until after sBTC is live. But, it would reuse a lot of the tech stack that’s getting built for sBTC, so there would be few technical surprises when implementing it.

[jonkho]

@jude

The pool must pick up the UTXO from a miner wishing to join the pool. But what if the majority of miners want to exclude new participants? To address this, the Stacks blockchain consensus rules would be altered so that the act of ignoring a valid UTXO would be the act of forfeiting STX.

Which participants in the consensus model would guarantee this consensus rule be enforced? Would it be possible for an existing established set of miners to all collude together to ignore new miners while acknowledging all amongst themselves nobody got ignored?

[jude]

@jonkho

Which participants in the consensus model would guarantee this consensus rule be enforced?

The node software itself would, by inspecting the Bitcoin chain and verifying whether or not a pool-join transaction’s UTXO got picked up by the pool. If this does not happen in a timely manner (e.g. after X Bitcoin blocks), then the node software would not grant a STX block reward to the pool for any Stacks block mined after X Bitcoin blocks had passed until the UTXO got picked up.

@jonkho

Would it be possible for an existing established set of miners to all collude together to ignore new miners while acknowledging all amongst themselves nobody got ignored?

Yes, but per the above, they would be forfeiting all STX until they picked it up (so they’d be losing money by doing this).

[jonkho]

@jude

The node software itself would, by inspecting the Bitcoin chain and verifying whether or not a pool-join transaction’s UTXO got picked up by the pool.

Is the participant that runs the node software also a miner? If so the miners would be able to configure/modify the node for the exclusion behavior?

Are there non-mining self-sovereign stack nodes that participate in consensus that can keep miners in check?

[jude]

@jonkho

Is the participant that runs the node software also a miner?

No, every node would check that pool-join transactions are processed in a (protocol-defined) reasonable amount of time. We already do something similar with on-Bitcoin transfer-stx, stack-stx, and delegate-stx operations – all nodes require that these on-Bitcoin transactions get picked up in Stacks blocks.

@jonkho

Are there non-mining self-sovereign stack nodes that participate in consensus that can keep miners in check?

Yes – the whole network keeps miners in check this way. If miners deviate from the protocol, then the rest of the network rejects their blocks.

[aaron]

I like this approach, but I think that I would call this something more broad than “lifting mining off of Bitcoin” – this is a pretty different mining model, though it does (I think) preserve a lot of how Stacks mining works today (open-membership and bitcoin-based block commits).

I am interested in exploring some variations on this approach, though – still trying to think through all the consequences, but very broadly speaking, I think of the above proposal as something like periodic membership elections where the membership group controls block formation for the period. The trust of the system is provided by the election (rather than the block formation), so I wonder if a design could be such that:

1. Bitcoin commitments are made during the “election”. The above proposal does this by creating a UTXO, but perhaps this could actually be a PoX commitment.

2. The membership set is no longer optionally formed, but rather the set would be defined by the commitments made.

3. Everyone who participates in the election receives coinbase rewards. Coinbase rewards still only manifest if a block is mined.

I am sure that there are concerns here around participating in the election, but not the block formation, but I think this is solvable: if the commitment of bitcoin occurs during election, that means that this “non-participation” would be as costly as, for example, empty-block or invalid-block mining is today.

[jude]

@aaron

Bitcoin commitments are made during the “election”. The above proposal does this by creating a UTXO, but perhaps this could actually be a PoX commitment.

Sure. The reason I tied PoX payouts to block formation instead of elections is to ensure they happen at the same frequency as they do now (so, no change to the PoX payout behavior). If we could preserve this during the election, then I’m all for it.

@aaron

The membership set is no longer optionally formed, but rather the set would be defined by the commitments made.

I’m not sure I understand this point? The above proposal requires that a pool (membership set) creates the blocks on the happy path, and the act of giving the BTC to the pool necessarily adds the sender to the pool.

@aaron

Everyone who participates in the election receives coinbase rewards. Coinbase rewards still only manifest if a block is mined.

I’ll have to think more about this. Some challenges that spring to mind regarding allowing the BTC sender to opt out of participating in block production include:

• We need to determine the subset of BTC senders that can produce blocks. How do they know that a BFT quorum is met for a block, if they cannot be sure whether or not a sender intended to participate?

• What is the advantage of giving BTC senders who don’t participate in block production a STX reward? And, why should the coinbase be equitably shared between senders who produce and senders who don’t produce? Running a mining node is a cost on top of sending BTC and reaping STX, meaning that any sort of reward-sharing scheme between producing and non-producing members ought to compensate producers for this additional cost. Otherwise, it would be more profitable to be a non-producer, which would disincentivize the creation of a large, diverse set of producers within the pool.

[aaron]

@jude

I’m not sure I understand this point? The above proposal requires that a pool (membership set) creates the blocks on the happy path, and the act of giving the BTC to the pool necessarily adds the sender to the pool.

My understanding of your proposal is that the pool could choose to exclude a sender from the pool (hence the need for a super-linear reduction in coinbase payout). Removing this optionality would mean that every would be participant would be a member in the pool.

@jude

We need to determine the subset of BTC senders that can produce blocks. How do they know that a BFT quorum is met for a block, if they cannot be sure whether or not a sender intended to participate?

The assumption is that anyone that sends BTC during the pool selection is trying to produce blocks.

@jude

What is the advantage of giving BTC senders who don’t participate in block production a STX reward?

It eliminates all coinbase reward incentives for excluding would-be participants from the pool. This would mean that a miner has much less incentive to try to crowd out other miners.

@jude

Running a mining node is a cost on top of sending BTC and reaping STX, meaning that any sort of reward-sharing scheme between producing and non-producing members ought to compensate producers for this additional cost.

That’s true, but I think this is something that transaction fees could incentivize: only miners that actually sign off on the produced block would receive transaction fees (which pay for the cost of speculatively evaluating them in a to-be-mined block). Further, coinbase rewards are only payed out if a block is actually produced, meaning that in order to receive rewards, at least some threshold of participants in the election need to participate in the block mining (either by leading the production of the block or signing off on the block).

[aaron]

Linking another proposal here:

RFC: Proposal for Collaborative mining with threshold signatures

This proposal for mining in Stacks proposes a change to the current Stacks mining protocol while trying to maintain many of the current system’s properties. Namely, the goals of this proposal are: Eliminate coinbase reward based incentives for miners to attempt to crowd each other out of the protocol. Promote faster block production by eliminating competition for blocks, replacing block competition with miner collaboration. Retain the existing system’s proof-of-transfer security scheme…

This just outlines a high level design for a scheme that I think builds on what is proposed in “RFC: Lift Mining off of Bitcoin”, but goes a bit further by (1) mandating set membership based on participation in producer selection, and (2) leaning into the threshold signature/production collaboration by changing how blocks are announced during a producer set’s “term”.

[jude]

@aaron

My understanding of your proposal is that the pool could choose to exclude a sender from the pool (hence the need for a super-linear reduction in coinbase payout). Removing this optionality would mean that every would be participant would be a member in the pool.

I’m not sure that this is even possible. If I want to join an existing pool, I have to pay into the pool. But in Bitcoin’s UTXO model, this is the act of (1) me creating a UTXO that the pool can spend, and (2) the pool spends it to add it to the pool UTXO’s balance. There’s no way to force the pool to execute the second step; hence the attention given to recovering from this scenario.

@aaron

The assumption is that anyone that sends BTC during the pool selection is trying to produce blocks.

Ah, I think you’re saying that the pool is reconstituted every so often from a set of UTXOs in a given block interval? Per your other proposal, I think you’re saying that instead of requiring the pool to spend a UTXO to complete a pool-join, we should just create a new pool every N blocks from the UTXOs created for the purpose in the prior N blocks. Is my understanding correct?

[aaron]

@jude

Ah, I think you’re saying that the pool is reconstituted every so often from a set of UTXOs in a given block interval? Per your other proposal, I think you’re saying that instead of requiring the pool to spend a UTXO to complete a pool-join, we should just create a new pool every N blocks from the UTXOs created for the purpose in the prior N blocks. Is my understanding correct?

Yep, that’s the idea.