Topic: New contract type: Betting on sporting events using passive third-party (Read 808 times)

Somewhat related,

https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state

In this case the bar is acting as the oracle, in effect. But an application on a web site is probably more reliable and more general.

why not just use bitbet?
If its a short term bet not too likely anyone else will jump in and change the weights.

I don't know if this has been proposed, but it's an app I would love to create if I wasn't so terrified of going near gambling apps.  I'll let someone else steal the idea.  Note: this could be Intrade-style betting, too.  It doesn't have to be sports betting.

CONOPS (CONcept of OPerationS):

Two guys at a sports bar are watching a featured event and argue about which team is going to win.  They want to make a bet, say 3:1 on the outcome of the match.  They've never met each other, and in fact they're quite drunk so there's no guarantee that they'll ever see each other again.  But they don't need to see each again, as long as the winner comes back to the bar the next day to collect the "payment code." (there's a variant that doesn't even require that;  see "Extra Credit")

The house is "passive" here because they do not have any active role in any individual bet.  They just post a QR code on the wall for each event going on.  The QR code has the following information (concatenated together):

["Team A" || Hash(SecretA) ||  "Team B" || Hash(SecretB)]

The guys each scan the code with their phones, then touch their phones together (or do the QR exchange), and the app pops up and says:  "Are you betting on Team A or Team B?  What odds?  How much?"   If you both put complimentary information into the phone (one picks A and puts in X BTC, and the other puts in B and 3X BTC), then it accepts it and the bet is made.  Both users' phone wallets are deducted coins (because they were sent to this funky script), and they can now wander off and never see each other again.  

The next day, or later that night, the winner goes back to the bar and the house will have posted a new QR code based on the output of the event.  It's either SecretA or SecretB (unhashed), depending on who won.   (There could be a third option for "no-contest-everyone-gets-their-money-back" scenario, but this will dramatically increase complexity).  The guy scans the bar code with his phone, and his phone instantly recognizes it and completes the transaction to send the money to himself.  Done.

I have a fun modification that could even make redemption automatic without going back to the bar (as long as his phone is on), but that's an "add-on" to this idea at the end.

How it works:

Once they have exchanged public keys and scanned the QR code, they construct the following transaction:
  
    Inputs:
       Bettor A:  X BTC
       Bettor B:  3X BTC
    Outputs:
       Non Std-Script:    [HashOfSecretA and PubKeyA] OR [HashOfSecretB and PubKeyB]

Redeem by signing and supplying the correct preimage of your hash.



Drawbacks:

--Non-standard.  App probably needs to have direct connection to a miner that is willing to support these transaction types, and bets need to be made well in advance of the event to ensure time to get into the blockchain.
--Patron has to go back to the bar after the event.  Not ideal if he doesn't remember he made the bet (he was drunk), or he's traveling and in town only for the night.  Both of these could be resolved by putting the data on the net.  Or my extra credit, below.
--House gets nothing.  They would have to do this purely as a perk for customers without any compensation -- besides the fact that people love betting, and might go there for the perk.  However, if it were popular, you only need one third-party, anywhere willing to do it for free, and all apps/devices could connect to it for major events.  However, if the house could still do it for local events.

---

Extra Credit:

How could we automate this so that neither party actually has to go back to the bar to get the redeem code?   The bar could actually "signal" through the blockchain, but not in the normal way that everyone hates!  The reason I used OP_HASH160 above, is because "SecretA" and "SecretB" could actually be unspent TxOuts (UTXOs) owned by the house.  It doesn't matter how big the UTXOs are, or where they ultimately go.  All that matters is they haven't been spent and these are the addresses have never been used:  i.e. the public keys are not public yet!  

Before the event, both UTXOs are in the house's wallet, but "locked":  artifically prevented from being spent.  When the event is over, the house unlocks the correct UTXO and it will be spent on their next transaction that would've been executed by the house, anyway.  The patron's phones used the HASH160 of those UTXOs as the secrets, and the act of the house spending the coins puts the public key into the blockchain.  The device only has to store the address and watch the blockchain for any transactions spending coins owned by the address.  When it sees it, it can automatically complete the transaction.  

And, he doesn't even need to put in his password.  Because he already had to put it in when signing the original transaction... he can pre-sign the return transaction to himself, and the app can just plug in the public key into the redeem script to complete it.

The only catch is that the house not spend the other output for 30 days.  After that, they spend the other output, and if the winner never claimed the money, then the loser can.  No coins lost!

---

The actual output script for the transaction is complicated, but here it is (because it was fun figuring out the script ):


Redeem script:

     BettorA:   0 0   SigA  PreimageA
or
     BettorB:   SigB PreimageB 0 0

I don't know if that's exactly right, but it's probably close.