RFC: Stacker-Signing, a protocol upgrade to defeat the 51% attack on the Stacks blockchain

Long post ahead, 1 hr+


The current Stacks miner centralization problem is a manifestation of the “51% attack”. The symptoms are orphan blocks and long-chain reorganization which compromises transaction finality. During a chain reorg, honest miners are revoked of their block rewards for which they have paid commitments for. Becoming unprofitable, they drop out leading to further mining centralization. We are already past this point.

The 51% attack is an attack vector that presents itself in Nakamoto-Consensus blockchains for which Stacks and Bitcoin are a part. The way the attack works is if a selfish miner can accrue at least 51% of the mining power, they can build a fork hidden from the rest of the network. This fork is composed exclusively from the attacker’s own blocks through refusing to integrate the blocks of others (orphaning) and keeping their own blocks to themselves (withholding). Then at a later point when their hidden fork exceeds the length of that of the competing “canonical fork” - an inevitability because the selfish miner produces blocks faster than the rest of the network combined - the selfish miner then publishes his fork for the rest of the network to reckon with. The honest miners receiving this longer fork have to accept this fork as part of the new canonical chain per Nakamoto Consensus, evicting the honest blocks from their place. Even as this is not the desired outcome at-large, it is the rule: The longest fork is proof of the most work done and reorganizing the chain around the longest fork is a core consensus rule of Nakamoto Consensus which allows contentious forks to resolve to one canonical chain without appealing to a central authority. Thus is a brief overview of the mechanics of the 51% attack.

We are not advocating to remove/replace Nakamoto Consensus in Stacks. It has a proven track record to converge without trust and under adversarial conditions. It is also attack-resistant, but only if certain supporting conditions are met.

Nakamoto Consensus enforces how to resolve a conflict i.e. fork length, however it takes no stance or enforcement on whether the techniques or strategies used to create said forks are fair. During bitcoin’s GPU mining days, the introduction of ASICs caused an uproar as just a few dozen of these machines could completely dominate the hashing power of the entire network. If ASICs were forever restricted to the hands of a few, the Bitcoin network would not be secure despite operating under Nakamoto Consensus. However, today Bitcoin is considered very secure. The point is this: deploying the Nakamoto Consensus on its own does not confer automatic security. There are other supporting conditions required for this consensus method to provide meaningful security.

What are these supporting conditions that make an attack on Bitcoin difficult? We can identify 2 conditions:

A1. Insurmountable upfront financial and logistical costs to anyone wishing to accrue 51% of hashing power. With bitcoin, the combination of ASIC machines, technology, logistics, and operational expertise adds up to be a massive economic barrier up-front for a malicious entrant. The costs are in the billions of dollars if indeed even feasible at all.

Q: Why then, don’t the current pre-existing bitcoin miners collude their hash power to 51% attack the network for their own benefit?

A2. Miners have substantial consolidated capital investment. Given bitcoin mining operations have substantial illiquid capital in the form of ASIC machines and its associated enterprise, degrading the network would be akin to slashing the valuation of this capital. Bitcoin could be considered proof-of-stake of ASICs. In short, it is economically harmful to them to degrade the network. It is common belief, at a glance, that bitcoin is secured by hashpower alone, but this view is incomplete. A bitcoin miner’s desire to preserve consolidated capital motivates the miners to conduct themselves for the benefit of the network, rejecting cursory bribes to undermine it. The particulars of the social and economic cast that lies beyond the code often gets overlooked when reasoning about bitcoin security.

As for the Stacks network, those 2 supporting conditions are not satisfied. Let’s review:

B1. It’s cheap and easy to accrue 51% of Stacks mining power. To accrue 51% of the mining power, the malicious miner just needs to submit 51% of the total block commitments for the sortition step. Rational miners are looking to make a profit, so the total value of block commitments generally does not exceed the value of the stacks block reward. At the current price of $0.5 (as of this writing) the block reward is $500. Practically speaking, commitments totaling above the $500 threshold will result in a negative expected value (-EV) for all mining participants. A malicious miner will over-commit precisely to economically evict honest miners and wrest control of the mining pool. The cost to 51% attack the network is thus measured in only hundreds of dollars. Proposals to fix 51% attacks that focus on tuning rules around threshold commitments and the block reward distribution are still limiting the security budget to some fraction or low multiples of the value of the block reward, at best.

B2. Stacks miners have zero consolidated capital requirement. Without consolidated investment, the miners’ actions are no longer tied to the long-term health of the network. Mercenary mining behavior will dominate where the miners are only interested in very short-term results such as profiting from the spread between their block commitments and the block reward. They are susceptible to bribes and other corrupt behavior as they have no locked-in or vested interest. It is almost certain that the current batch of miners are not advocates for the network for which they are a participant, have no interest in accumulating stacks tokens and liquidate their rewards to realize their profit immediately.

Is there a solution?

