Thanks!


Yes I know that, it was just pseudocode. "pay to X's public key" was a shortcut for the standard "OP_DUP OP_HASH160 <X's pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG" script. I understand that this kind of language should not be used with noobs because it is indeed misleading but I think someone familiar enough with Bitcoin will understand what I meant. Other than that, do you see any critical problems? Maybe I should make the pseudocode a little more concrete? I thought it was quite clear and didn't want spend too much time writing the actual script in case there was a logical flaw in the scheme.

No reply? That's a bit disappointing. Is there another sub-forum that would be better suited for this post?

Hi all,

First let me preface this with a disclaimer: I haven't really followed this forum recently, so sorry if this idea was proposed before. Also, this is heavily inspired by the atomic cross chain trading scheme.

I think I came up with a block chain based scheme that would allow completely trustless/decentralized gambling between 2 participants. That being said, I'm not familiar enough with Bitcoin scripts to know if the idea is feasible and would like some feedback from the community.

I will describe it with an example:

A wants to bet 1 BTC at 25% (winning payout is 3 BTC). A finds a person B who will act as the house.
Effectively, this is another player who wants to bet 3 BTC at 75% (winning payout of 1 BTC). An house edge could also be agreed upon.

A picks a random number x
B picks a random number y
A gives H(x) to B
B gives H(y) to A
 
B creates TX1: "Pay 4 BTC to (<A's public key> if x and y known for H(x) and H(y) AND H(x+y) < MAX_HASH * 0.25) OR (signed by A and B)"

B creates TX2: "Pay 4 BTC from TX1 to <B's public key>, locked 6 hours in the future, signed by B"
B signs TX2 and sends to A.
A signs TX2 and sends to B.

B submits TX1 to the network.
A creates TX3: "Pay 1 BTC to <B's public key>, if y known for H(y)"
A submits TX3 to the network.
B spends TX3, revealing y.

A now knows both x and y and can spend TX1 if H(x+y) < MAX_HASH * 0.25.
If A won, he sent 1 BTC and received 4 BTC. A effectively wins 3 BTC. B received 1 BTC and sent 4 BTC. B effectively lost 3 BTC.
If A lost, he sent 1 BTC and effectively lost 1 BTC. B wins 1 BTC and is able to regain control of his 4 BTC in 6 hours.

The protocol could be improved by using a locked transaction that spend TX3 to A in case B doesn't go through with the protocol. It could also be improved to allow B to regain control of TX1 before 6 hours assuming A is a nice guy (he could reveal X for example knowing that he can't win anyways).

The biggest limitation I see is having to wait for block confirmations (assuming the scheme makes sense).

Any thoughts?