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.bIn 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<o (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.bIn 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 2A 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)
