Idea: InstantBet

[HostFat]

Yesterday I was in a club, and there was a boxing match from 2/3 different schools. (nothing really serious)
I thought it would be nice to open a bet on them, just a moment before the match start.

Do you think that it's possible to make a smartphone app that works through bluetooth/wifi?
People should be able to open a bet where ever they want for what ever they want.

Something like a "mobile-betsofbitco.in"

Bet creators should also have a rating.

I want that the next time I'll see a match (or everything else), I'll take my smartphone to see if there is a betting going on the place.
If there isn't, I'll be the first to open it!

InstantBet will also save GPS coordinates, so after I'll arrive "everywhere", my smartphone will give me a notice if there are betting around the place, and  I'll go to see what is happening. (I'll see on the map all open bets around)

I hope that someone will take this idea and then make it true!

[bbit]

I like the idea where it's anywhere, anytime for the "moment" . Heck you could be down at Santa Monica Pier and if there is a guy who is throwing up bowling pins and you place a bet if will drop them!  Good thinking. Kind of the snapchat of betting where it be for a little bit and dissolve.

[etotheipi]

I like the idea where it's anywhere, anytime for the "moment" . Heck you could be down at Santa Monica Pier and if there is a guy who is throwing up bowling pins and you place a bet if will drop them!  Good thinking. Kind of the snapchat of betting where it be for a little bit and dissolve.

I bet there's a cool cryptographic way that this could be assisted by the house, without the house actually taking part in the gambling itself (it would really just be a courtesy).  They publish some secret material, and that material is somehow folded into an escrow transaction.  When the fight is over, the house would release one of two secrets, depending on the outcome, and that secret is sufficient for the winner to claim the funds. 

[edd]

This is an interesting concept. The "house" should require a fee to become a member with bet creating abilities. This way the house makes money and the bet creator's history and reputation can be viewed by potential participants.

[etotheipi]

This is an interesting concept. The "house" should require a fee to become a member with bet creating abilities. This way the house makes money and the bet creator's history and reputation can be viewed by potential participants.

If I had more time, I'd try to flesh out this idea further.  I just wanted to point out that I suspect this is possible for the purposes of the operator of the particular event to assist with bets being placed, without having to actually get a license to operate a gambling operation.  Maybe that's wishful thinking.

Also, due to multi-signature transactions, credit and reputation would be irrelevant.  Both bettors would be committing actual bitcoins to the transaction ... the only way to release them is using the released secret.  No trust would have to be involved.

It wouldn't surprise me if this was possible, but I haven't thought through the details yet.

[edd]

This is an interesting concept. The "house" should require a fee to become a member with bet creating abilities. This way the house makes money and the bet creator's history and reputation can be viewed by potential participants.

If I had more time, I'd try to flesh out this idea further.  I just wanted to point out that I suspect this is possible for the purposes of the operator of the particular event to assist with bets being placed, without having to actually get a license to operate a gambling operation.  Maybe that's wishful thinking.

Also, due to multi-signature transactions, credit and reputation would be irrelevant.  Both bettors would be committing actual bitcoins to the transaction ... the only way to release them is using the released secret.  No trust would have to be involved.

It wouldn't surprise me if this was possible, but I haven't thought through the details yet.

This would create a lot of work for the house. The site operator(s) would have to verify the winner of every bet. Let's take the OP's example: if the winners weren't instantly published online, how long might it take for the winner to receive their BTC and how much could one expect from the site operator in tracking down any relevant info?

[HostFat]

The site operator(s)...

I know that it's something hard, but was hopping that it was possible without a direct control from someone else "out circle / betting environment".
Anyway, even if it's needed a remote house, the main target of my idea is giving the possibility to bet everywhere without any direct contact between the participants.
No one should know who is participating to the bet neither who opened it.

It isn't probably a good idea to open a bet if there are only 2/3 people around (and they aren't your friends)

[etotheipi]

This is an interesting concept. The "house" should require a fee to become a member with bet creating abilities. This way the house makes money and the bet creator's history and reputation can be viewed by potential participants.

