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

Technical
#14

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

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

#15

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 :smirk:
thanks :pray:

#16

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

“real” shit :rocket:

1 Like
#17

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. :+1:

2 Likes
#20

thanks for the breakdown :wink:

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” :roll_eyes: 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

#21

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.

7 Likes
#22

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.

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