Yes, perhaps. The claim is that it is possible to upgrade the Stacks network protocol to gain the security virtues as described in A1 and A2 while preserving Nakamoto Consensus. Restated, the Stacks network can gain security so that a would-be 51% attacker will confront these 3 Security Postulates:

C1. Insurmountable upfront financial costs to accrue 51% mining power.
C2. They themselves have pre-existing consolidated capital invested in the network.
C3. Nakamoto Consensus is the tie-breaker; conflict-resolution is trustless. When conflicting forks present themselves, the longest fork wins.

In my opinion whichever solution that ultimately gets adopted should have to satisfy these 3 postulates in order to demonstrate sufficient tamper-resistance.

The Proposed Solution:

We begin by detaching Nakamoto Consensus from the economics of block commitments. The reason being it’s too cheap (see point B1). Instead we organize Nakamoto Consensus around stackers where there is a large amount of capital in play. Nakamoto Consensus is now the conflict-resolution strategy between stackers. Conflict resolution for what issue? Conflict resolution for the stacker’s new responsibility of advancing the chain tip. Let’s dive into the details.

The actors:

  1. Stackers: The same as the stackers as we know them today with one more thing: they have a new responsibility of advancing the chain tip. There will be Stacker nodes that Stackers must run to perform this task.

  2. Block Committers: Block committers make block commitments. The closest analogue is current stacks miners, but we shall deprecate that term because it’s overloaded for tasks they are no longer responsible for under this design.

  3. Stacks full nodes: Same as what they are right now. Not super relevant to this discussion.

Let’s walk through the steps of a single block round in a basic ideal path. We begin with all actors agreeing on same chain-state:

  1. At the start of the block round, each Block Committer constructs a valid block that he would like to see the chain-tip advance to should he win the sortition. These are their candidate blocks.

  2. Each Block Committer sends his candidate block to the Stackers for archival.

  3. Stackers receive candidate blocks from Block Commiters. They validate and store each block in their cache, retrievable via its hash.

  4. Each Block Committer makes their block commitments along with their candidate block’s hash for sortition.

  5. After sortition is complete, the Stackers of the 2 slots randomly selected to receive the PoX yield are the Chosen Stackers. With the hash of the winning candidate block at hand, each Chosen Stacker retrieves the block from its cache, validates it and appends it to its view of the canonical chain, advancing it.

  6. Each Chosen Stacker then signs that candidate block which is now canonical, and publishes the canonical block to the rest of the network.

  7. The network nodes receive the canonical block, validates its signature confirming it originates from one of the Chosen Stackers, validates the block for itself and appends it to the tip of their chain. The Block Committer receives his block reward.

  8. A new round begins.

First point to note: There are no changes in either the reward or payout structure for either the Block Committers (formerly miners) or Stackers. I repeat: there are no new financial incentives introduced in either magnitude nor distribution for anybody; no one is earning more or earning less than what the current network rules have in place. On net, this design is asking Stackers to take an active part to earn their PoX yield in exchange to heighten network security, rather than sitting by idly as they do now.

Second point: The tasks that were previously held by the miners are now split between two acting groups. The Block Committers exclusively construct blocks but cannot control the chain-tip; The Stackers decides on the chain-tip but cannot control the choice of block that appends to it.

How much more security can be gained by this arrangement? Let’s walk through an attacker scenario. Recall that for this design to be worthwhile, we must demonstrate that a would-be 51% attacker encounters the 3 Security Postulates (C1, C2, C3) that impede their attempts.

51% Attack Scenario:

The attacker Alice is looking to produce a fork consisting of her own blocks. This fork is to be mined in secret and then published at a later time when she needs to reorg and overwrite the canonical chain. Her motivation is perhaps she is about to place a on-chain bet with a casino application: if she wins the bet, she does not need to reorg the chain and can abandon the hidden fork; if she loses, she will publish her hidden fork to the rest of network in an attempt to unwind the transaction history to a state before the bet took place so as if the bet never occurred.

Her strategy: She has Block Committer nodes to create candidate blocks to her specification. She also runs Stacker nodes that control 10 PoX slots (out of hundreds) so she has a chance to become the Chosen Stacker which earns her the right to append her block to the chain. Let’s illustrate the sequence of events step-by-step:

Attempt 1:

  1. Alice constructs a candidate block and enters into the sortition with her block.

  2. She wins the sortition so her candidate block is selected to be incorporated into the chain.

  3. Her Stacker node also immediately wins 1 of 2 PoX slots, making her one of the Chosen Stackers, giving her the right to append her block to the chain.

  4. Her Stacker node appends her block to the chain, but she withholds from broadcasting the signed block in order to initiate her secret fork.

  5. However, the winner of the second PoX slot is an honest stacker and acts honestly. He broadcasts his block to the rest of the network. Therefore everyone is on the same chain-tip as Alice and no secret fork is created. This attack attempt is thwarted.

Alice, realizing she needs to win the pair of PoX slots, tries again.

