Taming large miners with Helper Blocks

Two serious threats posed by miner centralization are censorship and selfish mining. Censorship diminishes the basic value proposition of Bitcoin as a way to control your own wealth. Selfish mining confers a competitive advantage to large miners, resulting in an undesired feedback loop of more pressure to centralize. Extreme versions of censorship and selfish mining can also be used to attack a chain, for example by mining empty blocks, or by forcing large reorgs.

Helper Blocks could be a way to reduce the threat posed by censorship and selfish mining by giving miners an additional incentive to publish solved blocks immediately, and creating a way for a diverse set of non-miners to influence what transactions will be included in the next block.

The Basic Idea:

When a block is solved, it randomly selects one satoshi from the utxo set and gives whomever controls that satoshi the power to generate a “Helper Block”. The Helper Block commits to a subset of transactions for inclusion in the next block. A miner can accept the Helper Block by including the suggested transactions and giving the associated transaction fees to a payment address specified in the Helper Block. Miners who do not use a Helper Block must satisfy a 25% higher difficulty.

More Detailed Description:

Whenever a block is found, one winning satoshi is determined by the block hash. The owner of the winning satoshi is able to produce a valid helper block.

The helper block would consist of the following:

1. The root of a Merkle tree of suggested transactions
2. Proof that the helper had access to the entire previous block (not just the header)
3. Payment address
4. A signature, as specified in the utxo containing the winning satoshi

Once the helper block is published, miners can use it by doing the following:

1. They make sure that one of the hashes in their transaction Merkle tree matches the root of the suggestion tree provided by the helper block.
2. They pay the payment address at least as much as the fees collected from the transactions suggested by the helper block.

Suggested way to pick a winning satoshi:

Assign a number N to each block B equal to the number of mature satoshis that are held in utxos mined in blocks with a lower height than B. Compute T, the total number of mature satoshis in all utxos. Take the hash of the most recent block, and modulo by T to get a number W corresponding to the winning satoshi. The block with the largest N such that N ≤ W is the block containing the winning satoshi. To find the right utxo, you walk through the Merkle tree root down and left to right until you have added up W-N unspent satoshis.

Previous Block Contents Observation Proof

To encourage miners to immediately publish the entire block, rather than just the header, helper blocks would also prove that the creator of the helper block had access to the entire previous block. To prove this, the Helper signs the previous block hash, appends the signature to the previous block contents, hashes the two together, and includes that hash in their signed Helper Block.

Suggested way to sign helper blocks:

To support old utxos, the helper block could be signed with the same key necessary to spend the utxo. To allow cold storage, a special script could be hidden using taproot that could enable the signing computer to create the helper block without being enabled to spend the coins.

Soft fork:

This rule could be implemented as a soft fork. Upgraded nodes would check that blocks either satisfy a 25% higher difficulty or make use of a valid helper block. This soft fork could be automatically reverted after 1 year or some other suitable trial period, unless a second soft fork makes it permanent.

Choices and Incentives for miners:

If a helper block is available, miners must choose whether to use it or not. To decide which is more profitable, miners could calculate the expected value of the 25% lower difficulty and compare it with the fees requested by the helper block. Miners may still reject profitable helper blocks if they contain transactions the miner prefers to censor, but they will be leaving money on the table. Pools with a censorship policy may find it difficult to pay hashers as much as non-censoring pools.

After solving a block, miners must decide whether to publish it immediately or to delay. If they publish it immediately, there is some probability that a helper block will be created and the next block can be mined at a lower difficulty. If they delay, then (assuming that they do not control the winning satoshi) they must labor on the next block at the higher difficulty. If someone else publishes a solved block during this period, the selfish miner is put at a potential disadvantage because the competitor’s block could be built on by a helper, but their block cannot. The problem for the selfish miner becomes worse the longer the chain of private blocks being concealed.

Incentives for helpers:

When a new block is mined, its hash selects a winning satoshi, and the utxo containing that satoshi defines a signing rule necessary for making a valid helper block. If a person wishes to create helper blocks, they must ensure that a node is set up ahead of time that will receive new blocks, recognize that they can create a helper block, create the block, and publish it. This process must take place as quickly as possible because any delay could result in a block being found at high difficulty without using a helper block. Everyone who owns any satoshis has a financial incentive to participate in this lottery.

