Hardening the withdrawal mechanism

[john-light]

In the Bitcoin Peg doc, it says:

To disburse funds from the reserve, more than two-thirds of the validator set must sign the Bitcoin transaction (weighted by voting power).

There is a safety mechanism, described here:

[W]e can hold these signatories accountable by creating a rule on the peg network to remove voting power and tokens from any signatory which has signed an unexpected transaction, also known as slashing. The likelihood of collusion is then reduced since potential colluders would be able to gain from reporting malicious signatures to the peg network in a signatory fraud proof transaction.

Taken together, we can assume the funds held in the reserve address are safe if at least 1/3 of the signatories (as weighted by voting power) are honest.

However the system is NOT safe in two specific scenarios:

1. Where one party controls 2/3+1 voting power, or
2. Multiple parties collude to control 2/3+1 voting power, for example multiple mining pools.

In both cases it becomes possible for 2/3+1 signatories to ~instantly (within one mainchain block) steal all funds held in the reserve address, with no practical recourse to victims.

Since voting power can be acquired by bitcoin miners for "free" simply by mining bitcoin, the marginal cost of acquiring voting power is near zero making this attack feasible as soon as the discounted value of future fees/demurrage that could be earned by validators for acting honestly is worth less than the value of BTC that could be stolen today (i.e. whenever 2/3+1 signatories decide "a bird in hand is worth two in the bush"). If the voting power tokens take on a secondary market value that miners would be giving up by attacking Nomic, this increases the value of BTC that can be safely held in the peg to be any amount less than the current market value of 2/3+1 voting power (assuming sufficient liquidity to sell that much voting power) plus the discounted value of future fees/demurrage that could be earned by voting honestly.

Hardening the withdrawal mechanism is a problem all two-way bitcoin pegs have to overcome. I've written about some of the techniques used by other two-way pegs here. There are three main ways that other two-way pegs try to harden the withdrawal mechanism:

• A withdrawal delay (e.g. Drivechain)
• A bond (e.g. tBTC)
• Hardware security modules (HSM) or trusted execution environments (TEE) (e.g. RSK, pTokens)

I think it's worth thinking about whether Nomic can implement one or more of these methods to further harden the withdrawal mechanism.

Withdrawal delay

In the case of a withdrawal delay, this method is relying firstly on game theory and should validators ignore the game theory and go ahead with an attack, then secondarily on time and vigilance. The idea here is that if validators do try to steal from the reserves, there is a delay between the time that they start their attack and when the attack is complete. In the case of Drivechain this delay is six months. If users of a drivechain that is under attack notice at any time during these six months that an attack is under way, they can organize user-activated soft fork (UASF) on the bitcoin mainchain that rejects any blocks supporting the attack transaction. The game theory here suggests that as long as this defense is known and plausible, validators will never try the attack in the first place. But if validators do still attempt the attack, then users can organize to stop the attack and most likely won't trust that drivechain going forward, thus validators forfeit any future fees they could have earned from the drivechain had they simply remained honest and not killed the goose that lays golden eggs.

See "Does Drivechain rely on a UASF to prevent a sidechain theft?" in the Drivechain FAQ for more info about this.

Question: Is it possible to build a two-step withdrawal mechanism with a delay, to mimic the type of withdrawal delay implemented by Drivechain? Step one would be to "announce" the withdrawal, so that everyone can observe a withdrawal will happen at some future date (along with the details of the withdrawal, such as which addresses the withdrawal will be sent to). Step two happens much later, when the withdrawal actually becomes valid and withdrawal recipients can actually move the coins that have been withdrawn to their designated addresses.

Bond

In the case of a bond, the idea here is for validators to have some value at stake above and beyond the cost simply to become a validator. In the case of tBTC the bond is equal to 1.5x the value of the BTC held by signatories, and signatories can be individually targeted for slashing if they behave maliciously. 66% of the value of the bond is used to recapitalize the system, and the rest goes to whoever reported the theft attempt. Nomic also has slashing, however slashing cannot be enforced in the 2/3+1 attacker scenario since the attacker could censor any slashing transactions. Some ideas for how Nomic could implement a bond:

• Implement a tBTC-like system on Nomic. This would necessarily limit the value of BTC that could be deposited on Nomic to be less than the value of collateral assets at stake. If voting power tokens were used as the collateral asset, then this would also ensure that an attack is (almost) never profitable. More info about the tBTC security model can be found here.
• Implement a bond on another chain, with a cryptoeconomic dispute resolution system as "enforcer" of the bond. For example, Nomic signatories could be required to deposit a bond into a smart contract on Ethereum and increase the size of their bond as the value of BTC held in the Nomic reserve address increases. The value of collateral in the bond contract would always have to be greater than the value of BTC held in the reserve address. If the signatories ever tried to steal BTC from the reserve address, then a cryptoeconomic dispute resolution system such as Aragon Court could be used to report the theft and slash the bond. This adds an additional cost to attacking the Nomic peg: the cost of attacking the dispute resolution mechanism used to slash the bond. Not indefeasible, but it does increase the margin of safety of the withdrawal mechanism.

HSM & TEE

