First atomic bet on Bitcoin Cash using new opcodes
There was a post of reddit yesterday describing an on-chain atomic betting scheme created by Jonald Fyookball and others. Whereas apps like Satoshi Dice require trust in the operator that he will pay out your winnings and not run away with your bet, an atomic bet guarantees that the winner will be paid no matter what. In that sense it's a trustless betting protocol. To my knowledge this is the first time someone has proposed such a scheme on Bitcoin though I suppose it's possible it has come up before and I just missed it. And unless I'm missing something I don't think you can't use this scheme on the BTC chain because it requires opcodes that Bitcoin Cash enabled in its latest hardfork in May. [Edit: looks like there is a clever hack to make this work on BTC. You use the length of the secret values rather than the values themselves. https://curiosity-driven.org/bitcoin-contracts#multilottery] The way the scheme works from a high level is that Alice and Bob are going to generate secret random numbers and commit the hashes of those numbers to the bet's output script. To determine the winner they will both reveal their random numbers and the script will add them together. If the sum is even, Alice wins. Otherwise Bob wins. The challenge is doing this securely. Bitcoin arithmetic operations only accept signed 32 bit integers. This means if Alice and Bob commit to 32 bit random numbers, the second one of them reveals their commitment the other will instantly know what number they picked and can tell if they would win or lose the bet before funding the address. Which obviously would not work. For the purpose of this demo I had Alice and Bob commit to the hash of 256-bit random numbers. The numbers are then converted to signed 32 bit integers using the new OP_SPLIT and OP_BIN2NUM. The re-enabled OP_MOD is also used to determine even or odd. To make the scheme atomic, Alice first funds a special output with a redeem script of: OP_HASH160 <aliceCommitment> OP_EQUALVERIFY <alicePubkey> OP_CHECKSIG Alice and Bob then jointly build a transaction with two inputs ― Alice's special output and a normal output from Bob's wallet [edit: this will need to be a 2of2 to prevent bob from double spending]. The transaction's output contains the following redeem script. OP_IF OP_IF OP_HASH160 <bobLosingCommitment> OP_EQUALVERIFY OP_ELSE "6 blocks" OP_CHECKSEQUENCEVERIFY OP_DROP OP_ENDIF <alicePubkey> OP_CHECKSIG OP_ELSE OP_DUP OP_HASH160 <bobCommitment> OP_EQUALVERIFY OP_OVER OP_HASH160 <aliceCommitment> OP_EQUALVERIFY 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 <bobPubkey> OP_CHECKSIG OP_ENDIF Bob signs the transaction first and sends his signature to Alice. Alice then signs her input and broadcasts the transaction to the blockchain. By signing the transaction Alice is revealing her secret number to Bob who can then use that number to determine if he won or lost the bet. If he won, Bob can immediately claim his winnings. If Alice won, Bob cannot do anything but Alice can claim the funds after a timelock (6 blocks) expires. If Bob wants to be a nice guy he can send the secret key he used for his losingCommitment to Alice so she can claim the funds without waiting the timelock. Though this is not a necessity. The following video shows the first atomic bet being made. The transactions can be viewed on the blockchain here: https://blockdozer.com/address/bitcoincash:pqzyq50kcnwk3yq48l08mnhyrhvme2xx7c3wmcp9sf (and yes it did finally confirm :p)
https://youtu.be/a1Ci_U3sR7w If anyone can find a flaw in the scheme or in the output scripts, or if you can find a way to improve the outputs scripts let us know!
7 of 8 reviewers say it's worth paying for
1 of 8 reviewers say it's not worth paying for