First atomic bet on Bitcoin Cash using new opcodes | Hacker News Reader

First atomic bet on Bitcoin Cash using new opcodes

yours.org

76 pointsca98am7948 comments

Just so we're clear, we're talking about a virtual coin flip here, right? Anything else would require trust. Even if you tried to use an API that checked the scores of a sporting event.

yes, it's just a coin flip.

Now i'm wondering, what is the ratio of odd to even outputs when calculating this?

are they perfectly even or is one more likely for each flip?

The example is a coin flip but it could be any random based game by using a different algorithm than "number mod 2". You're correct that it can't act on real world data.

Could this be modified to support, say, a chess game?

Chess doesn't have any random element so it wouldn't need this kind of system. You could implement card games and board games that do have randomness like candyland.

You could implement chess with only movement commitments and no atomic fair random number generation.

Some aspects of it would be interesting for non-random games too, e.g. the payout if one player stops submitting moves, verifying who won, ..

More specifically xor 2 initially hidden integers and mod X + 1 gives you a random number from 1 to X.

PS: Adding numbers mod X will provide a fair random number as long as at least one side provides a fair random number to start with. Which is a stronger guarantee if your making a real money wager.

... with a bias if X is not a power of 2.

Depends on the maximum range provided. If both part's pick a X bit number then you need a power of 2. If they pick a number 1 to X then can use X.

You're right of course. Just remember to use addition mod X instead of xor in that case to combine the choices.

That has been possible in pure Bitcoin already: https://curiosity-driven.org/bitcoin-contracts#multilottery

Wouldn't it cost a lot to play though compared to Bitcoin Cash or even Ethereum?

https://bitinfocharts.com/comparison/transactionfees-btc-eth...

All your graph says is that those coins are less valuable in terms of USD.

Transaction costs are specified by the protocol in satoshis, which is the base unit of Bitcoin. How much you can buy for one satoshi only depends on what people want to pay for it. We call this the coin value.

A coin without value is free to transact with. Run your applications on testnet if there are no other considerations.

What are you talking about? That graph is the transaction fee in USD.

Thanks for sharing that. Didn't know someone else had done it before. Nitpicking a little in that with that scheme the losers could attempt a double spend, but for 2014 it's still pretty cool.

Also a very clever hack to get around the scripting limitations by using the length of the secret instead of the actual secret itself.

It's more like a two-party roll of a die with a practically infinite number of faces. If both rolls sum even, Alice wins. Otherwise, Bob wins.

Alice and Bob commit to their rolls by hashing them then making a future spend contingent on revealing the roll that produced the hash.

The trick is how to reveal both rolls without giving an advantage to the one who reveals second. This is the problem the protocol solves - through transaction setup and the newly-activated Script opcodes.

>It's more like a two-party roll of a die with a practically infinite number of faces. If both rolls sum even, Alice wins. Otherwise, Bob wins.

What you are describing is a coin flipping protocol [0].

From the article:

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

There have been coin flipping protocols for Bitcoin since at least 2013-2014 [1]. The main contribution of the above post appears to be that they actually performed the protocol which is neat and quite a bit of work.

[0]: https://en.wikipedia.org/wiki/Commitment_scheme#Coin_flippin...

[1]: Back, Bentov (2014) https://arxiv.org/abs/1402.3698

This paper [0] (from 2013) linked from this article [1] was also executed on chain, see date here [2] and the actual script via API here [3].

[0]: https://eprint.iacr.org/2013/784

[1]: https://curiosity-driven.org/bitcoin-contracts

[2]: https://blockexplorer.com/tx/7ae5760af2105a5ba54a914f188686e...

[3]: https://blockexplorer.com/api/tx/7ae5760af2105a5ba54a914f188...

>an atomic bet guarantees that the winner will be paid no matter what.

How is this possible? is there an Oracle all parties agree to trust?

edit:i see how this can work for some sort of bet where the result is calculated on the blockchain itself but outside of that?

It relies on the parties to take an action (that they are both incentivized to take in order to see if they won). This is similar to atomic swaps - they setup a time boxed window when people must take an action. If one of the parties fails to act in time, they will, in fact, lose their coins.

Can I get a supporter of BTC/BCH explain to me why it makes sense to do this on those blockchains rather than on a blockchain with actual Turing completeness, such as Ethereum?

because in bcash land they can convince the miners to include tx's with 1 satoshi fee, so they can bloat their chain with all kinds of junk like yours.org Good luck doing that in ethereum land.

