Last month BCH was upgraded to open up some opcodes. A lot of people are asking, what can you do with these opcodes open? Here, the ChainBet protocol is used as an example to explore BCH’s scripting capabilities.

The ChainBet protocol was written by Jonald, who was also the lead developer of the famous BCH wallet Electron Cash. Just a few days ago, Jonald came up with the ChainBet idea and wrote the draft agreement. Chris, the lead developer of Open Barzzar, then implemented a Demo on Yours.org. That’s right, programmers are so simple and rough, directly stem code to give you!

The purpose of the ChainBet protocol is to allow two people to bet on a chain without the need for a third party and without default. The agreement is divided into two parts:

On-chain communication is colloquially called “gathering.”

To bet on a chain is to bet on a chain.

Yes, ChainBet does both of these things with the BCH blockchain. Let’s talk about “crowd” at another time. Today’s main analysis is how to do without a third party and no one can beat the bill.

First, let’s introduce the two protagonists who will run through the whole article. They are Xiao Ming and Xiao Hong who frequently appear in the sentences in primary school Chinese, but today they have foreign names:

Alice

Bob

Alice and Bob suddenly decided to make a bet for no reason. The rules are simple:

Each of them secretly wrote down a number

Then both people show the numbers at the same time and add them

Even numbers Alice wins, odd numbers Bob wins

Their “gambling tool” is a BCH wallet client, “gambling money” is the BCH in the client. (Ok, the author is no longer in the mood to talk, next to enter the technical section, please brave to read)

Suppose Alice and Bob input BCH into a P2SH address. If Bob wins, Then Bob gets Alice’s number and transfers the coins to his address through the number and Bob’s signature. If Bob loses, Alice can take the coins away after a certain period of time through the Time Lock function.

That sounds good. However, there is a problem: Since Alice knows that she can transfer the coins after a period of time, she can simply not give her numbers to Bob and wait for the coins to be hers. So, it doesn’t work.

So can we make it so that If Alice wants to play the game, she has to show Bob her numbers? You can! Do this:

Each side uses the wallet to generate a random number, and each side exposes the Hash value of its own number, both without exposing the number and without being able to change it. We call public Hash values aliceCommitment and bobCommitment.

Alice first creates a P2SH address, and the coins of this address can be transferred out only after Alice provides her digital and private key signature. We call this address the Alice managed address. Of course, Alice needs to provide a redemption script to Bob, who checks that the script for this address is correct.

Key points: The coins in this address are still controlled by Alice, but if Alice wants to transfer coins from this address, she must provide her own number. That is, once the coins at that address are transferred out, the transfer is broadcast onto the blockchain, and Bob knows Alice’s number.

Alice transfers coins to the Alice towing address.

Bob generates a P2SH address, which we call the bet address, where the script dictates that only the winner can take the coins. Of course, Bob needs to provide a redemption script to Alice, who checks that the script for this address is correct.

Bob generates a transfer, the output is to the bet address, and the input is two:

In step 3, Alice manages the output of the transfer address, which requires Alice’s signature. Bob can construct the transfer, but not sign it.

Bob’s own wallet input and signature.

Bob sends the transfer data constructed in the previous step to Alice and asks Alice to sign.

Alice receives the transfer data and signs after confirming that there is no problem. In order to make the transfer valid, she also needs to provide her own number. It is then broadcast to the network, at which point Both Alice and Bob’s coins are transferred to the gambling address.

Bob receives the broadcast from the previous step, gets Alice’s number from it, plus his own number, and Bob knows two numbers.

If the two numbers add up to an odd number, Then Bob wins, and he can withdraw the coins from the bet address using the two numbers and his signature.

If the two numbers add up to an even number, then Bob loses and he can leave it at that, because after a certain amount of time, Alice can transfer the coins. Of course, if Bob is nice enough, he can give Alice his number right away and have Alice transfer the money right away.

That’s it. Problem solved.

Script code is not deceptive, and I’ll use a script to illustrate how the above process is implemented. The rest of the // script is my explanation

Alice hosted address script:

OP_HASH160 //Alice provides her number and hashes the number to get Hash A OP_EQUALVERIFY // Compare Hash A with the aliceCommitment provided by Alice in step 1. OP_CHECKSIG // The script that checks the signature provided by Alice to ensure that it is indeed Alice who authorised the transfer of the betting address:

OP_IF // If Alice wins OP_IF // If Alice can supply Bob’s number OP_HASH160 OP_EQUALVERIFY // If Alice supply Bob’s number, Hash and compare with bobLosingCommitment //, OP_ELSE // If Alice can’t provide Bob’s numbers, but the bet has been over for a while, it can also be transferred to the coins // equivalent to Bob losing, OP_ENDIF OP_CHECKSIG // Check Alice’s signature, Make sure it’s Alice who transfers the money, OP_ELSE // If Bob wins OP_DUP OP_HASH160 OP_EQUALVERIFY // Make sure Bob can supply his numbers correctly OP_OVER OP_HASH160 OP_EQUALVERIFY // Make sure Bob can provide Alice’s number OP_4 OP_SPLIT OP_DROP OP_BIN2NUM OP_SWAP OP_4 OP_SPLIT OP_DROP OP_BIN2NUM OP_ADD OP_2 OP_MOD OP_0 OP_EQUALVERIFY // Add two integers to make sure they are even: Divide by 2, remainder is 0 // where OP_MOD is OP_CHECKSIG opened after upgrade in May // Check Bob’s signature to make sure it is Bob to transfer, and then the coins can be transferred. The full protocol script is more complex, but if you can understand the above, then understanding the full protocol is not a problem.

BCH is routinely upgraded twice a year, in May and November, each time to make the network more powerful and robust. ChainBet uses OP_SPLIT and OP_MOD, which were just opened in the May update. In other words, the ChainBet protocol can only be implemented on BCH networks, not BTC networks.

BCH can be upgraded quickly because of the efforts of the developers. Currently their income is not much, I would also like to ask everyone to donate BCH to the developers of Bitcoin ABC, one of the main development teams. Their donation address is:

qqeht8vnwag20yv8dvtcrd4ujx09fwxwsqqqw93w88