Will SHA-Gate be ready for the May 15th upgrade?

Jonas · March 4, 2022, 9:56am

Some back-of-the-envelope calculations for the 51% attack if SHA-Gate was live today:

Current BCH hashrate < 1.5 EH/s
(fork.lol)

Current sBCH supply: > 100’000 (> $30’000’000)
(Grafana)

Price for renting SHA256 hash:
(Mining Rig Rentals | Sha256 Mining Rigs)
50 PH/s for 3 hours: < 0.05 BTC = < $2500
1.5 EH/s for 10 hours: 30*(2500/3*10) = < $250’000

Spending < $250’000 and gaining > $30’000’000

This also disregards the block rewards the attacker get when mining which actually lowers the cost…

nyusternie · March 4, 2022, 10:59pm

oh wow! @Jonas you’ve been super informative!

apparently, i wasn’t subscribed to their posts and I missed this.

ahhh, well that seems quite problamatic. with just 3 “operators”, if 2 go down (eg. DDoS), then the remaining has free reign?? possibly worse would be a state actor “forcing” the hand of one or more operators.

if i understand you correctly, this is exactly what I’ve been thinking about myself. why are we working on a “trustless” type of atomic-swap bridge network for BCH <> sBCH? I would love to start a new topic on this. I’ve worked on atomic swaps in the past.

that’s right! forgot about that

makes sense

hmmm, lots to think about here

very much appreciate all the info
thanks again!

nyusternie · March 4, 2022, 11:03pm

forgot to touch on this.

i definitely question why this isn’t a priority for Amber testing if the SmartBCH team has already implemented/deployed the necessary hard fork?

“few” months sounds better than 18 I suppose

ShadowOfHarbringer · April 10, 2022, 8:07pm

I somehow highly doubt the bridge will be ready.

Change my mind

MathieuG · April 14, 2022, 12:57pm

Kui Wang wrote in the SBCH telegram chat:

Yes. Sha-gate will launch sometime AFTER May. Hopefully before September.

The further discussion on the SHA gate in this thread is interesting. I just went over the code and what stands out to me most is that the “finishUnlock” function only enables an all or nothing withdrawal by one public key.

The example code is good for showcasing the setup but would not actually work because the general case is that people withdraw a different amount of BCH than they initially bridged to the sidechain (otherwise what use is the sidechain?).

The whole modular setup does not make much sense to me, instead of having countless SHA-gate UTXOs there should be one big covenant handling all the bridging. This means there should also be a contract function that just allows people to increase the balance of the SHA-gate (currently this is not possible).

I upgraded the cc_covenant contract code to use native introspection to compare the contract size. The opcode count decreased from 194 to 141 and the bytesize from 359 to 277.

With the newly available 60 opcodes, they should upgrade the contract to not vote on a receiver public key but instead on a P2SH. The P2SH should be a covenant that can only pay out certain addresses a certain amount. Each voting round then batches multiple payouts. They should also add the option to add funds to the contract as I mentioned before.

This is just my initial impression, it should not be too hard to add this if it fits within the opcode limit. I will reach out to them to see if I can help out with the SHA-gate, indeed as pointed this can all already be demo-ed on the mayupgrade testnet. If the SHA-gate script has to be optimized by hand to enable additional functionality this should not be too big of a deal either, given the size and importance of Smart BCH.

MathieuG · April 15, 2022, 9:31am

Doing away with the one cross chain covenant for each time a user bridges approach also solves the Bitmain firmware issue talked about by Kui Wang in the "BCH Network Discussions"video. Miners don’t even need to include the cross chain covenant outpoint in the OP_RETURN, it’s redundant.

The limits why you would have multiple cross chain covenants still is to play around the 2^80 collision attack of P2SH addresses/contracts and when running into the limits of the batched withdrawals.

The documentation of the cross chain covenant also says

To vote for a covenant, a miner must use a coinbase transaction whose height is greater than the cc_covenant’s height

But this is not actually implemented in the smart contract code.

Wecx · April 16, 2022, 12:06am

Oh good, nice to see miners benefit always.

nyusternie · April 16, 2022, 1:18am

After smartBCH’s XHedge hard-fork, we’ll focus on developing the SHA-gate feature, which enables a secure and decentralized bridge between BCH mainchain and smartBCH sidechain.

this was posted earlier this week

this far, the SmartBCH has been very consistent on delivering as promised, so I’m giving them the benefit of the doubt here

but time will tell…

ShadowOfHarbringer · April 16, 2022, 1:21am

Looks promising.

I am holding my thumbs they do deliver.

Not delivering on this promise would be a serious disaster right now, when so many people are invested in SmartBCH.

nyusternie · April 16, 2022, 1:26am

I will reach out to them to see if I can help out with the SHA-gate

PLEASE!!! and do not hesitate to reach out for additional help & support…

for the love of God, we shouldn’t be so laissez a faire about the importance of rectifying this “serious” treasury issue…

afterwards, i swear it’s ALL downhill

nyusternie · April 16, 2022, 1:29am

Doing away with the one cross chain covenant for each time a user bridges approach also solves the Bitmain firmware issue talked about by Kui Wang in the "BCH Network Discussions"video.

would you mind elaborating?
in layman’s
thanks

nyusternie · April 16, 2022, 1:33am

BCH is hands down the market leader in merchant adoption…

add a cheap and efficient EVM protocol to replace the now legacy SLP, and i can finally see a foundation on which to fck’n BUIDL shit!

“real” shit

MathieuG · April 16, 2022, 6:35am

