Adraza
I kind of stumbled over your post via bit2factor.org.
I'm not sure if I can follow your thoughts.
One thing I find very promising: You can use bitcoin based escrow not only for bitcoin-based trades, but for anything. You could sell you car for horses.
Other than that the "hedging" you are proposing is normally covered with standard financial instruments, derivatives like futures/options:
https://en.wikipedia.org/wiki/Derivative_%28finance%29
So, I don't see a revolutionary idea behind that. Just like when buying any commodity like i.e. steel or cotton, you could reduce the risk against BTC volatility this way. I believe there are even some exchanges that offer these derivatives (i.e. https://icbit.se/).
But there is definitely more potential to bitcoin based trading/escrow.
-BeeCoin.
Topic: TRUST AND SECURITY FOR THE MASSES (Read 827 times)
My brain suddenly become hyperactive and I am producing ANOTHER STEP/LEVEL of the problem.
I will try to explain myself.
So, I was thinking "this is a Bitcoin related technology", then we can apply it only to BTC type transactions, whether buying something or betting against something etc. All the transactions being in BTC network, denominated in BTC 'currency'.
What if I really do not trust BTC's volatility? Or I am a short term bear?
What if I want the transaction/ bet to be in USD? Or EUR?
As far as I know the current solution is to trust an escrow that changes the BTC in USD/EUR/ whatever at some exchange then deposits the fiat somewhere or just keep the money in the exchange account.
Basically that adds an additional layer of INSECURITY: the exchange itself (MTGox, etc).
So the parties involved should trust the ESCROW (remember we can not apply the cryptographic escrow here because the escrow has to be able to SPEND the BTC in order to get fiat) and the EXCHANGE!
Additionally if the escrow chooses to withdraw the fiat money from the exchange there is another burden of trust to the BANK where the ESCROW has the account.
Not a real safe method, huh?!
The beauty of my idea is that we do not need all of these.
We can have a SAFE transaction/bet/whatever denominated in USD/EUR/whatever, using an easy to use implementation (FOR THE MASSES) like here http://www.bitescrow.org/, a method based on cryptografic escrow idea https://en.bitcoin.it/wiki/User:Casascius/Escrow_scheme_draft.
The parties need just an escrow that is able to judge the situation (if and only if the parties do not agree about the transaction) and that CAN NOT STEAL THE MONEY ! !
I repeat: no need to be denominated in BTC!!
Buying Good/Services Scenario:
Seller A and Buyer B agree to have a transaction denominated in currency XXX (where XXX means USD, EUR, GBP, LTC etc.,)
Also I do not think it is necessary to be fiat currency, or even be a currency at all. Maybe I want (to barter) to trade products for products: chickens, carrots, gold coins, Mhashes, or even actions like "doing 10 pushups", "receiving 10 kicks in the butt" etc.
The only condition should be that "the currency" XXX is traded against BTC somewhere (most probably this solution extends for any cryptocoin as a way of providing value and safety/escrow, but I will resume to BTC for now) and it will be traded against BTC in the future when the transaction is over.
And both the Seller and the Buyer agree about the source of price at the beginning and at the end of the Transaction.
Opening Price BTCXXX = o (how many XXX are buying 1 BTC at the beginning of the Transaction)
Ending Price BTCXXX = e (how many XXX are buying 1 BTC when the Transaction is over)
Seller A agrees to provide to Buyer B a quantity "a" of products for a quantity "b" of currency XXX, at a certain time.
Buyer B agrees to pay a quantity "b" of "currency" XXX (after receiving "a" products), at a certain time in future.
1.
The Escrow E generates a FIRST PAIR of escrow invitations (keys) e11 e12; he gives one to Seller A and one to Buyer B.
Seller A generates FIRST BTC public address (PA1) and another 'payment invitation' =key p1 that he gives to Buyer B.
From 'escrow invitation' key e12 and 'payment invitation' p1 Buyer B generates FIRST BTC public address (PA1).
So after 1st step:
Escrow E knows 2 escrows invitations e11 and e12. He does not know the Public addresss nor the private key. And only using his information he can not find them.
Seller A knows escrow invitation e11 and public address PA1 and payment invitation p1. He can verify the balance of PA1. He can not spend the btc from PA1. He does not know the private key. In order to find it he would need key e12 from E or B.
Buyer B knows escrow invitation e12 and public address PA1 and payment invitation p1. He can deposit (the price b in XXX) transformed in BTC to PA1 at current price = b/o. He can not spend the btc from PA1. He does not know the private key. In order to find them he would need key e11 from E or A.
2.
Additional steps to 'hedge' against BTCXXX appreciation. (1 BTC would buy more XXX)
The Escrow E generates a SECOND PAIR of escrow invitations (keys) e21 e22; he gives the first to Buyer B and the latest to Seller A .
Buyer B generates SECOND BTC public address (PA2) and 'payment invitations' =key p2 that he gives to Seller B.
From 'escrow invitation' key e22 and 'payment invitation' p2 Seller A generates SECOND BTC public address (PA2).
In PA2 The Seller deposits the price in BTC =b/o. (this is just an example; doing this way will hedge up to 100% increase in price)
3.
Additional steps to 'hedge' against BTCXXX going down. (1 BTC would buy less XXX)
The Escrow E generates a THIRD PAIR of escrow invitations (keys) e31 e32; he gives the first to Seller A and the latest to Buyer B .
Seller B generates THIRD BTC public address (PA3) and 'payment invitation' =key p3 that he gives to Buyer B.
From 'escrow invitation' key e32 and 'payment invitation' p3 Buyer B generates THIRD BTC public address (PA3).
In PA3 The Seller deposits the price in BTC =b/o. (this is just an example; doing this way will hedge up to 50% decrease in price)
Escrow E knows pairs of escrows invitations e11 and e12, e21 and e22, e31 and e32. He does not know the Public addressses nor the private keys. And only using his information he can not find them. He would need the payment invitations p1, p2, p3.
Seller A knows escrow invitations e11, e22, e31 and public addresses PA1, PA2, PA3 and payment invitations p1, p2, p3. He can verify the balance of any PA. He can not spend the btc from any PA. He does not know the private key. In order to find it he would need keys coresponding 'e' keys from E or B.
Buyer B knows escrow invitations e12, e21, e32 and public addresses PA1, PA2, PA3 and payment invitations p1, p2, p3. He can verify the balance of any PA. He can not spend the btc from any PA. He does not know the private keys. In order to find them he would need corresponding 'e' keys from E or A.
What happens if the price e is different than price o. At the end of the transaction the price 'b' denominated in XXX would have a different value than the initial sum.
Let's say e>o (it means at the end 1 BTC buys more XXX than at the beginning) therefore PA1 has (a+b)/o BTC and the value in XXX is
e*(a+b)/o.
What could happen?
Happiest Outcome:
A and B agrees about the transaction. After receiving the products a the Buyer B gives his 'escrow invitation' to the Seller A. The Seller A gets to know the private key of PA1. Imports the BTC in the wallet. Keeps for himself only the equivalent of (a+b) XXX = (a+b)/e, and the rest [(a+b)/o-(a+b)/e] sends it back to the Buyer B.
The escrow is not involved at all.
Almost Happy Outcome:
A and B agrees about the transaction. After receiving the products 'a' the Buyer B gives his 'escrow invitation' e12 to the Seller A. The Seller A gets to know the private key of PA1. Imports the BTC in the wallet. Keeps for himself MORE than the equivalent of (a+b) XXX = (a+b)/e. We have a disagreement. (This situation should not happen very often because the Seller knows he already has enough funds 'locked', so his best interest is to be honest.)
The Escrow steps in. He analyses the transaction and gives to the Buyer the key e22. So the buyer has access to the collateral fund of the Seller. He takes what he is entitled to compensate the Seller's "theft" and send the rest to the Seller. After that the Escrow gives e31 to the Buyer. The transaction is over.
1.b
In the unlikely event that the Buyer decides to be dishonest and take more than 'the theft' compensation, then the Escrow will release e31 to the Seller. The transaction is over. The last thief was punished.
What if e (it means at the end 1 BTC buys less XXX than at the beginning) therefore PA1 has (a+b)/o BTC and the value in XXX is
e*(a+b)/o.
What could happen?
Happiest Outcome:
A and B agrees about the transaction. After receiving the products 'a' the Buyer B gives his 'escrow invitation' e12 and e32 to the Seller A. The Seller A gets to know the private key of PA1 and PA3. Imports the BTC in the wallet. Keeps for himself only the equivalent of (a+b) XXX = (a+b)/e, and the rest [(a+b)/o-(a+b)/e] sends it back to the Buyer B.
The escrow is not involved at all. The transaction is over.
Almost Happy Outcome 1:
A and B agrees about the transaction. After receiving the products 'a' the Buyer B gives ONLY his 'escrow invitation' e12 to the Seller A. The Seller A gets to know the private key of PA1. Imports the BTC in the wallet. Ofcourse it is not enough. We have a disagreement. (This situation should not happen very often because the Buyer knows he already has enough funds 'locked', so his best interest is to be honest.)
The escrow steps in. He analyses the transaction and gives to the Seller the key e32. So the Seller has access to the collateral fund of the Buyer. He takes what he is entitled to compensate the Buyer's dishonesty and send the rest to the Buyer. After that the Escrow gives e21 to the Seller. The transaction is over.
1.b
In the unlikely event that the Seller decides to be dishonest and take more than Buyer's 'the theft' compensation, then the Escrow will release e21 to the Buyer. The transaction is over. The last thief was punished.
Almost Happy Outcome 2
A and B agrees about the transaction. After receiving the products 'a' the Buyer B gives his 'escrow invitation' e12 and e32 to the Seller A. The Seller A gets to know the private key of PA1 and PA3. Imports the BTC in the wallet. Keeps for himself MORE than the equivalent of (a+b) XXX = (a+b)/e.
(This situation should not happen very often because the Seller knows he already has enough funds 'locked', so his best interest is to be honest.)The escrow steps in. He analyses the transaction and will release e21 to the Buyer.
The transaction is over. The last thief was punished.
if e=o. Trivial scenario.
So to summarize:
The transaction can be denominated in anything else besides BTC, currency XXX.
The contract needs a predetermined, mutually agreed source of price for the 'currency' XXXBTC (Mtgox, etc.), without effectively ever changing the involved BTC into something else.
Both the Buyer and the Seller are strongly motivated to be honest. If they are not, they expose themselves to the risk that the other party to be dishonest.
There is no need to trust the honesty of the Escrow, just trust his judgement!
At least at the basic level. (With only one escrow there is the the risk of collusion with the other party, but with more Escrows (3, 5 etc.) the risk of collusion is reduced)
I will try to explain myself.
So, I was thinking "this is a Bitcoin related technology", then we can apply it only to BTC type transactions, whether buying something or betting against something etc. All the transactions being in BTC network, denominated in BTC 'currency'.
What if I really do not trust BTC's volatility? Or I am a short term bear?
What if I want the transaction/ bet to be in USD? Or EUR?
As far as I know the current solution is to trust an escrow that changes the BTC in USD/EUR/ whatever at some exchange then deposits the fiat somewhere or just keep the money in the exchange account.
Basically that adds an additional layer of INSECURITY: the exchange itself (MTGox, etc).
So the parties involved should trust the ESCROW (remember we can not apply the cryptographic escrow here because the escrow has to be able to SPEND the BTC in order to get fiat) and the EXCHANGE!
Additionally if the escrow chooses to withdraw the fiat money from the exchange there is another burden of trust to the BANK where the ESCROW has the account.
Not a real safe method, huh?!
The beauty of my idea is that we do not need all of these.
We can have a SAFE transaction/bet/whatever denominated in USD/EUR/whatever, using an easy to use implementation (FOR THE MASSES) like here http://www.bitescrow.org/, a method based on cryptografic escrow idea https://en.bitcoin.it/wiki/User:Casascius/Escrow_scheme_draft.
The parties need just an escrow that is able to judge the situation (if and only if the parties do not agree about the transaction) and that CAN NOT STEAL THE MONEY ! !
I repeat: no need to be denominated in BTC!!
Buying Good/Services Scenario:
Seller A and Buyer B agree to have a transaction denominated in currency XXX (where XXX means USD, EUR, GBP, LTC etc.,)
Also I do not think it is necessary to be fiat currency, or even be a currency at all. Maybe I want (to barter) to trade products for products: chickens, carrots, gold coins, Mhashes, or even actions like "doing 10 pushups", "receiving 10 kicks in the butt" etc.
The only condition should be that "the currency" XXX is traded against BTC somewhere (most probably this solution extends for any cryptocoin as a way of providing value and safety/escrow, but I will resume to BTC for now) and it will be traded against BTC in the future when the transaction is over.
And both the Seller and the Buyer agree about the source of price at the beginning and at the end of the Transaction.
Opening Price BTCXXX = o (how many XXX are buying 1 BTC at the beginning of the Transaction)
Ending Price BTCXXX = e (how many XXX are buying 1 BTC when the Transaction is over)
Seller A agrees to provide to Buyer B a quantity "a" of products for a quantity "b" of currency XXX, at a certain time.
Buyer B agrees to pay a quantity "b" of "currency" XXX (after receiving "a" products), at a certain time in future.
1.
The Escrow E generates a FIRST PAIR of escrow invitations (keys) e11 e12; he gives one to Seller A and one to Buyer B.
Seller A generates FIRST BTC public address (PA1) and another 'payment invitation' =key p1 that he gives to Buyer B.
From 'escrow invitation' key e12 and 'payment invitation' p1 Buyer B generates FIRST BTC public address (PA1).
So after 1st step:
Escrow E knows 2 escrows invitations e11 and e12. He does not know the Public addresss nor the private key. And only using his information he can not find them.
Seller A knows escrow invitation e11 and public address PA1 and payment invitation p1. He can verify the balance of PA1. He can not spend the btc from PA1. He does not know the private key. In order to find it he would need key e12 from E or B.
Buyer B knows escrow invitation e12 and public address PA1 and payment invitation p1. He can deposit (the price b in XXX) transformed in BTC to PA1 at current price = b/o. He can not spend the btc from PA1. He does not know the private key. In order to find them he would need key e11 from E or A.
2.
Additional steps to 'hedge' against BTCXXX appreciation. (1 BTC would buy more XXX)
The Escrow E generates a SECOND PAIR of escrow invitations (keys) e21 e22; he gives the first to Buyer B and the latest to Seller A .
Buyer B generates SECOND BTC public address (PA2) and 'payment invitations' =key p2 that he gives to Seller B.
From 'escrow invitation' key e22 and 'payment invitation' p2 Seller A generates SECOND BTC public address (PA2).
In PA2 The Seller deposits the price in BTC =b/o. (this is just an example; doing this way will hedge up to 100% increase in price)
3.
Additional steps to 'hedge' against BTCXXX going down. (1 BTC would buy less XXX)
The Escrow E generates a THIRD PAIR of escrow invitations (keys) e31 e32; he gives the first to Seller A and the latest to Buyer B .
Seller B generates THIRD BTC public address (PA3) and 'payment invitation' =key p3 that he gives to Buyer B.
From 'escrow invitation' key e32 and 'payment invitation' p3 Buyer B generates THIRD BTC public address (PA3).
In PA3 The Seller deposits the price in BTC =b/o. (this is just an example; doing this way will hedge up to 50% decrease in price)
Escrow E knows pairs of escrows invitations e11 and e12, e21 and e22, e31 and e32. He does not know the Public addressses nor the private keys. And only using his information he can not find them. He would need the payment invitations p1, p2, p3.
Seller A knows escrow invitations e11, e22, e31 and public addresses PA1, PA2, PA3 and payment invitations p1, p2, p3. He can verify the balance of any PA. He can not spend the btc from any PA. He does not know the private key. In order to find it he would need keys coresponding 'e' keys from E or B.
Buyer B knows escrow invitations e12, e21, e32 and public addresses PA1, PA2, PA3 and payment invitations p1, p2, p3. He can verify the balance of any PA. He can not spend the btc from any PA. He does not know the private keys. In order to find them he would need corresponding 'e' keys from E or A.
What happens if the price e is different than price o. At the end of the transaction the price 'b' denominated in XXX would have a different value than the initial sum.
Let's say e>o (it means at the end 1 BTC buys more XXX than at the beginning) therefore PA1 has (a+b)/o BTC and the value in XXX is
e*(a+b)/o.
What could happen?
Happiest Outcome:
A and B agrees about the transaction. After receiving the products a the Buyer B gives his 'escrow invitation' to the Seller A. The Seller A gets to know the private key of PA1. Imports the BTC in the wallet. Keeps for himself only the equivalent of (a+b) XXX = (a+b)/e, and the rest [(a+b)/o-(a+b)/e] sends it back to the Buyer B.
The escrow is not involved at all.
Almost Happy Outcome:
A and B agrees about the transaction. After receiving the products 'a' the Buyer B gives his 'escrow invitation' e12 to the Seller A. The Seller A gets to know the private key of PA1. Imports the BTC in the wallet. Keeps for himself MORE than the equivalent of (a+b) XXX = (a+b)/e. We have a disagreement. (This situation should not happen very often because the Seller knows he already has enough funds 'locked', so his best interest is to be honest.)
The Escrow steps in. He analyses the transaction and gives to the Buyer the key e22. So the buyer has access to the collateral fund of the Seller. He takes what he is entitled to compensate the Seller's "theft" and send the rest to the Seller. After that the Escrow gives e31 to the Buyer. The transaction is over.
1.b
In the unlikely event that the Buyer decides to be dishonest and take more than 'the theft' compensation, then the Escrow will release e31 to the Seller. The transaction is over. The last thief was punished.
What if e
e*(a+b)/o.
What could happen?
Happiest Outcome:
A and B agrees about the transaction. After receiving the products 'a' the Buyer B gives his 'escrow invitation' e12 and e32 to the Seller A. The Seller A gets to know the private key of PA1 and PA3. Imports the BTC in the wallet. Keeps for himself only the equivalent of (a+b) XXX = (a+b)/e, and the rest [(a+b)/o-(a+b)/e] sends it back to the Buyer B.
The escrow is not involved at all. The transaction is over.
Almost Happy Outcome 1:
A and B agrees about the transaction. After receiving the products 'a' the Buyer B gives ONLY his 'escrow invitation' e12 to the Seller A. The Seller A gets to know the private key of PA1. Imports the BTC in the wallet. Ofcourse it is not enough. We have a disagreement. (This situation should not happen very often because the Buyer knows he already has enough funds 'locked', so his best interest is to be honest.)
The escrow steps in. He analyses the transaction and gives to the Seller the key e32. So the Seller has access to the collateral fund of the Buyer. He takes what he is entitled to compensate the Buyer's dishonesty and send the rest to the Buyer. After that the Escrow gives e21 to the Seller. The transaction is over.
1.b
In the unlikely event that the Seller decides to be dishonest and take more than Buyer's 'the theft' compensation, then the Escrow will release e21 to the Buyer. The transaction is over. The last thief was punished.
Almost Happy Outcome 2
A and B agrees about the transaction. After receiving the products 'a' the Buyer B gives his 'escrow invitation' e12 and e32 to the Seller A. The Seller A gets to know the private key of PA1 and PA3. Imports the BTC in the wallet. Keeps for himself MORE than the equivalent of (a+b) XXX = (a+b)/e.
(This situation should not happen very often because the Seller knows he already has enough funds 'locked', so his best interest is to be honest.)The escrow steps in. He analyses the transaction and will release e21 to the Buyer.
The transaction is over. The last thief was punished.
if e=o. Trivial scenario.
So to summarize:
The transaction can be denominated in anything else besides BTC, currency XXX.
The contract needs a predetermined, mutually agreed source of price for the 'currency' XXXBTC (Mtgox, etc.), without effectively ever changing the involved BTC into something else.
Both the Buyer and the Seller are strongly motivated to be honest. If they are not, they expose themselves to the risk that the other party to be dishonest.
There is no need to trust the honesty of the Escrow, just trust his judgement!
At least at the basic level. (With only one escrow there is the the risk of collusion with the other party, but with more Escrows (3, 5 etc.) the risk of collusion is reduced)
"Do not give one party both codes until the transaction unless you need to force the coins to be released."
This isn't worded very well.
I do like the site though! Hope to use it in the future.
This isn't worded very well.
I do like the site though! Hope to use it in the future.
Mutli-way payment introduces extra complexity I think.
In many bets there is the potential for a push - bet is cancelled, or is a draw. Given that a feature of the bitcoin escrow is the ability for the payer to get their money back, that means that each bet payment would need to be controlled by a different private key.
For the simple 2-payer suggestion (a one-against-one bet), it should be fairly trivial for the payment invitation to generate two addresses.
One address is sent to the second party with the payment invitation, as per a regular escrow.
The second address is paid into by the first party, and sent to the second party so they can verify that the address matches the payment invitation, and verify that payment has been made.
Just a minor modification, but I think it should work.
In many bets there is the potential for a push - bet is cancelled, or is a draw. Given that a feature of the bitcoin escrow is the ability for the payer to get their money back, that means that each bet payment would need to be controlled by a different private key.
For the simple 2-payer suggestion (a one-against-one bet), it should be fairly trivial for the payment invitation to generate two addresses.
One address is sent to the second party with the payment invitation, as per a regular escrow.
The second address is paid into by the first party, and sent to the second party so they can verify that the address matches the payment invitation, and verify that payment has been made.
Just a minor modification, but I think it should work.
yes you are right
Usually I am modest but right now I think I am witnessing the beginning of a PARADIGM SHIFT ! !
And I am glad I am one the contributors!
And I am glad I am one the contributors!
I just wait to see the implementations of my ideas!
Apparently the browser based solution works offline so it should be safe.
Do not take my word as absolute truth!!
I am not a coder so I can not verify it.
The real issue here I think it is how EASY has become to benefit from the technology.
Apparently the browser based solution works offline so it should be safe.
Do not take my word as absolute truth!!
I am not a coder so I can not verify it.
The real issue here I think it is how EASY has become to benefit from the technology.
Mutli-way payment introduces extra complexity I think.
In many bets there is the potential for a push - bet is cancelled, or is a draw. Given that a feature of the bitcoin escrow is the ability for the payer to get their money back, that means that each bet payment would need to be controlled by a different private key.
For the simple 2-payer suggestion (a one-against-one bet), it should be fairly trivial for the payment invitation to generate two addresses.
One address is sent to the second party with the payment invitation, as per a regular escrow.
The second address is paid into by the first party, and sent to the second party so they can verify that the address matches the payment invitation, and verify that payment has been made.
Just a minor modification, but I think it should work.
In many bets there is the potential for a push - bet is cancelled, or is a draw. Given that a feature of the bitcoin escrow is the ability for the payer to get their money back, that means that each bet payment would need to be controlled by a different private key.
For the simple 2-payer suggestion (a one-against-one bet), it should be fairly trivial for the payment invitation to generate two addresses.
One address is sent to the second party with the payment invitation, as per a regular escrow.
The second address is paid into by the first party, and sent to the second party so they can verify that the address matches the payment invitation, and verify that payment has been made.
Just a minor modification, but I think it should work.
AND ANOTHER STEP
The possibility of having more than 2 parties involved in the transaction or bet.
And of course with adequate number of escrows/judges.
The possibility of having more than 2 parties involved in the transaction or bet.
And of course with adequate number of escrows/judges.
And I am pushing the wall ANOTHER STEP FURTHER:
The possibility of having 2 or more Escrow Agents (for the paranoids like me)
If we suspect collision of the other party with the escrow, we can prevent that having more escrows. Or at least we drastically reduce the chances.
Of course it would be convenient to have odd number of escrows; so we avoid the possibility of stalemate.
Something like a Jury Court.
The possibility of having 2 or more Escrow Agents (for the paranoids like me)
If we suspect collision of the other party with the escrow, we can prevent that having more escrows. Or at least we drastically reduce the chances.
Of course it would be convenient to have odd number of escrows; so we avoid the possibility of stalemate.
Something like a Jury Court.
I need some confirmations from the men able to read code. I can not. At least not properly.
But I think is trivial.
But I think is trivial.
I have discovered the casascius implementation https://en.bitcoin.it/wiki/User:Casascius/Escrow_scheme_draft
of an older idea https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation
transformed in a (I would say elegant) browser based application here http://www.bitescrow.org/
easy enough for people like me.
I am pushing this ONE STEP FURTHER:
escrow for betting purposes (instead of payee and payer, bettor 1 and bettor 1)
https://bitcointalksearch.org/topic/m.1901820
Necessary correction:
I would conceive a BET as a double transaction (back to back): Bettor A buys with his betting sum/wage a from the Bettor B the product/service called: "the future possibility of winning the bet and to be payed by B".
Bettor B buys with his betting sum/wage b from the Bettor A the product/service called: "the future possibility of winning the bet and to be paid by A".
So they should use two separate addresses and two separate sets of keys. Until the end of the bet both sums of money/bets are 'locked'.
After the bet:
The loser gives his two keys to the winner (corresponding to his money address and winner's money address)
If they do not want to cooperate the escrow E steps in, judges the situation and if there is a winner he gives both keys to the winner.
If there is a draw, nobody won, he gives the corresponding key to each of them so they can take their money back.
Not swapping the keys and the money, obviously.
of an older idea https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation
transformed in a (I would say elegant) browser based application here http://www.bitescrow.org/
easy enough for people like me.
I am pushing this ONE STEP FURTHER:
escrow for betting purposes (instead of payee and payer, bettor 1 and bettor 1)
https://bitcointalksearch.org/topic/m.1901820
Necessary correction:
I would conceive a BET as a double transaction (back to back): Bettor A buys with his betting sum/wage a from the Bettor B the product/service called: "the future possibility of winning the bet and to be payed by B".
Bettor B buys with his betting sum/wage b from the Bettor A the product/service called: "the future possibility of winning the bet and to be paid by A".
So they should use two separate addresses and two separate sets of keys. Until the end of the bet both sums of money/bets are 'locked'.
After the bet:
The loser gives his two keys to the winner (corresponding to his money address and winner's money address)
If they do not want to cooperate the escrow E steps in, judges the situation and if there is a winner he gives both keys to the winner.
If there is a draw, nobody won, he gives the corresponding key to each of them so they can take their money back.
Not swapping the keys and the money, obviously.
Jump to: