Miner Voting Covenant for Sidechain bridging

Continuing the discussion from Will SHA-Gate be ready for the May 15th upgrade? on an improved miner voting covenant for sidechain bridging:

I’m finally open-sourcing the improved version of the first SHA gate contract! The contract is well commented so as to make it readable and invite review! Here it is: https://github.com/mr-zwets/upgraded-SHA-gate/blob/main/sha-gate-improved.cash

As mentioned in the thread

  • better architecture solves Bitmain firmware issue, requires way less voting and makes monitoring the contract way easier (!)
  • actually enforces only miners in a certain window can vote (!)
  • allows withdrawals of arbitrary amount (!)
  • changed variable voting period to fixed length
  • 5 operators (increase from 3)
  • removed unnecessary op_return message

There’s also a second smart contract in the repo for the sidechain withdrawals.

7 Likes

Made some necessary optimizations to the contract, because apparently the cashscript “cashc” compiler does not take the contract arguments in to account when calculating bytesize so the contract was actually over the 520 bytesize limit. The improved version uses pkhs instead of public keys and replaces long hardcode bytesequences full of zeros by an int to byte conversion to save on bytesize.

The contract is now 194 opcodes (max 201) and 478 bytes large (max 520) including contract parameters. This change means that the contract can still fit up to 6 operator pkhs but no longer 8 like I first thought.

The demo contract made also did not take this compiler behavior in to account but managed to stay under the limit with 193 opcodes and 504 bytes (but the documentation said it was only 359 bytes)

4 Likes

I was suggested by @bitjson to only keep a hash of the concatenated public keys as a contract parameter instead of the different public key hashes. This way the public keys are provided in the unlocking bytecode and do not run into the bytesize constraint discussed above! It also makes the contract quite a bit smaller for all other contract functions that do not use the public keys. :grinning:

The number of operators was not that important to me as the contract was a simple 1-of-n, so you needed at least 1 honest operator to make valid withdrawals sometimes but 1 malicious operator would be able to propose a withdrawal stealing all the sidechain funds. Clearly not ideal :sweat_smile:

Now the contract is upgraded to require an m-of-n multisig! It requires a 3-of-5 now by default but adding extra operators adds very little in terms of opcode count and bytesize so a 5-of-7 or larger would also be possible.

The upgraded contract and the updated document to reflect the multisig changes are still at the same github repo. I added discussion sections on malicious hashrate voting, miner participation, tracking the covenant and 3rd parties using the covenant also.

3 Likes

@MathieuG this is amazing work! congratulations! :clap: :+1:

unfortunately I’m seeing this 2 weeks late, smh

I’d love to hear about any progress that you’ve made since this original post. Have you received feedback from the SmartBCH team?

Given the current drama surrounding the custodial issues with the treasury, I’m working on a proposal to move us forward. Hopefully we see this resolved amicably & quickly; however, imo those of us that “can”, should “do” something to be prepared for the worse.

cheers!

1 Like

There’s now a fully working demo of the contract on testnet4!!

edit: botched the announcement half-way through :sweat_smile:

3 Likes

That’s a fantastic demo! :star_struck:
I’ll take a deeper dive over the weekend for sure!
Looking forward to reviewing the contract code…

Keep up the great work, and please let me know if there’s anything specifically I can do to help support your efforts.

I’ve been working on my own “formal” proposal to resolve the current Treasury drama, amongst other things.

1 Like

