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

Technical
#23

fantastic initiative :clap: :+1:

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

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

and please let us know what comes next… :wink:

1 Like
#24

great to hear on your progress!

1 Like
#25

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

  1. The voting contract
  2. The Sha-gate contract itself
  3. 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 :sweat_smile: Nobody expects solidity devs to work for free either, so I hope you understand why I did not publish it yet :+1:

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

4 Likes
#26

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 :+1: … i certainly appreciate your efforts thus far and I hope that when the time comes, the “community” appreciates it as well

#27

@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 :thinking:

#28

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 :+1:. It seems it would just be a way to enforce operator honesty and does not change anything about the SHA-gate design.

#29

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.

2 Likes
#30

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

2 Likes
#31

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

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!! :muscle: :rocket:

#32

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.

3 Likes
#33

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.

3 Likes
#34

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.

2 Likes
#35

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?

3 Likes
#36

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

3 Likes
#37

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.

1 Like
#38

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 :pray: looking forward to getting this done ASAP!

#39

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

#40

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.

1 Like
#41

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

Smart Bitcoin Exchange (SBX) — A "Smart" Bailout Plan