Miner Voting Covenant for Sidechain bridging

Technical
#1

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.

6 Likes
Will SHA-Gate be ready for the May 15th upgrade?
Smart Bitcoin Exchange (SBX) — A "Smart" Bailout Plan
#2

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
#3

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
#4

@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
#5

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

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

3 Likes
#6

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
#7

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