Attempt 2:

  1. Alice enters into the sortition with her candidate block.

  2. She wins the sortition so her candidate block is selected to be incorporated into the chain.

  3. Her Stacker nodes also immediately wins both PoX slots, giving her exclusive control to append to the chain.

  4. Her Stacker node appends her block to the chain, but she withholds from broadcasting the signed block in order to initiate her secret fork. Only her nodes see the chain tip advance to block height 101 (stx101) while the rest of the network still sees the tip at height 100 (stx100).

  5. For the network at-large, failure to receive a block is a “block-miss” and a non-event. No special action is needed. A new block round begins.

  6. Alice creates her candidate block. This candidate block is now archived by only her own Stacker nodes as other honest nodes cannot validate her block due to being on a different chain-tip than her.

  7. Alice enters into sortition with her candidate block.

  8. Alice wins the sortition again and her candidate block is selected to be incorporated into the chain.

  9. Her Stacker nodes also immediately wins both PoX slots, giving her exclusive control to append to the chain again.

  10. Her Stacker node appends her block to the chain. Again, she withholds broadcasting the signed block in order to build her secret fork to length 2. Her block height is now at (stx102) while the rest of the network still sees the tip at (stx100).

  11. A new block cycle begins and she repeats the steps above in an attempt to add to her fork …

It should be apparent to the astute reader that for Alice to even reach this far with the 10 slots she controls is a highly improbable statistical outcome although possible. At this point she would be wise to abandon her secret fork attempt and publish her blocks to collect her block rewards. To push on, she would have to continue her streak of winning the sortition and winning her pair of PoX slots in order to maintain her lead. It is exceedingly unlikely given her current control of the network. Furthermore her theoretical maximum fork length she can conceal is of length 5.

She has 10 PoX slots and each round consumes 2 slots. Now assuming the most likely event does take place over the next 3 blocks and she loses both the sortition and slot drawings, the honest network will add blocks (‘stx101), (‘stx102), and (‘stx103) to their chain-tip. Per Nakamoto consensus, if she publishes her fork (stx102) it will not displace (‘stx103), instead her chain will reorg to (‘stx103). Nakamoto Consensus selecting the longest fork is now precisely the outcome the network desires; thus Postulate C3 is demonstrated.

Alice however, is unfazed and she correctly surmises she will need to control a substantial portion of the PoX slots - over 51% of the PoX slots, in fact - to be able to consistently win both slot selections during each round. At current market value, there are over $300MM of stacks tokens stacked. So Alice raises at least $300MM and hits every bid on the stacks token market to acquire the correct nominal amount of tokens needed to control over half the slots; thus Postulate C1 is demonstrated.

Alice then takes her tokens and stack them in the network. However, having done this, Alice now has substantial consolidated capital locked in the network and she is no longer interested in performing actions that could undermine that capital. The incentives simply do not align that way. In fact, she is likely to become an advocate of the network. Alice is now an ally; thus Postulate C2 is demonstrated.

Now that the 3 Security Postulates have been demonstrated, we can answer the question of how much security is gained quantitatively by comparing the estimated financial cost of conducting a hidden fork between the current protocol and the proposed upgrade. The cost for the current is measured in the hundreds of dollars (point B1), whereas post upgrade it would be in the hundreds of millions, or by a factor of about 1 million fold (1,000,000x).

Other considerations: What if Stackers refuse to run the Stacker node, or refuse to sign blocks?

If every single Stacker node is offline or decides not to sign off the canonical block, then block production will grind to a halt. If only half of the Stacker nodes are online, then the block progression will move at half the speed. Stackers are economically incentivized to be online and sign, not only because they have consolidated capital they wish to preserve, but also because their PoX yield depends on it. Block Committers put up block commitments expecting the block reward but need a signature to receive it. Stackers want the bitcoin yield and can sign off a valid block. This is a perfect coincidence of wants and both participants are peers in this exchange. Neither party has lordship over the other. If Stackers do not sign valid blocks presented to them, Block Committers will refuse to make block commitments and over time the PoX yield will decrease proportionally to the Stackers’ absenteeism. If Stackers are economically rational actors who voluntarily give up short-term liquidity in exchange for stacking yield, they will be online ready to sign.

What about on a block-to-block basis? Is there a way to deny a Stacker of PoX yield if they are offline or don’t do their job?

Not really for now. Controlling bitcoin transfers is a bitcoin-write-problem. We could however adopt a different block reward distribution schedule where the block reward is paid out pro-rata to block commitments made over a certain span of sortition blocks. This would virtually guarantee the Block Committer with the missed block will get rewarded when the next block is signed. This also solves the Bitcoin MEV problem and is one of the solutions under consideration.

Censorship Resistance

There is an attack called the “empty block attack”. An empty block is a block without any transactions; they are valid, however. The way this works is if a malicious block producer has 51% of the mining power, this attacker can choose to append empty block after empty block and essentially halt the blockchain’s transaction activity. Honest block producers who present useful blocks are simply orphaned and never become part of the canonical chain. What is the motive for this attack? It’s malicious intent. It is not an economically rational behavior within the incentives of the network; it is clearly more profitable to collect transaction fees by processing transactions. This is the reason it’s not an attack typically performed. Nonetheless it does occur for ideological reasons and it amounts to censorship.

