mappum
commented
3 years ago @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
In the Bitcoin Peg doc, it says:
There is a safety mechanism, described here:
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:
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:
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:
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 :)