If they choose to set up such a node, they must decide on a policy under which transactions will be selected. If they select transactions totaling to too small a fee, they risk leaving money on the table. If they select transactions totaling too large a fee, they risk making their helper block unprofitable for miners to accept. If they select transactions they know that much of the hashpower is committed to censor, they take the chance that this hashpower will not accept their helper block.

Impact on out-of-band miner fees:

Out of band miner fees occur when someone compensates a miner for including their transaction some way other than by using the normal fee mechanism of having outputs sum to less than inputs. Out-of-band miner fees are less attractive if helper blocks exist, because helper blocks reduce the block space miners have discretion over, and it is not practical to compensate helpers out of band. For this same reason, all miner transaction inclusion policies apart from “maximum fee per block” have less impact.

Impact on feather fork censorship:

Feather fork censorship occurs when a large miner avoids building on a block with a black-listed transaction, hoping that they or someone else will mine an alternative block at the same height. The possible existence of Helper Blocks makes this strategy less likely to succeed, because it creates additional scenarios by which black-listed transactions can get in.

Scenarios:

1. Helper Block on block at height H contains a black-listed transaction. In this case, assuming a miner does not wish to accept the Helper Block, they can either mine at height H+1 at 125% difficulty or mine at height H for an alternative that might yield a different Helper Block. Neither of these options are attractive. Working without a helper block, they require 55.5% of the hashrate to overpower the remaining 44.4% who accept the Helper Block in order to have a 50% chance of beating them to H+1. If they choose to mine H instead, they might be able to do it at 100% difficulty, or they might be able to do it at 125% difficulty, depending on whether or not H-1 has a helper block. Furthermore, they may find alt H and then to their dismay a Helper Block may be created that again mines the black-listed transaction. Or they may not find alt H before the rest of the network finds H+1. Again, if they mine H with the black-listed transaction, they are sure to only need to achieve 100% difficulty.
2. Block at height H contains a black-listed transaction, and a Helper Block has been created. Miner wishes to feather fork block H, so they work on alt H. But here’s the problem. We already know that block H yielded a Helper Block. Alt H has something less than 100% probability of yielding a Helper Block. So H+1 can be for sure mined at 100% difficulty, but alt H+1 may only be able to be mined at 125% difficulty. No way of knowing ahead of time.
3. Block at height H contains a black-listed transaction, and no Helper Block has been created. In this scenario, the malicious miner is in a somewhat *better* position to execute a feather fork, because alt H might yield a Helper Block and be therefore a superior tip to build on. (Of course, the Helper Block may also include the black-listed transaction, ruining this advantage!!) The existence of this advantageous(?) scenario does not actually permit the feather fork attack to succeed, because a successful feather-fork must be carried on for multiple blocks. Once a black-listed transaction gets more than 1 confirmation, the cost of and odds against executing a feather fork go up fast.

Impact on attacker confidence:

A dynamic introduced by this scheme is to inject a new kind of helpful uncertainty to the mining process. When the most recently mined block has been augmented with a helper block, attackers who wish to avoid building on the helper block have less certainty about what might happen than they have in the current setup.

In the current setup, miners know their own hashrate, can estimate the network hashrate, and can calculate the odds of successfully mining an alternative to the most recent block. By contrast, if the most recent block has been augmented with a helper block, miners seeking to replace it with their own block do not know whether the block they create will be able to be augmented with a Helper or not. They likely cannot learn this until after they actually mine and publish the block — at which time someone will either augment it with a helper, or no one will.

Impact on energy consumption:

Because helpers consume up to 25% of the block reward in this scheme, up to 25% less block reward is available to spend on energy. At the same time, I would argue that security is not going down, but rather up, because the remaining 75+% energy consumption is being steered by a more decentralized set of people.

The 25% block reward NOT being spent on electricity is instead distributed to holders.

Helper Pools:

Having the winning satoshi is a rare event, and requires maintaining an active node, so helper pools could be expected to emerge. I have not worked out how to pool in a way that minimizes trust.

Restricting the candidates for winning satoshi:

There is an argument to be made for equally weighting every mature satoshi. This has the advantage of side-stepping politics about what magic parameters a restriction would have, and seems the most pure and fair. There is also no temptation in this plan to periodically spend coins merely to stay in the lottery. Finally, if the pool of candidates is as large as possible (all satoshis) it minimizes the potential for games to be played with trying to be a miner AND have a large fraction of the candidate UTXOs under your control.