Besides demonstrating reorg resistance, we must also demonstrate how this proposed design is censorship resistant.

The current Stacks network is vulnerable to this vector of attack because it currently has centralized mining control. The Stacks network is not experiencing empty block attacks at the moment because although the miner is malicious they are still economically rational and prefer to maximize profit processing transactions. However if their intent changes they can halt the network while still operating at a profit - just less profit. If this happens, the current network protocol doesn’t have a way to recover other than directed intervention by the community.

Let’s consider how the upgraded protocol could handle this attack.

Empty Block Attack Scenario:

The attacker Alice has been commissioned to attack the Stacks network in order to undermine confidence in the project. Since she cannot reorg the chain, she will attempt the empty-block attack instead.

Her strategy: She has a Block Commiter node to create empty blocks to archive with Stackers. In order to position herself to win every sortition, she must push out any other honest Block Committer… By overbidding on the block reward, she will make it -EV for Block Committers. Economically rational Block Committers will drop out and She will be the only Block Committer remaining. This is the sequence of events:

Attempt 1:

  1. Alice constructs an empty block and submits it to the Stackers

  2. Alice enters sortition by making a block commit worth $500 which is $500 on top of pre-existing honest block commitments worth also $500. The block reward itself is worth $500. So now we have $1000 worth of block commitments (the honest Block Committer’s $500 + Alice’s $500) chasing after $500 worth of block rewards. This is a negative expected return (-EV) for all Block Committers who will on average for every $1 spent will see $0.5 returned.

  3. The sortition completes and regardless of the outcome, some honest Block Committers begin to leave because they recognize a bad deal when they see one.

  4. A new block round begins and Alice repeats her actions. The block commitments total $700 for this round with (Alice’s $500) + (honest Block Committers’ $200). $700 dollars now chases $500.

  5. The sortition completes and Alice’s empty block is the winner.

  6. The chain appends an empty block.

  7. A new block round begins and all honest Block Committers have dropped out. Alice submits the sole block commitment of $500 and is the sole sortition participant and winner. The blocks appended to the chain are now empty.

Alice can sustain this course of action indefinitely because her $500 block commitment is rewarded with a $500 block reward so she is at net zero on executing this attack. It could be suggested that this attack be made more costly for Alice if the protocol mandates consolidated capital in the network as a security requirement for block production. However this requirement would void the open-membership quality that Block Committers currently enjoy. I believe this is a non-negotiable for this community.

As It turns out the proposal as-is already has natural affordances to defeat this. The concept is PoX-Recycling: Stacker can take the PoX that Alice pays to them and recycle this yield as block commitments to be used back against Alice. Since this is pure yield, Stackers incur no net losses for doing this. With the network in jeopardy, Stackers will undoubtedly mobilize together, either informally or in code, to protect their consolidated capital. Let’s play out this action resuming where Alice left off:

  1. Stackers, realizing the network is being attacked, cooperatively agree to recycle PoX rewards for 10 rounds.

  2. At the start of the new block round, each of the pair of Chosen Stackers that received their PoX rewards from the previous round (X-Chosen Stackers), will submit a useful block thus acting as Block Committers.

  3. The X-Chosen Stackers recycle their entire PoX yield ($500) into their block commitments. Alice also makes her block commitment of $500. Now there is $1000 in total block commitments (Stacker’s $500) + (Alice’s $500) contending for a $500 block reward. Alice now incurs a -EV for her attack.

  4. The sortition completes. Alice’s empty block wins and is attached to the chain. The Chosen Stackers’ PoX yield now totals $1000.

  5. A new round begins. The X-Chosen Stackers recycle their entire PoX yield (now $1000) into their block commitments. Alice also makes her block commitment of $500. Now there is $1500 in total block commitments (Stacker’s $1000) + (Alice’s $500) contending for a $500 block reward. The Stackers’ block commitments now dominate Alice’s and she incurs an even higher -EV.

  6. The sortition completes. The Stacker’s useful block wins and transaction flow continues.

It is apparent that if this continues for 10 rounds, Alice’s $500 block commitment will be up against Stacker’s $5000 block commitments. Not only is Alice losing her entire $500 due to extreme -EV, her attack exerts negligible pressure on transaction flow. Furthermore, ramping up her spending cannot help her; Alice’s -EV is the Stackers’ +EV so she will always be outspent. Alice’s other option is acquire enough PoX slots, over 51%, in order to break the Stackers resolve, and so we have the same resistance against this attack as it is with the 51% attack.

In Summary:

I want to thank you for your attention. It’s an exceptionally long post and we had to develop our reasoning from ground truths and praxeology. I think this proposal presents zero compromises for Stack’s values: Nakamoto Consensus, open membership for block production, and preserves existing reward payout structures.