In the case of HSMs and TEEs the main idea here is that signatories have to use some kind of secure hardware that the signatory is unable to access the contents of. This secure hardware will enable third parties (such as sidechain users and other signatories) to remotely confirm that the signatory is running the correct software using remote attestation. The software running in the secure hardware would ensure that the signatory only signs honest withdrawal transactions. Secure hardware from multiple manufacturers could be used to prevent any single point of failure. The main risk here is new types of side channel and direct attacks that compromise the integrity of the secure hardware, thus rendering it useless and putting users into a false sense of security. I wouldn't consider this a silver bullet solution but rather one component of an overall defense in depth strategy.

Conclusion

Nomic is an interesting system and it does seem that the peg can be defended up to a point, the question is can we harden the system even further to increase the value of BTC that can be held in the system? I think the answer is yes! There is no silver bullet, especially if we are attempting to work within the constraints of the existing bitcoin protocol, but I believe a combination of techniques such as those described above could be used together to strengthen the peg, harden the withdrawal mechanism, and enable even more BTC to safely enter the Nomic system than is possible under the current design.

Disclosure: I work at the Aragon Association, which sponsors the development of the aforementioned Aragon Court protocol. I am not writing officially on behalf of the Association, I am just a sidechain enthusiast who sees a potential use here for the technology I work on at my day job :)

[mappum]

@john-light Thank you for the thoughtful analysis.

Withdrawal delay

This mechanism is compelling, but the huge cost of locking BTC for 6 months increases costs and hurts UX in a huge way. We could consider something like this in a future version, where the majority of the reserves are delayed like this (the equivalent of cold storage for the peg), but a portion is kept without a delay in order to rapidly process most withdrawals (assuming the amount of BTC in reserve doesn't fluctuate significantly).

tBTC comparison/Bonds

Thanks for raising the issue of the difference between our slashing model and tBTC's. To reiterate in my own words, while both systems slash signatories for signing unexpected Bitcoin transactions, a consensus takeover of the Nomic chain (which means power to censor transactions) would allow signatories to steal the reserve and still be able to sell off their bonds. Whereas in tBTC, even if signatories had a hashrate majority, they would not be able to reclaim their bond because the owner of the BTC did not close the deposit.

But in our design this is actually a relatively easy fix - we can ensure an attack leads to losing stake (even when censoring fraud proofs) by only unbonding stake after proof that the expected checkpoint transaction was accepted on the Bitcoin blockchain. This means that if signatories steal the reserves by creating an unexpected checkpoint transaction, they will not be able to create a Bitcoin SPV inclusion proof for the expected checkpoint (since that would be a double-spend of the reserve output, which would be rejected on the Bitcoin network), and their bonds will not be released to them. So even though they can freely censor transactions on Nomic, we assume they cannot pull off a significant reorg of Bitcoin (we can tune the number of confirmations to the required security level).

So thanks for pointing that out, excited to make this even more secure!

HSM & TEE

I very much agree that HSM's are a good best practice for key management on high-profile nodes like signatories. This is already standard in the Cosmos world, we'll just have to ensure we build out the proper tools for doing this with the Bitcoin keys as well as the Tendermint validator keys.

As for TEEs, I'm not currently a huge fan since it seems like it requires a lot of trust in hardware manufacturers (of course we do already trust that they will execute our code correctly, but this goes a step beyond that). If TEEs worked really well, it seems we could do away with PoW and PoS which logically is a pretty big jump. But if there is a way to opt in to adding security with TEEs without any possible downsides then of course it is worth investigating.

[john-light]

the huge cost of locking BTC for 6 months increases costs and hurts UX in a huge way.

The way the UX can be improved while still preserving security is by having exchangers who will ~instantly trade NBTC for BTC. This could even be done in a trust-minimized way with atomic swaps. The cost might be a bit more than going through the normal withdrawal process but that is the price of having the added security of the withdrawal delay plus the convenience of instant exchange via trust-minimized exchangers. That said your proposed method of having most reserves subject to withdrawal delay and some clearing instantly is an interesting middle-ground!

So thanks for pointing that out, excited to make this even more secure!

Nice 😎

As for TEEs, I'm not currently a huge fan since it seems like it requires a lot of trust in hardware manufacturers (of course we do already trust that they will execute our code correctly, but this goes a step beyond that). If TEEs worked really well, it seems we could do away with PoW and PoS which logically is a pretty big jump. But if there is a way to opt in to adding security with TEEs without any possible downsides then of course it is worth investigating.

Fair enough! I'm also skeptical of TEEs but have seen several projects pull off some black magic using them e.g. pTokens so figured I'd mention in case there's something I'm missing/ something worth considering there.

Edit: regarding HSMs maybe something like what Sergio Lerner has proposed for RSK would work?

The game-changer here is a new version of the HSM (hardware security module) that the all federation functionaries will soon be running. This upgrade provides the level of security of a security enclave running an embedded SPV node which follows hashrate. You can compare this to the pBTC token, but our solution uses a secure element in the HSM that does not share any resource with the main CPU, instead of pBTC which is based on Intel SGX, whose security has been broken over and over in the last couple of years (18 vulnerabilities in total!)

https://blog.rsk.co/noticia/sergio-demian-lerner-june-2020-ama/