<p>Giving the operator the power to control the identity of the recipient won't work, since he can participate himself and declare himself the winner. A majority vote also isn't too good because an attacker can make multiple entries, which is cheap to do if he knows he can guarantee a win.</p>

<p>It is necessary that the winner will be decided according to public data (such as the hash of a future block), and that the operator (or majority) will not be able to secure funds before sending payment to the agreed winner.</p>

<p>The only way I can think of is burn-escrow. Each participant sends a tentative payment to the operator which cannot be reversed, it can either be carried through or burned (with a deposit that incentivizes carrying through). Then the operator sends to the winner using his own funds. Then every participant forwards the payment. If the operator does not send to the winner, participants burn the payment and refuse to do business with the operator again.</p>

<p>There is some risk that the operator will be honest but participants will neglect to forward payments, or that the operator will be fraudulent but participants forward payments anyway to get the deposit. But with a properly calibrated deposit, these risks can be mitigated and entered into the pricing.</p>

CC BY-SA 3.0
2012-03-06T10:14:13.790Z
2012-12-10T08:40:55.777Z
2012-12-10T08:40:55.777Z
Meni Rosenfeld
<p>There are a couple of bitcoin betting sites, but they all seem to require making a deposit with them. Is it possible to somehow use the Bitcoin contract system to establish a distributed betting pool? Once the bet is decided one way or the other, the transactions would become active. </p>

<p>The problem of course is who decides which side won. That could be the betting site operator. This way, you still have to trust them enough to make a fair judgement call, but at least they cannot just take everyone's deposits and run. The worst they can do is declare the wrong side of the pool the winner. Or maybe stay inactive, thereby locking funds (though this could be fixed by a decision deadline in the original contract).</p>

<p>Or this could be distributed as well. Maybe a majority of pool members gets to decide by some kind of voting process (requires fair losers). Or the block chain miners get to decide by including one of the two possible transactions into the block, just like they decide on double-spending right now?</p>

<p>Does any of this seem feasible (and meaningful)?</p>

CC BY-SA 3.0
2012-03-06T17:13:40.777Z
https://en.bitcoin.it/wiki/Contracts talks about various kinds of contracts that can be made with non-standard transactions.  They make my head spin, but could perhaps be used to do what you want.  Do you accept the operator being able to declare their own bets the winner?  At least that way they can't just run off with the funds from existing bets between two third parties.
Chris Moore
CC BY-SA 3.0
2012-03-06T21:05:44.927Z
The betting site operator can participate in the betting pool through shills and declare the side his shills all bet on the winner. So you still are trusting the site operator with some of the deposits.
David Schwartz
CC BY-SA 3.0
2012-03-07T00:15:40.870Z
"Do you accept the operator being able to declare their own bets the winner?" Yes.
Thilo
CC BY-SA 3.0
2012-03-31T18:58:18.193Z
The underlying problem you are trying to solve is how to let a party that you don't trust to decide what happens with your money.   Since the betting site is acting as escrow until the event where payout occurs, a lot of money can accumulate.  If that money is in an untraceable, non-reversible currency then the risk that the operator disappears with the escrowed funds increases.

This problem occurs with any similar venture that has this characteristic where it holds onto its customer's money.
Stephen Gornick
<trust><contracts><escrow><gambling>
Using Bitcoin contracts to run a betting site without the need for deposits?
Thilo
# Using Bitcoin contracts to run a betting site without the need for deposits?

(Asked by: username_0 on 2012-03-06)

There are a couple of bitcoin betting sites, but they all seem to require making a deposit with them. Is it possible to somehow use the Bitcoin contract system to establish a distributed betting pool? Once the bet is decided one way or the other, the transactions would become active.

The problem of course is who decides which side won. That could be the betting site operator. This way, you still have to trust them enough to make a fair judgement call, but at least they cannot just take everyone's deposits and run. The worst they can do is declare the wrong side of the pool the winner. Or maybe stay inactive, thereby locking funds (though this could be fixed by a decision deadline in the original contract).

Or this could be distributed as well. Maybe a majority of pool members gets to decide by some kind of voting process (requires fair losers). Or the block chain miners get to decide by including one of the two possible transactions into the block, just like they decide on double-spending right now?

Does any of this seem feasible (and meaningful)?

**Tags:** trust, contracts, escrow, gambling

> **Comments:**
> **username_1**: https://en.bitcoin.it/wiki/Contracts talks about various kinds of contracts that can be made with non-standard transactions.  They make my head spin, but could perhaps be used to do what you want.  Do you accept the operator being able to declare their own bets the winner?  At least that way they can't just run off with the funds from existing bets between two third parties.  
> **username_2**: The betting site operator can participate in the betting pool through shills and declare the side his shills all bet on the winner. So you still are trusting the site operator with some of the deposits.  
> **username_0**: "Do you accept the operator being able to declare their own bets the winner?" Yes.  
> **username_3**: The underlying problem you are trying to solve is how to let a party that you don't trust to decide what happens with your money.   Since the betting site is acting as escrow until the event where payout occurs, a lot of money can accumulate.  If that money is in an untraceable, non-reversible currency then the risk that the operator disappears with the escrowed funds increases.  This problem occurs with any similar venture that has this characteristic where it holds onto its customer's money.  

---

## 1 answers

### Answer by username_4 on 2012-03-06. Score: 5

Giving the operator the power to control the identity of the recipient won't work, since he can participate himself and declare himself the winner. A majority vote also isn't too good because an attacker can make multiple entries, which is cheap to do if he knows he can guarantee a win.

It is necessary that the winner will be decided according to public data (such as the hash of a future block), and that the operator (or majority) will not be able to secure funds before sending payment to the agreed winner.

The only way I can think of is burn-escrow. Each participant sends a tentative payment to the operator which cannot be reversed, it can either be carried through or burned (with a deposit that incentivizes carrying through). Then the operator sends to the winner using his own funds. Then every participant forwards the payment. If the operator does not send to the winner, participants burn the payment and refuse to do business with the operator again.

There is some risk that the operator will be honest but participants will neglect to forward payments, or that the operator will be fraudulent but participants forward payments anyway to get the deposit. But with a properly calibrated deposit, these risks can be mitigated and entered into the pricing.


---

