nomic-io/bitcoin-peg

Bitcoin sidechain module for Lotion and Coins (A Cosmos Bitcoin peg zone implementation)

bitcoin-peg's Issues

Handle signatory fraud proofs

We currently don't handle the fraud proofs as outlined in the design. We'll have to be able to process transactions which include proof of a signatory signing an unexpected transaction which spends the reserves, in order to reduce the likelihood of theft by malicious signatories.

Lock and Witness

Hi, I saw that in the documentation for PEGGY(https://github.com/cosmos/peggy/tree/master/spec##smart-contract-component), the readme also mentioned that Bitcoin can be linked to cosmos network through a peg zone. However, Bitcoin does not support Smart Contracts, which, I think, play a big role in the witness and lock/unlock step. How do you make Bitcoin perform thoses steps without using smart contract?

test hangs after deposit

Cloned repo, installed dependencies with npm, and am trying to run the integration test. No logs because the test doesn't actually fail, it just hangs after the following output:

set up data dir: /var/folders/hk/nsbgw1kn4n5dgzzr1sl_2yr40000gn/T/0.h27mjcz95ag
started bitcoind
generated bitcoin blocks
started peg network nodes
connected lotion client
committed signatory keys
relayed bitcoin headers
sent deposit transaction

Any thoughts?

Hardening the withdrawal mechanism

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 :)

Support dynamic validator sets

For simplicity, the code currently assumes the validator set does not change. The design supports changing validator sets in theory, but there will be some extra edge cases to handle, e.g. deposits sent to an outdated signatory set (in this case we'll have to check if the current signatory set can still spend the output, etc.).

Pay/Sign to Contract instead of OP_RETURN for destination address

Have you considered using pay-to-contract or sign-to-contract to commit to the destination address in the Tendermint chain instead of OP_RETURNs?

Puts less state on the chain, as well as guarantees the data can be retrieved by nodes which are not run with txindex=1

sign-to-contract basically modifies R in an ECDSA signature to also include the message you want to commit to (you also modify the nonce to ensure that the verification algorithm evaluates to true)

From the linked article:

def ECDSAsign2contract(x,m,c):
    k = deterministic_nonce(x,m)
    R = k*G
    e = k + h(R || c)
    Q = R + h(R || c)*G  # which is Q = e*G = C(c,R)
    q = Q.x mod n
    z = e^(-1) * (m + q*x) mod n
    return (q,z), R

Split Bitcoin transactions

Bitcoin transactions signed by signatories use all spendable UTXOs as inputs (which come from deposits and change), and pay to all pending withdrawal outputs. The current implementation does this all in one big transaction.

Since transactions aren't Merkleized, clients that want to SPV-verify the transaction have to fetch the whole big tx. When this gets too big, we'll have to split this up into 3 transactions as in the design document: one with deposit UTXOs as inputs and 1 output, one that spends this and the previous change output, and another which pays the withdrawals. This way, clients can look at just the chain of the 2nd kind of transaction to follow the reserves of coins without needing the deposits/withdrawals.