If Alice is willing to invest so much capital to reach her adversarial goal, she likely cares very little for the Stacks network and would not become an ally for the goals of the Stacks network. On the contrary, C2 is not satisfied as Alice should be receiving her invested capital (and then some) due to the nature of stacking. Procurement and liquidation of ASICs would be very difficult, time consuming, and costly. There is large upfront cost to stacking, but it is naturally returned.

Can you explain this quote better about how your proposed solution addresses Bitcoin MEV? “Controlling bitcoin transfers is a bitcoin-write-problem. We could however adopt a different block reward distribution schedule where the block reward is paid out pro-rata to block commitments made over a certain span of sortition blocks. This would virtually guarantee the Block Committer with the missed block will get rewarded when the next block is signed. This also solves the Bitcoin MEV problem and is one of the solutions under consideration.”

Is PoX recycling part of the proposed solution? It sounds like an individual decision that is dependent on the next stackers to make the same decision. Each step you take down that path, the stacker has 2x more reason to make the selfish decision. The first stacker to take the money benefits the most. This sounds like a (3,-1) decision. The concept doesn’t seem to work in a trustless environment. It is not individually economically beneficial for the stackers to lose their slot rewards. It is better to wait for the next stacker to do so. PoX recycling doesn’t appear to be a (3,3). This also assumes stackers are setup to be miners (block committers)

If Alice is able to procure the tokens, which in practice would take well over a billion dollars as there isn’t enough liquidity to fill a 600 million coin buy order at $0.5 each, what would be her remaining motivation to reorg the chain? If she successfully undermines the network, then congratulations she has reduced the value of the network and the token value will fall in tandem. If it falls 50% then she loses well over $500 million - $1 billion in unrealized losses. Very unlikely anyone would be willing to do this. Certainly possible but very improbable. The security postulate says there must be a very high upfront cost to do so as an impediment. And such is the case.

if a block signing is missed, the next block could be signed. Currently as I understand, a missed sortition means the next block reward is doubled to 2000 stx instead of the usual 1000. The idea is the payout could be spread out over a trailing window. So if the trailing window is 2 blocks and the missed block falls within this window and the 2000 Stx reward is shared with the missed block and thus the block committer who didn’t get his block signed gets paid.

This solution solves the bitcoin MEV problem
if in addition to above, the block reward payouts are in proportion to the block commitments. So if a MEV block won sortition with a $4 block commitment while adjacent block needed $400, then the MEV block gets 1% of the reward instead of the full 100%. Now since the MEV miner is in it to make a meaningful profit and they no longer are, it stands to reason they would cease their activity.

Subsequent stackers do not make 2x rewards of the previous round. Their total PoX reward balance increase linearly with Alice’s money-spend because that is precisely where the money comes from. It is all her money that is being recycled to use against her. If she puts $500 in each round then after 10 rounds there is $5000 working against her, not ($500 * 2^10).

Correct to say it is not part of the formal network protocol and that it is a group organized effort working within the parameters of the protocol. Faced with existential crisis of the network, the stackers with hundreds of millions at stake would not be willing take small bribe of a few cycles of stacking rewards (a few thousand dollars) in exchange of seeing the value of their tokens drop, losing potentially millions of dollars. So even an informal agreement between stacks could likely hold. However if we want to make it more robust, a smart contract could be written for Stackers to opt in to PoX-recycle. Once a threshold of stackers have opted in (let’s say 90%) then we know the counter-offensive can be launched with a very high chance of success.

This is only speculation based on praxeology as the real test of this is when the attack actually happens.

An election platform on Stacks would give a very plausible reason for someone to want to manipulate the system at any cost. Stacks has a financial system, yes. But it isn’t only a financial system. There motivations outside of financial gain for manipulating or even intentionally crashing a smart contract system.

The buy-in is rather large, but the input for Alice as the stacker should also get back throughout the stacking cycle if the goal wasn’t to crash the system.

This is PCR (sort of, I think). If you are just looking at the next (or previous) the MEV miner will still get the full reward if it wins 2 in a row (this does happen)

Who gets to make the decision on this? If orphaning is happening via a coalition (or one entity, multiple miners), it can difficult to detect. What is the decision point for the stackers to crowd out a miner?

PoX-recycling is not in response for block orphaning. It is only used in the event of an empty-block attack. And participation for PoX-recycling is voluntary.

Extend the window to 5 blocks, 10 blocks. It can be as large as the community decides. 2 was used as an illustration.

1 Like

The security postulates are only an impediment to an attack, but not absolute guarantee against it. Just like bitcoin hash power is only an impediment; it is not an absolute guarantee either.

Hey @jonkho, thank you for this very detailed write-up! It’s clear you’ve put a lot of careful thought into this problem.