I reviewed your Upgraded SHA-Gate contract and its supporting documents. Looks really good to me. Wish this had been done from the start back in Aug `21.

I have a couple questions and comments:

M-of N for operator keys: 3-of-5 (can easily be extended to 5-of-7 or even larger)

What would you say is the “maximum” for N? It appears to be limited by how many public keys can be submitted to the contract during initWithdrawal.

In my Bailout plan, I suggest that “single-digit” N is insufficient. Historical evidence has shown that these smaller quorums have sufferd greatly from having their keys compromised. How is often “undetermined”, which often lends to the notion of an “inside” job.

I aim to increase N to at least 20, but ideally, I’m hoping to support 100+ Validators during each quorum. To do so, I’m thinking of using a Merkle-tree style system of Covenants-of-Covenents. eg. if the maximum number of Validators per covenent is say 10, then we could have 10 individual contracts, that each use 1 N slot in the “Master” Covenant, which would then effectively support 100 Validators.

Does that make any sense? Would you know how to do something like that or recommend a better solution to increasing the number of participating Validators?


As outlined above this version works with a fixed length voting period and proposes to extend this to 2016 blocks (~2 weeks, which is the same length as the epoch for validator election).

Even with batching each withdrawal, 2 weeks seems like an awfully long time to have to wait on a withdrawal. Can you explain in more detail how this would work in practice? Who would typically be making these withdrawal requests? How would they manage the delay in receiving their assets?


BCH still uses 20 byte P2SHashes for smart contracts which opens them up to profitable collision attacks when holding balances upwards of a few hundred thousand USD (see post on Bitcoin Cash Research forum). SHA-gate is less vulnerable to this attack as it only allows operators to add arbitrary data to the state.

Could you explain what the “worst case” scenario is here? Could someone potentially empty the contracts funds? Block withdrawls? I’m assuming this is a “general” BCH problem as well, so it is probably low-risk otherwise I imagine it would have already been addressed.


whether to have miners or elected enclaves monitor the withdrawals

+1 elected enclaves

whether to have one main contract holding all the funds and batch withdrawals or have many separate UTXOs

+1 all-in-one, batched


I couldn’t quite make sense of the Diagram (not really my thing), but I plan to review ALL OF IT again next week and hopefully offer some additional feedback…

Cheers!

1 Like

Recently the idea of a miner voting covenant for sidechain bridging has seen some revival due to interest from script developers on BTC who were interested in its similarities to drivechain.

There’s two clear improvements to the contract that can now be made on Bitcoin Cash:

  1. With the new CashTokens network upgrade the miner voting contract could be upgraded to keep the state about voting in the commitment data field (as described here).

  2. The contract should also use the new P2SH32 standard for smart contracts to avoid any possible collision attacks present in P2SH20.

With re-targetted VM limits there would be a lot of extra room for more complex design choices.

2 Likes

Importantly, the current design is missing incentives for miner participation.

With CashTokens, participating miners can be rewarded part of the sidechain fees. Each miner is issued a NFT receipt when voting. The withdrawal transaction can include a payout to a covenant which pays the fees to the (honest) participating miners.

This way the contract can be upgraded to incentivize active miner participation in the bridging setup.

2 Likes

A while ago @bitjson posted some ideas about implementing a PoS drivechain-like mechanism:

Along these lines: CashTokens enables trustless proof-of-stake sidechains run by sets of cashtoken holders. Withdrawal transactions can be processed on an interval by a vote of token holders + “enforced vote secrecy” https://github.com/bitjson/cashtokens/blob/master/examples.md#sealed-voting

Works just as well for a prediction market as it could work for a trustless mixing service, effectively like http://Tornado.cash, but doesn’t have to be written in a blockchain VM language, you can just write the thing in Rust or whatever (the only mainchain consensus code is some simple covenants + CashTokens)

So more plainly: you can launch Zcash/monero clones as proof-of-stake sidechains, and deposit/withdraw BCH whenever

(and atomic swaps work between the chains)

The gist is that we can do the same withdrawal process as Drivechain: https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki, but instead of having miners vote, the cashtoken holders vote. Vote coordination is discouraged by the sealed voting idea from Truthcoin (page 43) https://bitcoinhivemind.com/papers/truthcoin-whitepaper.pdf

So there are 3 types of assets: BCH, sidechain “shares” (cashtokens), and sidechained-BCH (BCH that is locked in the covenant and currently being used on the sidechain). More info: https://drivechain.info/literature/index.html

An unlimited number of such sidechains can be created, they just need to grow a large enough shareholder base that a single person controls no more than 50% of the token. E.g. even if group of fraudsters owns >50% it’s still secure because one of the groups members can profitably double-cross it. All that matters is determining whether a single rational actor has a majority stake. (Page 25 here https://bitcoinhivemind.com/papers/truthcoin-whitepaper.pdf)

– Jason Dreyzehner on Telegram

I believe a PoW version would be possible if we’d use our Script + CashTokens to implement BIP300-like hashrate escrow, too.

Hashrate would opt in by using a simple one-time vote covenant (OTVC) address that requires bridge DAO input as sibling.

Bridge DAO could then burn and tally these one-time vote covenants and accumulate them in NFT’s commitment. By “unpacking” the TXID of the vote covenant’s input, the DAO can verify the vote is indeed coming from a coinbase TX, and extract the height from the input to verify belongs in the voting window.

2 Likes

@MathieuG @bitcoincashautist any way to bring zSide zcash based sidechain to BCH faster

https://www.truthcoin.info/blog/zside-meltcast/