Alternatively, some function could be applied to weight satoshis from recent blocks higher. This approach would allow lost coins to eventually age out of the lottery, which is nice since lost coins are incapable of producing helper blocks. For example, coins could simply stop being candidates after a timeout, or they could become less likely to win over time based on some linear or exponential decay.

My suggestion would be a simple timeout of 2¹⁹ blocks, which is slightly less than 10 years. The vast majority of coins that are not lost will probably be moved more frequently than every 10 years and would therefore not need to think about the timeout. Some have estimated that several million coins are lost by now, and as time goes by, miners wishing to selfish mine may begin estimating how likely a particular winning satoshi is to be lost and therefore unable to produce a Helper Block. A 10 year timeout would wash unspent coins from the 50 coin epoch out of contention by 2022. These utxos probably contain a lot of lost coins. Also, let’s be honest, Satoshi is not very likely to broadcast Helper Blocks.

Odds of getting picked:

If all satoshis are equally weighted, and assuming blocks are produce every 10 minutes, each Bitcoin would get picked every 400 years on average. If we drop old utxos, it would be reasonable to lower that value to perhaps once every 300 years. Significant economic players (e.g. those controlling at least 100 bitcoin) would only expect to wait about 3 years to produce a Helper Block.

Helper Block size:

Helper Blocks have elements as follows:

Element_1 = signatureOf(hash_of_previous_block_header) [71 bytes]

Element_2 = hashOf(full_previous_block+Element1) [32 bytes]

Element_3 = Merkle root of transaction subtree [32 bytes]

Element_4 = paymentAddress [20 bytes]

Element_5 = signatureOf(Element_1+Element_2+Element_3+Element_4) [71 bytes]

Total size =226 bytes

When a Helper Block is published, if the Helper wants miners to actually use it, they also need to publish instructions for how to build a transaction subtree that generates the Merkle root. This information does not get stored anywhere though.

Miners are expected to be willing to accept helper blocks that request an amount of money less than 25% of the block reward they can get without the Helper block. Right now, less than 25% of the block reward is transaction fees, so miners should be willing to accept helper blocks with very large subtrees — even up to the block size limit. In the future, when fees make up more than 25% of the block reward, miners would only be willing to use smaller Helper Blocks, until in the end Helper Blocks would tend to specify about 25% of the block space.

Impact on latency sensitivity:

Under this proposal, mining takes place in two difficulty phases. Phase 1 is at high difficulty before receiving a Helper Block. Phase 2 is at low difficulty after receiving a helper block. This reduces the disadvantage that miners with bad latency have, which is good, because large, centralized miners tend to have lower latency than small, decentralized miners. By the time a helper block has been received, it is possible to fully validate the previously mined block. Helper blocks can be verified more quickly than mined blocks, partly because they contain fewer transactions. Helper blocks also can be seen by all miners more or less at the same time, rather than being seen early by the miner who mined the previous block, which is the unfortunate circumstance presently.

Selective Helping:

I’ve described the Helper as broadcasting the Helper Block to everyone immediately, but what happens if the Helper only gives the Helper Block to some miners but not to others? Does this create a vulnerability where large miners could pay Helpers to give a Helper Block exclusively to the large miner, and in this way help the miner gain even more power?

Reason #1 why Selective Helping is not a problem:

Suppose a miner wishes to try this strategy. They make it public that they are willing to compensate Helpers who play along. (And bring endless wrath down on their heads via twitter.) If Helpers normally expect a payment of X, this miner tells them they will pay X + Y, where Y is the additional money just for being exclusive. Should helpers be exclusive?

I would think Helpers in this situation should be expected to cheat. Helpers are generally anonymous and unlikely to have a winning satoshi again soon. They may have no reputation to lose. The rational move for most helpers in this situation is to privately send the Helper Block to the miner, but also privately send it to their competition. This might not be true of Helper Pools which could have a persistent cozy relationship with big miners — but Helper Pools would be even easier to set up and tear down by concerned hodlers than Miner Pools.

Reason #2 why Selective Helping is not a problem:

