If the bet creator verifies the outcome, it would make it possible to use this solely as an app, without any third party intervention necessary. I could bet on anything from a coin toss to a street hockey game. The only issue would be trusting the bet creator to enter the correct outcome. I can't imagine anyone willing to impart that much trust unless the bet creator had built up some kind of reputation as an honest individual.
You can split the risk, using multi-sig transactions: both bets go into a transaction requiring 2-of-2 signatures to release it -- one from each bettor. Neither person actually controls the funds, and both have to agree to the final distribution of the funds (by providing a signature), in order for the money to be distributed. If it's not resolved agreeably, neither person gets the money -- so both sides have an incentive to play fairly.
This is the same idea as proposed for
buyer-seller escrow (with the same risks). The biggest risk is that a sore loser won't agree to unlock the coins for the winner. You can solve this by both sides putting an extra "risk deposit" that is returned at the end, so the loser still has incentive to complete the transaction. But unlike buyer-seller escrow, I imagine that the probability of one party losing their wallet before the bet is over is dramatically smaller -- so a third-party is still recommended, it's not critical to have one.
It would go like this:
(1) Bettor A offers bettor B 3:1 odds on the outcome of a bet -- Bettor A would put in 60 BTC, bettor B would put in 20 BTC, and whoever wins gets all of it.
(2) Bettor B agrees with a 10 BTC risk deposit, and sends A his public key (probably via QR code).
(3) Bettor A creates a tx putting in 70 BTC (60 + 10 risk deposit) on the input side and a single output of 100 BTC to a 2-of-2 multi-sig tx using both their public keys. Bettor A signs it. (Note that this transaction is
not valid because it has 70 BTC of inputs and 100 BTC of outputs).
(4) Better B receives the partial-tx from A, and adds a 30 BTC input (20 + 10 risk deposit). After B signs it, the transaction is now valid and is broadcast
(5) After the event, three things could happen:
--Bettor A wins: creates a tx spending the 100 BTC multi-sig: sending 90 BTC to himself, 10 BTC back to bettor B. Bettor B signs it and broadcasts
--Bettor B wins: creates a tx spending the 100 BTC multi-sig: sending 90 BTC to himself, 10 BTC back to bettor A. Bettor A signs it and broadcasts
--Something unusual happens and they agree to "cancel" the bet: create a tx sending 70 BTC back to A and 30 BTC back to B. They both sign it and then broadcast.
The beauty of this system is that neither party puts their money in before the other: either they both get the money in at the same time, or neither of them do. Similarly, at the conclusion of the bet, they both receive their funds at the same time. And they both have to agree to the payout tx.
This could actually be made into an app, and most of the above discussion would be hidden under the hood. As long as there is a convenient way to pass tx data between two unassociated phones.
Steps 1-4 can be done with Casascius' BtcAddress tool, with the exception that instead of B signing it, B instead verifies an Intermediate Passphrase code. I don't understand step 5. I thought this would require a separate second transaction. I like the term Counterparty Escrow.
Show Posts
