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

nyusternie · March 3, 2022, 7:24pm

We’re only about 2 MONTHS out from the next Bitcoin Cash upgrade

But the last update to the SHA-Gate repo was 7 MONTHS ago

TL;DR

WTF is going on?? I don’t understand what the plan is to deal with the very serious “treasury” problem that currently exists with SmartBCH. If SHA-Gate doesn’t go live soon after the upgrade, what is the incentive to BUIDL on Bitcoin’s EVM sidechain?

No FUD here, I swear; but I’ve been patiently waiting for this issue to be resolved, but on the surface it looks like it’s being completely ignored. I have NO intention of building on a chain financially controlled by a single “for-profit” entity. BSV v2 makes absolutely NO fck’n sense…
This is my very strong personal opinion.
-Shomari

A DuckDuckGo search of “SHA-Gate” retrieves these relevant results:

SHA-Gate: Why Wait?

This video features the Legendary Wang Kui

He briefly talks about why we need to wait until the May 15th upgrade to implement a “proper” SHA-Gate. I was most intrigued by the limits he talks about regarding the firmware on the very popular Bitmain miners. Will this still be a problem after the upgrade? I’m assuming so

Okay, so what can we do?

Let’s start testing the capabilities of SHA-Gate while utilizing:

the new 64-bit integers
the expanded bytes count
and expanded operation count

ASAP! LIke TODAY!
👷‍♂

IMHO, the alternative is that BCH misses yet another opportunity to attract the stakeholders, BUIDLers and users that are no doubt necessary to bring “VALUE” back to the Bitcoin network.

When I joined BCH back in 2020, it was with the excitement that SLP was mature enough to finally build the services that I could only dream about back in the days of Colored Coins [1] [2].

But now with the future of SLP in questions, it really only leaves SmartBCH as a “viable/practical” solution for builders like myself.

I completely understand & accept that Telegram and Discord are the home for crypto discussions; but not everyone uses those private “walled garden” networks or find their KYC login process to be acceptable

Respectfully, I’m asking for ANYONE with knowledge of this situation to post that information here, in a “public/indexable” forum where others can be informed about the current SHA-Gate status.

By JUNE '22, I’d love too busy for “Summer”, because I’m BUIDLing the most incredible services powered-by SmartBCH. And I KNOW there are countless others that would share that sentiment. So let’s get this done!

Thanks for reading.
And it’s my hope this will be well received as “constructive”

Cheers!
Shomari

tom · March 3, 2022, 9:06pm

Hi there.

Are you aware that there is a protocol upgrade scheduled for May 15th on the BCH chain?

The ideas behind the SHA-gate will require that upgrade to have been activated. The code is ready, just not possible to deploy.

Personally I don’t know the plans either, but the point I made above is reason enough for a simple wait.

It is relevant to know that the SHA-gate as written today (meant for after the next upgrade) is absolutely not providing you with a permissionless system.

There exists no such thing as a permissionless two way peg which makes this secure or decentralized. Their homepage is selling you that but they can not deliver it. At least for the next 18 months or so should some protocol upgrade make this available.

Invest your time into s-BCH with care. Other people are holding the private key to your BCH coins and they could choose to leave with it or maybe someone steals the priv-key and you just lose access to your coin. Not your keys, not your coins.

nyusternie · March 4, 2022, 12:52am

Hey Tom!

Thank you for commenting on this issue.

Actually, the most recent SHA-Gate contract appears to be ready to deploy today. But based on the repo, no one has worked on this in the last 7 months. I’m looking for someone who can point me to the NEW contract code, that will be deployed AFTER the upgrade.

So for some context…

@MathieuG recently developed a new Flipstarter proposal (P2SH assurance contract), based on the upgraded capabilities coming in May. So, I’m suggesting that we do the same for SHA-Gate. Let’s start testing TODAY for May…

TBH, this stuff is over my head. I would certainly be attempting to do it myself, if I better understood the “upgraded” environment’s CashScript limits; and how to test them.

I’m very optomistic for the NEW SHA-Gate contract, but there are 2 things the bother shit outta me with the current contract:

github.com

smartbch/shagate/blob/main/cc_covenant_v0.cash

pragma cashscript ^0.6.0;

