Trustless gambling scheme

[syskall]

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?

[1715490125]

1715490125

[1715490125]

1715490125

[1715490125]

1715490125

[syskall]

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

[NarC]

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

Maybe project development board. Defiantly a cool idea though.

[DannyHamilton]

- snip -
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"
- snip -

While it might be possible to accomplish what you are wanting to do, it won't work the way you describe it.

Scripts don't "pay to" anything.

Scripts are evaluated based on the input (ScriptSig) that is provided when the output from the transaction is spent. The output script encumbers the output value with some condition that must be met by the ScriptSig before that value can be re-assigned elsewhere.  Anyone that can provide the necessary ScriptSig can "spend" that output.

The bitcoin protocol just checks to see what value is remaining on top of the stack after the script is evaluated. A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). If the transaction is valid, then the value is reassigned to the new unspent outputs and the previous outputs that were used as inputs outputs are now "spent".

[syskall]

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

Maybe project development board. Defiantly a cool idea though.

Thanks!

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

Maybe project development board. Defiantly a cool idea though.

- snip -
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"
- snip -

While it might be possible to accomplish what you are wanting to do, it won't work the way you describe it.

Scripts don't "pay to" anything.

Scripts are evaluated based on the input (ScriptSig) that is provided when the output from the transaction is spent. The output script encumbers the output value with some condition that must be met by the ScriptSig before that value can be re-assigned elsewhere.  Anyone that can provide the necessary ScriptSig can "spend" that output.

The bitcoin protocol just checks to see what value is remaining on top of the stack after the script is evaluated. A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). If the transaction is valid, then the value is reassigned to the new unspent outputs and the previous outputs that were used as inputs outputs are now "spent".

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.

[dooglus]

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)"

The scripting system in Bitcoin has been quite severely limited, so I'm not sure it's even possible to express such conditions the way things currently stand.

And even if it is, there's the further barrier that only a very small subset of all possible scripts are considered "standard". Non-standard transactions won't be relayed or mined.

Something like the scheme you propose could well work with an altcoin designed to be used with "smart contracts", but I don't think it's feasible with the current state of Bitcoin itself.

[seabass1985]

If it was able to work with a alt coin which one would it be? An if so hopefully one that had some value on a trading market such as cryptsy or the like.