Their current architecture only suffers from a “Bitmain firmware issue” because they intend to create a separate sha-gate covenant for each time a user bridges. This means miners would need many coinbase outputs to vote on a lot of different withdrawal proposals. (They also intended to have miners include an OP_return for each vote, which I point out is redundant)

Instead the architecture should be to have one big (or a few at most) sha-gate covenants managing a lot of transfers to and withdrawals from the sidechain, so miners only need one coinbase output (or a few at most) to participate in all the voting which solves the need for many coinbase outputs.

nyusternie · April 17, 2022, 8:39am

thanks for the breakdown

because they intend to create a separate sha-gate covenant for each time a user bridges.

I’m not an expert who can speak on this confidently, but i see MANY inefficiencies in the current design.

my concern is that work on sha-gate has been delayed intentionally because no one has any “good” idea on how to solve these issues

I’d love to see a “plan b”, just in case the sha-gate is eventually deemed impractical for “real-world” use.

the solution used by basically every other chain is a “trusted” multi-sig to manage their treasuries

it’s completely horrible, but seems to be the accepted industry standard at the moment, even by the largest players

MathieuG · April 18, 2022, 7:03am

I’ve worked on the SHA-gate contract for the past couple days now and this is what I was able to achieve:

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

The first three are pretty much essential for the thing to work. My implementation of the SHA-gate 194 opcodes and 400 bytes, so cleanly within the current limits.
So I’m confident a fully functioning and secure SHA-gate can be implemented, writing the smart contract is a very important but not the most time consuming part. That will be to actually invoke and test the smart contract functions on testnet & mainnet and then write the software for miners to actually run to participate with their coinbase outputs in this voting process.

Pretty amazing what we can do within the current limits now.

ShadowOfHarbringer · April 18, 2022, 8:19am

This is amazing, thank you for clearing this up.

Can’t way for May and June to see SmartBCH bridge really happening.

BCH could finally break out of the shackles and start walking the path towards being world’s reserve currency.

nyusternie · April 18, 2022, 11:06pm

fantastic initiative

is your work ready for peer review? do you have a repo or would you consider a pull request to the original repo?

github.com

smartbch/docs/blob/main/sha-gate.md

# Decentralized Cross-Chain Bridge

## SHA-Gate: a sidechain bridge for Bitcoin Cash

This document describes a mechanism named "SHA-Gate" which transfers BCH between the Bitcoin Cash main chain and a sidechain.  It is decentralized, non-custodian, miner-supervised and fully implemented with Bitcoin Cash's script bytecode. It does not require any consensus change of Bitcoin Cash, nor rely on operators' honesty for asset security.

 ### Light-Clients are not safe enough for crossing chain

Many people believe that cross chain bridge is good enough to be as secure as a light client of the host chain. This is a wrong belief.

The basic idea of light clients is to trust the miners of PoW chain (or the validators of PoS chain), instead of verifying the transactions yourself. This means the miners and validators can be much more harmful and dangerous on the guest chain than on the host chain.

The worst thing that miners can do on Bitcoin Cash is to reorg the chain for double-spend. And the worst thing of the validators on smartBCH is double-signing. The miners and validators cannot make the other full-node clients accept fake transactions, because they verify all transactions. But they can make light clients accept fake transactions.

If smartBCH use an embedded BCH light client to verify the cross-chain transfers from main chain, a malicious attacker would like to rent hash power to mine some BCH blocks containing fake cross-chain transactions and submit this fork onto smartBCH, as long as these fake transactions can gain them more profit than the rent fee of hash power. These BCH blocks mined by the attacker are only submitted to smartBCH, because their fake transactions are invalid on the main chain.

If we use a covenant on BCH to implement smartBCH's light client for cross-chain transfers to the main chain, a malicious attacker would like to bribe the validators to sign fake smartBCH cross-chain transactions to unlock coins on BCH main chain, as long as it can gain more than the slash punishment for double-signing.

So the SHA-Gate's design is not based on light clients, instead, it depends on power balance of several parties.

This file has been truncated. show original

would love to see SHA-Gate updated from its last commit back in aug

and please let us know what comes next…

Steban · April 19, 2022, 9:54pm

great to hear on your progress!

MathieuG · April 22, 2022, 7:44am

I was able to strip down the contract to 182 opcodes and 373 bytes which means it could fit up to 8 operators within the limits (instead of 5).

In the demo and current version miners vote directly with their coinbase output which requires participating miners to be able interact with the complex smart contract and to have a private key online to sign the P2PKH output.

I’m experimenting with a second design where miners would create a vote covenant output instead which does not require the miner to have keys available or interact with a smart contract - just need to create one.

So this 2nd version of Sha-gate consists of 3 separate contracts

The voting contract
The Sha-gate contract itself
The payout contract

Not sure if this is superior yet… This requires another layer of contracts and would make the voting happen before finding a block by choosing the yes/no P2SH vote covenant and not afterwards like in the current design.

First of all thank you for the supportive comments in this thread!

I have not made my code public yet - as I like to join the SBCH team or do this work as a paid contractor. I have pretty much done a free security audit of their demo contract above Nobody expects solidity devs to work for free either, so I hope you understand why I did not publish it yet

edit: sorry to change the numbers on the contractsize had overlooked something

nyusternie · April 24, 2022, 12:37pm

i commonly see that 7 or 9 is the “multi-sig” norm throughout the ecosystem … so this seems very reasonable by my standards.

very nice! options are always good … though I’m not sure how you can create a covenant without some use of a private key. how is the covenant created & validated? public key?

this all sounds reasonable, but could you outline the pros and cons of each approach?

absolutely! very happy to help you advance yourself to a “formal” position in any way I can … i certainly appreciate your efforts thus far and I hope that when the time comes, the “community” appreciates it as well