Overall, I think you’re on to something here with leveraging the economic value of Stackers’ STX to help the network decide which blocks fall onto the canonical fork. In particular, I like that your proposal achieves this by separating block production (performed by miners) from block availability (performed by Stackers). This lets your proposed system leverage the economic weight of their STX holdings to produce a high-quality chain without converting the consensus algorithm into a PoS variant, which is a HUGE win.

While what you have presented here is good, I think there is a significant but fixable weakness in the proposal. Namely, chain robustness is not incentivized: Stackers can outsource block-signing to 3rd parties, and miners are the most incentivized party to do this work for them. As long as this remains true, then this proposal would not achieve the additional security budget it claims.

In your proposal, you say:

Right now, I can tell you that not all Stackers run nodes. Some of them use a 3rd party custodian, for example. While I don’t think it’s unreasonable to pressure Stackers to run nodes (sBTC imposes a similar requirement), I also don’t think that this proposal by itself creates any direct incentive for them to do so. Specifically, Stackers who don’t want to run nodes could just outsource the responsibility for signing blocks. This would potentially lead to a very brittle system, where chain liveness is only guaranteed by a small number of independent signing entities (smaller than the number of Stackers).

Now, depending on the proposal implementation, outsourcing could happen in one of two ways:

  • If the Chosen Stackers’ signing keys are different from the key(s) that hold their STX and PoX BTC, then Chosen Stackers could authorize a 3rd party to cache and sign blocks for them. This takes the Stacker out of the decision-making loop for advancing the chain tip, and possibly leads to this decision-making step consolidating into the hands of a few large custodians (i.e. exchanges with STX integrations). Despite this drawback, I think is actually better than the alternative below:
  • If the Chosen Stacker’s signing key is the same as the key(s) that hold the STX or PoX BTC, then Chosen Stackers would entrust their STX and BTC on a 3rd party custodian to get out of the business of running and maintaining a node. I think this is a worse outcome than the above, because it consolidates ownership of the STX into a handful of large entities (which puts the system’s liveness at risk – if the STX get stolen or get mishandled, then the chain could halt).

(We face a similar problem with sBTC – Stackers are additionally entrusted to maintain and hand-off the sBTC BTC wallet, but we can’t force them to run local nodes at the protocol level. The current sBTC design opts for the first signing set-up – it requires Stackers to use a dedicated sBTC signing key for their sBTC responsibilities with the expectation that some will outsource that responsibility to 3rd parties, but fewer than 70% of the STX signing power will be outsourced. This expectation is reasonable in practice because over 30% of the STX is owned by entities who are committed to running their own signers).

As you point out, there are of course indirect incentives to running nodes. For example, you trust your node more than a 3rd party node to give you an accurate view of the chain, you trust your node to faithfully sign blocks, and so on, in order to keep the chain healthy. However, because these incentives are indirect and thus hard to quantify, it will be hard for Stackers (especially less technically-inclined Stackers) to justify running nodes 24/7 when the option to outsource the work exists for cheap.

This means that this proposal must tolerate outsourcing. It will happen whether we like it or not.

You speak to this somewhat here:

While it is true that eventually the PoX yield will drop of Stackers don’t sign blocks, this does not preclude Stackers from outsourcing signing to a small number of 3rd parties, and create systemic risk in doing so.

Furthermore, the fact that Stacks blocks would not be valid without their Chosen Stackers’ signatures incentivizes outsourcing block-signing to the most competent signers: the miners. Miners stand to make the most money by ensuring that all mined blocks are correctly signed, and miners already run highly-available nodes 24/7. Therefore, miners are incentivized to help Stackers get their blocks signed as best as they are able, including taking steps like sharing block-rewards with Stackers for handing over their signing keys. This is a bad outcome: forcing unsigned Stacks blocks to be invalid creates the conditions for Stackers to make more money by delegating their signing authority (and security budget) to miners, thereby defeating the security increase in this proposal.

Ultimately, I think this could be addressed somewhat as follows:

  • Allow Chosen Stackers to confirm ancestor Stacks blocks that are not signed. If Alice and Bob are the Chosen Stackers for the Stacks block at height H, but that block’s prior A ancestors are not signed (but the (A+1)st ancestor is), then Alice and Bob’s signatures also authenticate those A signature-less ancestors. While this modification would trade some security budget for liveness beyond your proposal, this at least removes part of the incentive for miners to be the 3rd party signers. Also, this change would ensure that chain liveness is no worse than it is today (and no one is happy with the current speed; making Stacks blocks invalid due to missing signatures would make this UX worse).

  • Figure out a way for Stackers to lose their PoX rewards for blocks they don’t sign. This is equivalent to saying that Chosen Stackers only get BTC if their blocks get signed. If an upgrade such as this one is shipped concurrent with or after sBTC, then this is actually pretty straightforward: the protocol would require the Stackers’ PoX rewards to accumulate to the sBTC BTC wallet instead of their individual addresses, and Stackers would be required to disburse PoX rewards amongst themselves in a pro-rata fashion at the end of the reward cycle as part of the wallet hand-off. This would make it so that the protocol can then require Stackers to deduct the BTC rewards for Stackers who failed to sign their blocks in order for the wallet hand-off to be valid.

  • Allow Stackers to unilaterally set and change their dedicated block-signing keys at any time. This would provide Stackers with the necessary agility to keep the chain live and maximize their PoX payouts in the event that the party that signs their blocks (either in-house or outsourced) goes offline or misbehaves.

