Bitcoin Forum
June 25, 2017, 05:39:28 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Trustless gambling scheme  (Read 1392 times)
syskall
Newbie
*
Offline Offline

Activity: 9


View Profile
December 14, 2014, 08:03:13 AM
 #1

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?
1498369168
Hero Member
*
Offline Offline

Posts: 1498369168

View Profile Personal Message (Offline)

Ignore
1498369168
Reply with quote  #2

1498369168
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
syskall
Newbie
*
Offline Offline

Activity: 9


View Profile
December 15, 2014, 04:19:52 PM
 #2

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

Activity: 189

BitcoinStoreStarter.com


View Profile WWW
December 15, 2014, 04:36:15 PM
 #3

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
Legendary
*
Offline Offline

Activity: 1834



View Profile
December 15, 2014, 04:42:02 PM
 #4

- 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
Newbie
*
Offline Offline

Activity: 9


View Profile
December 15, 2014, 05:01:37 PM
 #5

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
Legendary
*
Offline Offline

Activity: 2198



View Profile
December 15, 2014, 06:16:27 PM
 #6

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.

Just-Dice                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   Play or Invest                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   1% House Edge
seabass1985
Member
**
Offline Offline

Activity: 70

Think For Yourself Question Authority


View Profile WWW
December 20, 2014, 10:31:32 AM
 #7

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.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!