Stakechain: A Bitcoin-Backed Proof-of-Stake

Abstract

We propose an energy-efficient solution to the double-spending problem using a bitcoin-backed proof-of-stake. Stakers vote on sidechain blocks forming a record that cannot be changed without destroying their collateral. Every user can become a staker by locking Bitcoins in the bitcoin blockchain. One-time signatures guarantee that stakers lose their bitcoin stake for publishing conflicting histories. As long as 34% of the stakers are honest the sidechain provides safety, and with a 67%-majority it provides liveness. Overwriting a finalized block costs at least 34% of the total stake. Checkpoints in Bitcoin’s blockchain mitigate classical attacks against conventional proof-of-stake algorithms. A stakechain’s footprint within the mainchain is minimal. The protocol is a generic consensus mechanism allowing for arbitrary sidechain architectures. Spawning multiple, independent instances scales horizontally to a free market of sidechains which can potentially serve billions of users.

R. Linus—Independent Researcher.

A Appendix

1.1 A.1 Staking Contracts in Bitcoin Script

Currently, burning funds is not supported in Bitcoin script. Committing to a certain spending transaction requires a construct called Covenants². Yet, upcoming Bitcoin features such as SIGHASH_NOINPUT³ or OP_CHECKTEMPLATEVERIFY⁴ or OP_CAT allow trustless covenants. For now, we need a workaround to implement the staking contract. In the following we discuss solutions. All of these trust-minimizing workarounds are highly undesirable additional complexity. Fortunately, in the long term, we will certainly have some clean solution for covenants.

1.1.1 A.1.1 Trust-Minimized Workaround 1

A simple solution is to introduce a trusted party, say, Bob:

• Alice creates a funding transaction with the following output:

  • Alice can spend her money in one year.

  • Alice and Bob can always spend her money collaboratively.

• Bob pre-signs and publishes a punishment transaction:

  • burn her collateral now to address 0x000...000 (if Alice agrees).

• Bob immediately deletes his secret key (in case his machine gets compromised).

There is no counter-party risk here for Alice, because she executes her funding transaction only after she received Bob’s signature for the punishment transaction and completed her setup.

For the system to minimize trust in Bob, multiple parties can participate and if only one is honest and deletes their key, then this scheme is secure. Bitcoin script currently supports more than 60 participants per multi-signature transaction [14].

Containing more than 60 signatures, the punishment transaction becomes large and expensive, but as long as the staker is honest, the transaction doesn’t need to be included in Bitcoin’s blockchain. To incentivize Bitcoin miners to execute the punishment transaction quickly in case of misbehavior, it pays a high miners fee.

It is possible to further minimize trust in single parties by using ECDSA signature aggregation to allow for thousands of Bobs participating in a single combined signature [15]. When Schnorr signatures become available in Bitcoin, such aggregated signatures will become more simple because of the linearity of Schnorr’s scheme [16].

The Bobs could be a trusted federation or a percentage of the current stakers. With aggregated signatures they could also be a significant percentage of current coin holders. The trusted parties sign blindly to reduce the risk of censorship. A simple scheme exploits that Bitcoin transactions use double SHA256. Thus, Alice can ask Bob to sign the single-round SHA256 hash of her transaction. The second round is Bob’s hashing function for his signature algorithm. This way Bob doesn’t learn what he signs until Alice publishes her contract.

1.1.2 A.1.2 Trust-Minimized Workaround 2

The bitcoin mailing list member, ZmnSCPxj, came up with the following trust-minimized covenant construction based on replace-by-fee, which requires no softfork.

We can implement the staking contract with a simple

OP_CHECKSEQUENCEVERIFY ensures, as a side effect, that the spending transaction opts in to replace-by-fee. Thus, if the pubkey <​A>​ is used in a single-sign signature scheme (which reveals the privkey if double-signed), then at the end of the period, anyone who saw the double-signing can claim that fund and thus act as “Bob”. Indeed, many “Bob”s will act and claim this fund, increasing the fee each time to try to get their version onchain. Eventually, some “Bob” will just put the entire fund as fee and put a measly OP_RETURN as single output. This “burns” the funds by donating it to miners.

From the point of view of Alice this is hardly distinguishable from losing the fund right now, since Alice will have a vanishingly low chance of spending it after the collateral period ends, and Alice still cannot touch the funds now anyway. Alice also cannot plausibly bribe a miner, since the miner could always get more funds by replacing the transaction internally with a spend-everything-on-fees OP_RETURN output transaction, and can only persuade the miner not to engage in this behavior by offering more than the collateral is worth (which is always worse than just losing the collateral).

A OP_CHECKTEMPLATEVERIFY would work better for this use-case, but even without it you do not need a trusted party to implement the staking contract.

Drawback of this solution is that cheating stakers are not immediately removed from Bitcoin’s UTXO set. Yet, this might be a decent tradeoff because we have a succinct proof to exclude a cheating staker: knowledge of his private key.

Another drawback is that it requires trust in miners. If Alice cooperates with a significant share of Bitcoin’s hash power, she has proportional chances of mining the transaction herself. Then she would not have any cost of attacking the chain.

1.2 A.2 Staker Signatures

In this chapter we discuss details of the stakers signatures. We explain how to pre-commit to a particular nonce per block efficiently. Finally, we explain a scheme for better hot key security.

1.2.1 A.2.1 Compact Nonce Commitments

Constructed naively, stakers would have to pre-commit to millions of nonces within their funding transaction. A more efficient construction is to let stakers subsequently commit to their next nonce by signing it within their previous signature. This amortizes the inclusion proof size to basically zero. Furthermore, each staker has to store only one nonce at each point in time.

Jeremy Rubin contributed this scheme for constant-sized commitments to sequences of nonces. Furthermore, he implemented a staking contract in Sapio⁵.

1.2.2 A.2.2 Hot Key Security

Hardware wallets are usually stateless and therefore they’re incompatible with nonce commitments. Thus, to protect the stakers’ nodes, they can use a staking key to sign sidechain blocks and a separate redeem key to spend the bitcoin deposit once it is unlocked. Until then, the redeem key remains in a cold wallet. Nodes having access only to the staking key are a much less attractive target for attackers.