While these changes do not stop block-signing outsourcing, they at least make it so that Stackers are incentivized to ensure that the entities who sign blocks (be they in-house or outsourced) are always doing the best-possible job at it. Their PoX rewards depend on it, and the chain does not suffer degraded performance (i.e. punish users) in the event that some Stackers screw this up. While this does not stop miners from offering to be block signers, it does not give them any incentive to do so – they make money either way as long as a few Stackers are signing.

If we further make it so that the Chosen Stacker is always the sBTC wallet address (a consequence of my second point above), then this can be made tantamount to requiring at least 70% of all STX to sign a block. Specifically, the protocol can be constrained to require that the block signature be a threshold signature generated by at least 70% of the STX. We’d use the same mechanism for generating these signatures as we do for generating BTC signatures from the sBTC wallet, for example.

Anyway, thanks again for taking the time to write this up! I think a lot of what you have here is actionable.

Hi Jude, thank you for the detailed feedback and good words.

For stacking pools, we can look to bitcoin mining pools for a solution template. In bitcoin mining, miners who own ASICs contribute their hash power towards the pool; physical or remote access to their capital equipment (ASICs) is not typically given. We can design something similar where Bob can contribute a “virtual balance” - not actual tokens - over to Pete the pool operator. Bob can also revoke this “virtual balance” at a moment’s notice. This is how it could work:

  1. Bob owns 6000 STX in his wallet address. He sends a signed message to Pete indicating he wishes to delegate a virtual balance of 5000 STX to Pete’s address for stacking.

  2. Pete receives this message and also adds his signature to the message and invokes a Clarity system call to process it.

  3. The system verifies the signatures, addresses, and balances. It attaches an attribute (let’s call it “delegated-virtual-balance”) to Pete’s address and increments it to 5000 and locks 5000 STX in Bob’s address.

  4. Now when Pete goes to stack, all arithmetic calculations around the stacking protocol will use the compound value {address-balance} (Pete’s own coins ) + {delegated-virtual-balance} (Bob’s contribution) instead of just {address-balance} to calculate stacking power.

  5. The system also issues a pair of non-transferable tokens, each to Bob and Pete as a receipt. Either Bob or Pete can invoke a Clarity system call with this token to reverse the delegation of virtual balance, deducting the virtual balance and consuming both tokens.

With this design Bob doesn’t give up any signing authority over and either doesn’t have to manage keys. The range of freedom is restricted and the attack surface is small. The system can also look up instantly how much stacking power a pool has without validating numerous keys to see if they still hold. Bob can also revoke his stacking power at a notice if Pete is acting maliciously and we can look at bitcoin pool behavior as already established tribal knowledge of how it polices itself. The community would benefit from having a public dashboard that transparently shows who the pools are, their delegated balances and block-signing record. Stacking.club could have been great unfortunately it seems they are not restoring full functionality.

As for confirming missed ancestor missed blocks, If I understand correctly that transactions in non-confirmed blocks are back in the mempool where then the next block could include them, then confirming an ancestor block may not make sense. I am biased towards seeing how much missed signings is actually a problem before designing a core protocol to take on more assumptions. This usually leads to more fragility.

As far as penalizing missing signings, it’s a good idea. I’m still biased towards reviewing whether this would be an actual problem before adding layers of indirection and complexity.

How is the winning block determined?

Step 2 specifies Block Committers submit candidates, and Step 5 presupposes there is already a winning block from these candidates, but neither Step 3 nor 4 specify how a winning block is selected. It would presumably still be determined by a vrf of sats committed?

If so, it’s not clear to me how your proposed solution does anything to address what you identified as a problem in B1:

Wouldn’t the same still be true under the proposed consensus mechanism, and a “miner” (now called a Block Comitter) could just monopolize block candidacy in the same way, and for the same cost, as they can currently monopolize block creation?

Conversely, doesn’t the “PoX-Recycling” you suggest as a mitigant to this, already exist in current PoX as is? In current PoX as is, what is stopping honest stackers from taking their stacking rewards and mining with them to prevent attacks?

Correct. The sortition process is unchanged. Recall the block commitments are made along with the hash of the candidate block. So after the sortition winner is declared, anybody can see what the winning block hash is.

Yes and I want to expand on this point. “Monopoly mining” is not an issue in the proposed solution because the monopoly miner cannot 51% attack the chain via their monopoly whereas in the current network they can. The reason we are concerned about monopoly miners is because of the attack vectors monopoly mining exposes the network to. If monopoly mining did not expose viable attack vectors, it’s not a problem. The proposed upgrade removes viable attack vectors that monopoly miners currently have so attacks are no longer viable.