If I had more time, I'd try to flesh out this idea further.  I just wanted to point out that I suspect this is possible for the purposes of the operator of the particular event to assist with bets being placed, without having to actually get a license to operate a gambling operation.  Maybe that's wishful thinking.

Also, due to multi-signature transactions, credit and reputation would be irrelevant.  Both bettors would be committing actual bitcoins to the transaction ... the only way to release them is using the released secret.  No trust would have to be involved.

It wouldn't surprise me if this was possible, but I haven't thought through the details yet.

This would create a lot of work for the house. The site operator(s) would have to verify the winner of every bet. Let's take the OP's example: if the winners weren't instantly published online, how long might it take for the winner to receive their BTC and how much could one expect from the site operator in tracking down any relevant info?

To clarify, the idea was that the house simply releases one code publicly before the event that bettors would somehow make part of their betting transactions on that particular event.  When the event is over, the house publicly releases one of two secret codes publicly, which cryptographically allows the winner to sign the transaction to himself.  Obviously, if the house has to verify each individual bet that kind of defeats the purpose -- this would be one operation per event for the house.  I was just saying it wouldn't surprise me if there was a crypto trick that made this possible.

You can also use pure multi-signature transactions to do this, but if the loser is a sore loser, there may not be any incentive for him to help you release the coins in your direction.  This starts going down the buyer-seller-escrow route, where you could solve this by having each side submit 20% deposit on top of the bet, that they get back when the bet is over, and that way both sides have an incentive for the bet to be completed.  It's possible, but may be too complicated without an app specifically designed to facilitate it.

[edd]

The site operator(s)...

I know that it's something hard, but was hopping that it was possible without a direct control from someone else "out circle / betting environment".
Anyway, even if it's needed a remote house, the main target of my idea is giving the possibility to bet everywhere without any direct contact between the participants.
No one should know who is participating to the bet neither who opened it.

It isn't probably a good idea to open a bet if there are only 2/3 people around (and they aren't your friends)

No matter what, some agreed upon authority needs to verify the outcome. Either, A) the house does it, or B) a bettor does it.

If the house decides which side won and which side lost, it renders local, small events impractical. This might as well be an app for Bets of Bitcoin.

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.

[etotheipi]

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. 

[cbeast]

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.

[etotheipi]

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.

The problem with Casascius's tool, and all other EC-trick-based multi-sig, is that it doesn't have the same [necessary] flexibility of using network-based multi-sig.
(1) The coins only go 100% to bettor A or 100% to bettor B.  There is no splitting them without trusting one party.  What if the bet needs to be cancelled? 
(2) A user has to give up a private key in their wallet in order to let the other user take the coins.  This is something I never want to deal with as a client developer:  sometimes it's an epic fail to reveal the private key, sometimes it's expected to reveal a private key. 

I think Casascius's tool is pretty cool, and I am glad someone is making it possible to do these types of transactions.  But it's only an 80-90% solution, in terms of being able to make it accessible to a wider audience. 

[killerstorm]

I bet there's a cool cryptographic way that this could be assisted by the house, without the house actually taking part in the gambling itself (it would really just be a courtesy).  They publish some secret material, and that material is somehow folded into an escrow transaction.  When the fight is over, the house would release one of two secrets, depending on the outcome, and that secret is sufficient for the winner to claim the funds. 

It is possible to implement this using hashes, I've even written a script which does that: https://bitcointalk.org/index.php?topic=8821.msg286271#msg286271 (read starting from BTW).

It's a pity that it's hard to get support for new transaction types in Bitcoin.

[SlickTheNick]

kind of a really cool idea though. How would you determine wether a bet was actually won or lost or not though..?

[killerstorm]

@killerstorm
Maybe one can design new blockchain for
these types of transactions )
I doubt that Big bitcoiners will support
betting contracts in the Bitcoin blockhain.

I guess it won't be hard to get this in one of alt-chains: it is safe to enable script type like that and it won't create too much blockchain bloat.