contract ccCovenant(pubkey operKey0, pubkey operKey1, pubkey operKey2, pubkey receiver, bytes4 noBytes, bytes4 yesBytes) {
   // initialize an unlocking proposal
   function initUnlock(sig s, pubkey pk, bytes33 newReceiver) {
      require(checkSig(s, pk));
      require(pk == operKey0 || pk == operKey1 || pk == operKey2);
      // we want to ensure this utxo has been voted to stay or nobody voted in last 300 blocks
      // The following if-clause is actually requiring int(noBytes) > 30 || tx.age >= 300
      if (int(noBytes) <= 30) {
         require(tx.age >= 300);
      }

      // update receiver and clear vote count
      bytes newContract = 0x0400000000040000000021 + newReceiver + tx.bytecode.split(44)[1];// 5+5+34
      bytes8 amount = bytes8(int(bytes(tx.value)) - 1000); // 1000 is hardcoded fee
      bytes32 out = new OutputP2SH(amount, hash160(newContract));
      require(hash256(out) == tx.hashOutputs);
   }

This file has been truncated. show original

Only 3 Validators / Operators

Line 1
contract cc_covenant(pubkey operKey0, pubkey operKey1, pubkey operKey2, pubkey receiver, bytes4 noBytes, bytes4 yesBytes) {

I won’t say much about this, because I understand this will no longer be a problem after the upgrade, but yeah, THREE VALIDATORS? Makes BSC look decentralized as fuck!

24+ Hours to Unlock Your BCH

Line 50
require(tx.age >= 150); // nobody voted in last 150 blocks

This requires over 24 hours to unlock your BCH from the bridge. That’s not practical. This will just push people back to using centralized services that are basically instant. And these CEXs may just push this limit right back onto the user, I dunno…

And fwiw (I may NOT be understanding this correctly), this constraint is based on the “last vote”. So it will reset, each time a new validator votes. So ~24 hours is the absolute MINIMUM unlock time.

Lastly, does anyone know who wrote the original CashScript code for SHA-Gate? The developer is https://github.com/zxh0. But this is certainly NOT Wang Kui, nor is it @rosco, whom I would consider the MOST qualified individuals to do so.

Jonas · March 4, 2022, 11:41am

Two weeks ago the SmartBCH team released the following article:

With this paragraph

These are not really validators. An operator (anyone of the three) can initiate a withdrawal vote and that’s it. They can misbehave in two ways: (1) colluding and not initiate a certain withdrawal meaning that a certain sBCH user (or all of them!) can not get their mainchain BCH back. And (2) not spam with false withdrawal requests.
Who the validators are, how they are elected and the number of them is to me an open question.

Related to number (2) above I actually think that 24 hours is a really short time period. Consider if there is 1 million sBCH on the side chain and one operator decides to rug pull everything. He/she would create X withdrawal requests for the 1 million sBCH each block where X is the number or votes a miner is able to do in the coinbase transaction + 1. After a while there will be one withdrawal request without any votes during 149 and the operator can just mine one block with one vote and walk away with 1 million BCH. The cost of this attack is the transaction fees of all requests and the cost of mining 1 block. Until the “Bitmain firmware issue” described by Kui the number X is apparently very small and consensus wise I think coinbase transaction has an upper limit of 1 Mb which sets an upper limit on X.

(Edit3: Actually, when inspecting the current code it turns out that it isn’t possible to spam with the same withdrawal request. Initiating a withdrawal is moving the funds to a new UTXO and it’s clearly not possible to double-spend. There is however no consolidation of the deposited funds so it could be possible to overload the miners by spamming with different withdrawals. Another thing I noted is that the operator does not have to mine a block to get one ‘yes’ vote, it’s sufficient to not get any ‘no’ votes during 150 blocks)

Looking at BIP-300 (Drivechains) the withdrawal time is 6 months (!). It is fully expected by that author (Paul Sztorc) that any user that would take his funds to the mainchain is using some atomic-swap bridge.

Edit:

According to the design document (Decentralized Cross-Chain Bridge - smartbch) the voting stops after 30 ‘yes’ votes (minimum 5 hours):

Edit2:
Considering the “30 vote” threshold the attack described above could be changed into:
One operator initiate a withdrawal for the entire amount and conducts a 51% attack for mining 30 blocks with yes votes. Once the amount of funds on sBCH exceeds the cost of mining 30 blocks the operator is incentivized to do so. I would think long and hard about these parameters before putting any value on the side chain.

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.