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

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

nyusternie · April 27, 2022, 4:50pm

@MathieuG are you aware of Wang Kui’s plans to use enclaves in the next iteration of the SHA-Gate?

just wondering how this may affect the work that you’re doing now

MathieuG · May 9, 2022, 5:42am

To have 8 operators for SHA-gate is not the same as just having a 7 or 9 participant multisig. Operators can only initiate withdrawal proposals, miners still need to collectively give their stamp of approval.

No I had not seen this yet, thanks for sharing . It seems it would just be a way to enforce operator honesty and does not change anything about the SHA-gate design.

MathieuG · May 9, 2022, 5:49am

This thread has become quite long so I made a separate document with my ideas for the upgraded SHA-gate.

It includes some more comments about the problems of the OP_return idea, the 20byte P2SH vulnerability and some discussion on LP markups as compared with the previous design.

helldealer · May 17, 2022, 9:35am

Hi, I am defibear from smartbch dev team, thank you for your attention and contribution to SHA-gate, our team is working hard to advance SHA-gate, we will seriously consider your suggestion @MathieuG

nyusternie · May 19, 2022, 5:11am

@helldealer thanks for making the time to chime in on this discussion and for recognizing the tremendous contribution being presented by @MathieuG

quick inquiry:
is there currently any “active” code development for SHA-Gate, ie any commits being made to a repo, by anyone from the core team?

if so, where?

if not, when?

again, very much appreciate everything you and the rest of the team are doing to bring smartbch to reality … please keep up the amazing work!!

MathieuG · June 15, 2022, 4:05pm

A week ago the SBCH team published this article “The Plan for SHA-Gate V2”. It’s a reinvention of the bridging mechanism under the same name. It does away with miner voting and it relies on large part on the enclave concept mentioned higher up in this thread. If the enclaves publish an “attestation report” of the creation of the keypair before being elected as operator this would indeed imply all operators run predetermined software and the multisig will follow predefined rules.
However, some questions arise:

What if less than m enclaves are still up and running in for m-of-n multisig? The funds would be stuck and selecting new operators wouldn’t change a thing.
What if the enclaves think they are listening to the SBCH blockchain but instead they are listening to a fork - a modified version where different (fake) withdrawals happen?
What use are the monitors in preventing bugs when they are also enclaves checking the same withdrawals with nearly identical code? They seem redundant.

These are meant to open discussion - not close it.

I will also offer a counter arguments to the last step in the reasoning that brought them to the new solution:

Factor 7 : If we use one unique UTXO to hold all the cross-chain BCH, it will be very hard to locate.

It would be very easy for a server to track the latest state of the sidechain covenant, if the UTXO is spent, the new UTXO is always the first output of the transaction. The UTXO would change on every interaction but the address of the p2sh contract would only change whenever the votecount changes (so every few blocks). If a client queries the latest state from the server and is skeptical it can check check that the arguments of the latest state with the rest of the bytecode indeed hash to the provided p2sh address. If for some reason the server provides an old state - no harm is done any transaction attempting to interact with a spent output will be rejected.

I’m continuing the discussion with Kui Wang about this.

I also pointed out it would not be hard for 3rd party wallets to also use the BCH → SBCH bridging mechanism if they can query the latest state from a server. They would just need to add a second input to the covenant UTXO and send the increased amount back to the same p2sh address (optionally with a change output). The contract state does not change so no need for the wallet to do complicated smart contract stuff.

What I consider the most important criticism is number 2:

Factor 2 : Miners are not as willing to join smartBCH’s ecosystem as BCH holders.

This is a reason to think well about incentivizing participation, sufficiently long withdrawals etc. but not a reason to give up right away.

tom · June 15, 2022, 9:55pm

i’ll add a question about my greatest fear.

In BCH proper censorship is handled by decentralization. A transaction can be censored by a single miner by them not including it in a block. But since different miners are all able to include whatever transaction they want, censhorship is solved by multiple parties all having the same right to include a transaction.

In Smart-BCH I’m worried about censhorship of people cashing out. A user that wants to convert smart-BCH to BCH.
As this is using multi-sig there is no censhorship protection in the same sense that protects the user from the operators. Only a small number of organizations have to be pressured in order for a user to lose their funds.

Can someone tell me if I misunderstand, or is this indeed an issue.

bitcoincashautist · June 16, 2022, 4:46am

It is a valid concern, with PoW anyone can join without asking permission from existing players, with a system of multisig - they can’t unless other keyholders let them.

MathieuG · June 16, 2022, 7:06am

The enclave setup makes this somewhat harder as valid withdrawals are always signed and broadcasted but of course it is possible to only broadcast it to yourself and not relay the information if it is a withdrawal transaction you want to censor.

Kui Wang the lead dev answered

This is a good question. We need to ensure the operators’ enclaves are not fooled by fake forks. We are planning to run several smartbchd’s full-node clients in enclaves. The operators’ enclaves must query several full node enclaves to avoid fake forks.

It’s enclaves all the way down, enclaves checking the enclaves listening to enclaves.
Who decides the list of enclave full nodes? How can you know they are connected to the real network? Isn’t this just a trusted setup with extra steps?

MathieuG · June 16, 2022, 7:08am

I made a new topic for my miner voting sidechain covenant.

I have now open-sourced the smart contract code an you can find it in the same repo: https://github.com/mr-zwets/upgraded-SHA-gate/blob/main/sha-gate-improved.cash

tom · June 16, 2022, 8:44am

When you say “always”, how is that enforced?

Imagine if someone black-listed an address and some enclaves are in the USA and are forced by law to obey. Is it still certainty that a withdrawal is signed and broadcasted?

The enclaves model seems to be much more permissioned than proof of work is.

nyusternie · June 30, 2022, 9:00am

yeah, i definitely feel like this is a major weakness in the design of SHA-Gate. I’d like to see some form of fail-safe put in place for if the m-of-n requirement cannot be met. there would probably need to be some secondary “trust” system in place.

agreed!

would this action cause a change in contract address? if not, why not? if yes, then wouldn’t this cause problems for tracking the “latest” instance of the contract?

thanks so much for all your efforts looking forward to getting this done ASAP!

nyusternie · June 30, 2022, 9:09am

i don’t believe operators can censor ANY individual BCH account.

there’s currently no mechanism in place where redeeming requires any proof of ID. so ANY (sufficiently funded) account would be able to redeem from the bridge.

NOTE: This is in contrast to the EVM bridges, which typically will ONLY send to the same address 0x... when transferring assets from one network to another. This makes it trivial for bridge operators to blacklist addresses (even w/out it being coded into the bridge contract).

bitcoincashautist · June 30, 2022, 12:05pm

Would it be possible that PoS operators are somehow mirrored on the BCH chain? Instead of static mainchain multisig keys, have the covenant allow updating them somehow when sBCH validators are updated.

nyusternie · July 1, 2022, 3:59am

afaik, there’s no trustless method of communicating between the 2 chains.

i’m working on a dPOS proposal that would allow “n” to be >100