One can implement it right away in liquidcoin as with liquidcoin you can be your own miner (fixed difficulty). Too bad it was dropped by vircurex, now it's probably not very different from testnet.

But I imagine if there is a solid implementation one of major alt-chains like litecoin can approve this script to differentiate itself from bitcoin.

What puzzling me more is the question :
"How can we setup decentralised betting system with
tradeable bets, but WITHOUT oracle ?!"
I mean what kind of crypto could be usefull
here ?

If you want bets on external events, there should be an authoritative source of information. If you rule out centralized source, source can be decentralized, i.e. you need consensus of some sort.

It is probably possible to use bitcoin consensus-making mechanism (i.e. majority of miners), but it's impractical if miners would have to track many bets.

I think a practical trade-off between centralized and decentralized solutions would be voting: authoritative information about real-world events come from a central source, but that source is elected by votes of stakeholders. So if current authority is dead or corrupt it is possible to replace it with something else.

This mechanism is outlined in MasterCoin design: http://bitcoinmedia.com/the-second-bitcoin-whitepaper/

Note that it's a bit too light on details so not directly implementable, and security aspects are debatable.

Can colored coins be used for this ?

There is no straightforward solution, as far as I know, but it is possible to emulate some of MasterCoin features using colored coins.

[killerstorm]

Bets are tradeable between players,
roughly speaking like in Intrade market,

On futures market price converges to spot price under no-arbitrage condition. But arbitrage is possible only due to settlement where exchange forces market players to deliver or settle.

Without settlement it would be a game which is called "who has deeper pockets wins". Market will converge only if majority of players are altruistic. Rational players with large reserves can manipulate the price to get profit.

You cannot perform settlement automatically, settlement needs to be connected to external events.

I doubt that clean and accurate solution exists (even theoretically), but there might be some approximate market-based solution.

Particularly, outcome shouldn't depend on one deciding factor (e.g. 'who has more money'), but on combination of factors.

For example, proof-of-work based consensus might override market decision. For example, if miners detect price manipulation (non-convergence), they can unwind bets and zero-out asshole's balance. So now market manipulation is punishable and so market players would be reluctant to do that.

Of course, collusion between miners and manipulating speculators is possible. But miners generally tend to be more "altruistic" since they are interested in long-term viability of host currency. So such collusion is unlikely. (Or, less likely.)

Another possible way to punish assholes is hard fork/revolt. Example: Let's say bets are done using currency FooCoin and settlement is controlled by an oracle operator. If users detect that oracle isn't trustworthy they can migrate to currency BarCoins which would have another oracle operator. If some assholes profit from oracle's corruption they might be banned during migration.

What if users will create forks without a good reason? Nothing stops them, but there is an inertia, using an established currency has its benefits, so they won't switch to fork unless it is actually required.

(Currency migration is possible using colored coins, I think, but it requires trusted party... To some extent. If migration process fails users can migrate to yet another currency. )

[killerstorm]

Maybe the part of the Bitcoiners' resistance
 against new types  of transactions is
 due to their fears of accusations against
 Bitcoin for participating in "illegal   gambling" and to the fact that adding
 "betting" transactions  will open the way
 for Assassination Market ( associated with
 Bitcoin ).

Secure bets are already possible using multi-sig escrow with trusted arbitrator. Arbitrator will have to sign transactions, but he can hide behind Tor or something like that, so it's likely not a problem.

Hash-locked escrow does not require active arbitrator (as he simply needs to release an unlocking key), but is this difference fundamental? I doubt that.

[HostFat]

What is missing to make this real?
A bounty?
Are there already all functionalities from the bitcoin network?

[killerstorm]

What is missing to make this real?
A bounty?
Are there already all functionalities from the bitcoin network?

There are several different ways to do this. Some are relatively easy to implement and other are hard or impossible.

While some proof-of-concept probably can be done in a couple of days, a smartphone app and all the stuff is pretty involved, it would likely take months to implement and polish it.

So, basically, it's unlikely to happen without a business plan of some sort... Very few people can spend a couple of months of their time just on some fun app.