They also hate volunteers who run BCH nodes, 32MB blocks will wear-out harddrives quickly.

Wrong. BCH will run in Raspberry Pis just fine thanks to UTXO commitments. No need for large hard drives.

https://www.yours.org/content/first-utxo-commitment-on-testn...

Your "wrong" is wrong. You still need large storage devices if you want to trustlessly verify transaction history.

Your "'wrong' is wrong" is wrong. Yo can verify transaction history with an SPV wallet.

A full node won't help you against an eclipse attack. And also not against a sustained 51% attack since miners can mine empty blocks on the minority chain, halting it.

A full node is good for increasing your privacy, disguising what addresses you're watching, but that's all.

Virtue compliance. Same reason you'd use ethereum.

Because of usage & volume... More users of BTC/BCH than ETH.

Is that really true in the case of BCH vs. ETH? I find that hard to believe given the number of ICOs / developers working on the Ethereum blockchain.

Ok - probably right for BCH.. my rush on posting, so my bad.

Not the best indicator but.. https://coinmarketcap.com/currencies/ethereum/ vs https://coinmarketcap.com/currencies/bitcoin-cash/

But for BTC I'd say yes.

BCH has less users than ETH. I think the interest is that transactions in BCH are very low, and there are talks about enabling some 0-fee transactions:

https://coingeek.com/bitcoin-com-viabtc-join-miners-choice-i...

An important difference between BCH and ETH is that ETH has a lot of opcodes, but BCH is slowly enabling some of the opcodes that were created by Satoshi but later disabled.

There are absolutely not more users of Bcash than Ethereum.

There have been some other answers, but I’ll add first, people may just want to bet BCH - if it’s possible to do, even with a limited instruction set, why not figure it out? Second, turing completeness is not a panacea, and as we’ve seen now several times, the expressiveness of Eth’s VM actually opens it up to more bugs.

This is similar to https://github.com/Jfaler/Bitcoin-Casino

The interesting thing about this is that all the logic happens onchain. This is why OP mentions that this is the first truly decentralized bet of this kind, because everything is happening on top of the Bcash decentralized protocol.

TL;DR: A very simple smart contract running on the Bcash network.

bcash is trash.

https://www.youtube.com/watch?v=oCOjCEth6xI

I didn't realize this was possible on Bitcoin Cash. Here's a similar idea coded for Ethereum:

https://www.blunderingcode.com/gamble-channels-fast-verifiab...

This uses a chain of hashes so you can make a single commitment for lots of bets, and an off-chain payment channel.

The OP_CODES were 'disabled' by core because they were considered poorly tested and a consensus logic risk. https://github.com/bitcoin/bitcoin/pull/2610

Of course, the highly skilled 'Bitcoin ABC' aka bcash developers obviously tested these well, with no risk to consensus logic or users funds...

Can we please avoid having HN becoming yet another battleground for Core vs Cash sock puppets to dump their trollish posts?

Tell people to stop upvoting these threads, don't tell commenters to stop explaining issues and providing sources.

Eh, I think this belongs here. Heavy moderation is probably good to prevent the BTC/BCH flame wars you'll see on other forums, but the technical differences being introduced between the chains (such as OP_CODES here) are actually very interesting I think.

I thought asking people to upvote or downvote content on HN was against the rules?

>Please don't impute astroturfing or shillage. That degrades discussion and is usually mistaken. If you're worried about it, email us and we'll look at the data.

>Please don't complain that a submission is inappropriate. If a story is spam or off-topic, flag it. Don't feed egregious comments by replying; flag them instead. If you flag something, please don't also comment that you did.

>Please don't comment about the voting on comments. It never does any good, and it makes boring reading.

Why do people think this is trolling?

Ive been a long time bitcoin owner and I know having 15 different forks is bad for the currency.

Unless the definition of trolling has changed, I'm very serious when I hate on the fraud being committed with 'the real true bitcoin'.

When BCH started encouraging 0conf, I started thinking BCH leaders were actually crypto terrorists.

Because as I see it you're saying enabling OP_CODES is a bad thing. You may be right, but you didn't use a very good argument.

You used an 'Appeal to authority' to show OP_CODES are bad then you implied no testing was done by the BCH guys without providing any evidence of such.

So that's probably why you got downvoted.

Because of the use of "bcash" and "bcore" which are both considered derogatory terms for their coin on either side.

"bcash" is an indicator, but less strong of one than a green account with a randomly generated user name posting about it.

Reply on news.ycombinator.com