I do expect that even after the upgrade that monopoly mining to continue. Miners are in it to make a profit. Where does the profit come from? It comes from the spread between the block commitments they paid against the (block reward + fees) they collect. This is the only formula that drives mining. Miners do not have other consolidated capital they are looking out for. It’s simple arbitrage, buy and flip. Let’s Suppose the profit margin is 5%, a rational miner will want to earn 5% on the whole entire value of the block reward rather than just a small fraction of the block and let other miners come in and take the profit on the rest. So monopoly mining is expected and is harmless if they don’t have the ability to attack the chain with it.

In the current protocol PoX can be recycled as a counterattack to stop a malicious miner. However, because it’s so cheap/easy to reorg the chain, that once the counterattack concludes (which it will or else the stackers will have no PoX yield), the malicious miner can resume to 51% mine and reorg the chain from the point where he was kicked out. So the “good blocks” are just reorg’ed out of existence and the counterattack was futile.

How so? Do you simply mean that a monopoly miner in the proposed chain can censor or paralyze the chain, but can’t profit from monopoly mining without acquiring a large stake?

This seems a bit inaccurate/exaggerated. Simply counter-attacking to win 1-of-every-N blocks would be sufficient to prevent an N block deep re-org no? So it is not true that all the “good blocks” could be so easily reorg’ed away.

I think the stronger leg to stand on is saying that current PoX could also use recycling as a defense mechanism against someone censoring/paralyzing the chain, but that hasn’t happened, thus the defense has not been necessary.

If it were to happen, whether in the current or proposed system, PoX-recycling can defend against censor attacks, and in the proposed system requiring a large stake defends against profit-motivated “mining monopoly” attacks.

Overall this proposal reminds me of something @ryan mentioned to me about making a hybrid of PoX and PoS. People can argue all day long about semantics, I will not be partaking in that, but IMO there are enough similarities that a reasonable argument could be made that this change introduces a PoS mechanism into Stacks consensus (“if it quacks like a duck…”).

In the practicalities of the types of attack vectors (paralyze vs re-org), economic incentives (acquire stake vs expend energy/capital), and roles (block creators and block validators vs miners) it introduces, it is a PoS flavor mechanism.

There is a lot of baggage that comes with PoS as a consensus mechanism, especially in the Bitcoin community, so I think this point should not be so lightly brushed aside. Imo, a potential solution to the current re-org attacks that does not require PoS changes would be preferable.

1 Like

Under the proposed upgrade, the monopoly block producer cannot reorg the chain unless he also controls over 51% of the stacking slots. This is a statistical fact, not tied to profitability.

The point is once the Stacker’s defense falls off, the monopoly miner can resume and orphan the away the “good blocks” and continue to append empty blocks.

For example under the current network:

  1. Alice the attacker is empty-block-attacking and blocks 1001 and 1002 is empty.

  2. Stackers starts to recycle PoX at block 1003. Alice becomes -EV at block 1003. Stackers win block 1003 and 1004 and transaction flows again. Chain-tip is at block 1005.

  3. Alice stops empty-block-mining and stacker’s back off the defense. Now Alice is the monopoly (100%) miner again. She builds a new secret fork from block 1003 instead of the current chain tip (1005) for the next 3 blocks. Now her secret fork can reorg away blocks 1003 and 1004 when she publishes it.

Under the proposed upgrade this step just described is not possible unless she also wins her pair of PoX slots to become the Chosen Stacker. This is the investment high barrier that impedes her from reorg’ing under the new proposal.

The proposal does not use proof-of-stake consensus as a means to tie-break a fork conflict. It uses Nakamoto. I say this as an incontrovertible fact.

Right - they can not reorg it, they can paralyze it (a liveness failure not a safety failure).

This doesn’t address my point. For instance, in your above example, if honest miners win 1 of 2 blocks (whether by PoX Recycling or “organic” means), then Alice indeed can not do this reorg right?

I think there’s something here to this idea about PoX Recycling being a mean to protect the chain for reorgs, without introducing a hybrid-PoS model.

Not interested in debating semantics.

  • Block validation/finalization in the proposal is, as you might say, as an incontrovertible fact, determined by stake in the network.
  • Block production is, at least partially, dependent on validators who stake their tokens to back the security of the network, and these parties have a say on validation in proportion to the size of their stake.
  • Block history can not be reorged, such as in Nakamoto, longest-chain consensus mechanisms, but paralyzed via an “empty block attack”, such as in Proof-of-Stake consensus mechanisms (liveness failure).

The proposal is of course not literally purely PoS. However, that does not change the fact that this introduces a PoS mechanism into the consensus, making it a PoX/PoS hybrid.

I appreciate the work going into these thoughts. Imo, formalizing PoX-Recycling as a chain defense mechanism to prevent reorgs has a lot of promise to further explore (thank you for bringing up the concept) without requiring the PoS elements.