Proof-of-Stake sidechains for Bitcoin

[LLFourn]

I recently came across nomic which describes itself as a proof-of-stake Bitcoin sidechain based on tendermint. Best technical description is in the whitepaper[1]
The idea is basically that you can have a sidechain where the custodians/block creators are chosen based on how much pegged bitcoin stake they have in the sidechain. This is dynamic so as coins change hands on the sidechain the output that owns the mainchain coins has its script pubkey changed to reflect this by spending to a new address.
The obvious downside is that you that if you 9 BTC (or some chosen threshold) on the sidechain out of 10 BTC you can just pluck the remaining 1 BTC and run away.
That doesn't seem like a deal-breaker to me since you've got to have some security assumption (though it is quite a spicy one).

In practice it is probably going to be less secure than things like the liquid sidechain.
But they have HSMs, a public "membership" and "oversight" board and sophisticated custodians with data centers and stuff.
Where is the sidechain tech stack for unreliable plebs and raspberry pis?
So I see this as giving up some security to get a permissionless consensus on the sidechain. You can bootstrap it easily and lets totally anonymous coins join in the protocol. It's more risky but might be more resistant to targeted corruptions than a federated sidechain.

So I'd be really interested to see a research paper on the optimal protocol design for a proof-of-stake Bitcoin sidechain.

There are a two interesting questions here off the top of my head:

1. Can the mainchain custody output design be improved? For example, could we you build a threshold schnorr committee and do the signing in the sidechain protocol without putting the protocol data on the actual sidechain (or at least avoiding it in the optimistic case)?.
2. How do you make it impractical to purchase a supermajority of sidechain coins and steal the remaining?

Thoughts?
[1] https://gist.github.com/mappum/da11e37f4e90891642a52621594d03f6

[mappum]

The idea is basically that you can have a sidechain where the custodians/block creators are chosen based on how much pegged bitcoin stake they have in the sidechain. This is dynamic so as coins change hands on the sidechain the output that owns the mainchain coins has its script pubkey changed to reflect this by spending to a new address.

Your understanding is close but isn't quite accurate. I agree with your assessment that if the scheme did give people "voting" weight based on how much BTC they have deposited into the sidechain, someone could simply deposit a large amount and steal the rest.

In our model, there is actually a native token used purely as stake which gives nodes their voting power. If the nodes are malicious in any way (e.g. signing a transaction we didn't expect them to sign), their stake token is burnt as punishment (aka. "slashed"). This has to be a separate token native to the sidechain just for this reason, because the protocol can then slash malicious nodes when there is proof of doing something bad.

This brings up the question of how people can get the token (which isn't addressed in that design document). Our ideas for granting the staking token have been around 1) paying it to Bitcoin miners, 2) paying it when someone proves they burnt BTC, or 3) paying it when someone locks up BTC in an output that makes it unspendable for some period of time.

[LLFourn]

@mappum thanks for clearing that up. So we can generally ask "what is the right way to assign consensus rights in a permissionless Bitcoin sidechain".

This has to be a separate token native to the sidechain just for this reason, because the protocol can then slash malicious nodes when there is proof of doing something bad.

Why is this? I think you could slash pegged BTC also?

There is also the question of the consensus algorithm for the sidechain (whether to use BFT like tendermint or Ouroboros Proas or Algorand etc).

[mappum]

Why is this? I think you could slash pegged BTC also?

Other than the problems you brought up in the original issue, there's also a sort of weird circular dependency that happens when you use pegged BTC as stake: if the attackers succeed and steal the BTC reserve, they also steal back all their stake. Slashing the token on the sidechain which is redeemable for BTC is pointless then since the attackers have already recovered the actual BTC.

On the other hand, if the stake is only a token on the sidechain and is not backed by BTC in the reserve, when an attack happens a fraud proof can get broadcast to the sidechain and the protocol can just slash this native token guaranteeing the attackers lose some value.

We can even make sure they lose the stake even if a fraud proof is not broadcast, by only letting them unlock their stake by proving the BTC reserve has moved to an output that no longer has their key in the multisig. If a successful attack happens, the signers will no longer be able to show a valid new output that proves they are no longer in the multisig, and have forfeit all of their stake by causing it to be permanently locked.

[mappum]

There is also the question of the consensus algorithm for the sidechain (whether to use BFT like tendermint or Ouroboros Proas or Algorand etc).

Our implementation is built using Tendermint since we have experience with it, but the sidechain design is mostly agnostic to this decision.