How much extra money does a miner need to offer a Helper to make it worthwhile? As an example, suppose the Miner has 45% of the network hashpower. Assume it takes the network 540 seconds to mine at low difficulty and 540 * 125% = 675 seconds to mine at high difficulty. Our bad guy miner can mine blocks at 1200 seconds with a helper block. The other miners working together can mine blocks without a helper block in 1227 seconds. So if our bad guy miner can get exclusive rights to a helper block, they have slightly more than 50% of the effective hash rate.

The person controlling the winning satoshi must decide what to do. They can publish their Helper Block immediately to the entire network, producing a high probability that it will be included in the next block. Alternatively they can accept the exclusivity deal, in which case there is a 50% chance they will get nothing. If we assume that a normal Helper Block is worth up to 25% of the block reward, it follows that the premium for getting into bed with the bad miner starts somewhere around 25% of a block reward, and goes up according to the price the Helper puts on the added uncertainty.

So the miner must pay more than 25% of the block reward to obtain equivalent additional hashrate of 10% of the network? This is starting to sound like a bad deal for the miner. Thank goodness they didn’t spend that money on more electricity and miners, which presumably could have bought them something closer to 25% additional hashrate! Also, consider how ephemeral their advantage is? For this to be as threatening as a real 51% attack, they would need to dominate the network block after block. They cannot do this unless they can obtain helper blocks every time, which is not going to be possible.

Given the above arguments, I think selective helping does not pose a significant threat to this scheme.

Money for nothin’

One might object to Helper Blocks on abstract principle, figuring that it awards control of the network to people for no work and no risk. Proof of Work, the argument goes, requires purchasing hardware and burning electricity. It involves costs and risk, and skin in the game. What risk does the potential Helper run?

To make things more concrete, consider the Helper who is very passionate about soap and wishes to fill up 1% of the blockchain with advertisements for their favorite soap. How much bitcoin would they need to hold to achieve this? How much would they forfeit in fees?

At the time of writing, assuming equal weighting of satoshis over time, they would need to control 171,000 bitcoins minimum worth more than 1 billion dollars. That’s assuming they could submit Helper Blocks that specified all of the transactions in the block. In the future steady state, when each Helper Block would control only 25% of the transactions, it would require 4% of all satoshis to control just 1% of the block space, and they would forfeit fees equal to 1.44% of a block reward every day.

Given the above example of someone wishing to control just 1% of the block space, can anyone reasonably conclude that they are taking no risk and incurring no cost?

Helper Blocks do not award control and money for nothing, but they do award control and money to people based on something they already have about them for another purpose: saved money. This is typical of control systems that react in a sublinear fashion to the resources used to obtain them, and this sublinearity is good for decentralization.

Comparison with Proof of Stake:

A superficial analysis may conclude that this is a Proof of Stake scheme, and Helpers do qualify by proving stake, but there are crucial differences.

1. Helper Blocks do not have a nothing-at-stake property. Quite the opposite in fact — grinding an alternative history with Helper Blocks would be absurdly expensive. First you would need to possess some significant fraction of satoshis, and second you would need to mine multiple valid PoW blocks until you get one that points to a satoshi you control. For example, if you owned 100 bitcoins, you would expect to mine 170,000 valid blocks (!) in order to find a valid Helper Block that you had the keys to sign.
2. Critics of Proof of Stake worry that control of the chain will end up in the centralized hands of large stake holders. Helper Blocks, by contrast, do not award Helpers with significant control over which blocks get built upon. If you discover that you have the ability to build a Helper Block on top of the last mined block, that ability is not transferable to any alternative blocks.

Interaction with Confidential Transactions

To me it looks like CT outputs would not be able to participate in the contest for the winning satoshi, since these outputs have their amount blinded. This scheme depends on the ability for everyone to be able to calculate which utxo contains the winning satoshi. While we can compute how many satoshis there are in total among all CT outputs, we cannot figure out which satoshi is in which CT output.

What if you mine a block and you have winning satoshi?

Miners who control a significant amount of hashpower and who control a significant amount of bitcoin may sometimes find a block for which they can produce the Helper Block. In this situation, rewards and risks of selfish mining are higher than usual. The reward is higher because the expectation of successfully mining on top of the Helper Block at 75% difficulty is higher. The risk is higher because the Helper Block is worth money in the form of the transaction fees it claims. If a competitor finds a block first, the selfish miner may lose their witheld block AND the helper block.