Topic: Cryptoanarchy round 2 : Fully decentralized free market. (Read 2464 times)
I can see it working if the deposit amounts significantly outweigh the value of goods being transferred.
There needs to be an additional deposit amount paid by the buyer and determined by the seller. Once the transaction is confirmed by both parties, the buyer gets this amount back. This ensures that both parties have some "skin in the game" that motivates both to confirm that transaction. This will eliminate any extraneous impulse of the buyer to simply never confirm the transaction.
Actually, now that I think about it, there should probably be a seller's deposit as well, to ensure he actually sends the product. The buyer and seller deposits make it a bit more complicated, but they ensure everyone is motivated to conclude or mediate the transaction.
If you think about the three scenarios...
Current proposed:
1. Buyer puts up the money, seller delivers product. --> Both happy, price goes to seller.
2. Buyer puts up the money, seller does not deliver product. --> Buyer's money is destroyed. Seller doesn't care.
3. Buyer puts up the money, seller delivers product, buyer doesn't confirm product. --> Seller doesn't get paid. Buyer doesn't care because, to him, he's lost the money either way.
With Buyer deposit:
1. Buyer puts up the money, seller delivers product. --> Both happy, price goes to seller. Buyer's deposit returned.
2. Buyer puts up the money, seller does not deliver product. --> Buyer's money is destroyed. Seller doesn't care.
3. Buyer puts up the money, seller delivers product, buyer doesn't confirm product. --> Seller doesn't get paid. Buyer remembers deposit, completes/mediates deal.
With Buyer and Seller deposits:
1. Buyer puts up the money, seller delivers product. --> Both happy, price goes to seller. Both deposits returned.
2. Buyer puts up the money, seller does not deliver product. --> Buyer's money is destroyed. Seller remembers that his deposit is on the line, deliver's product.
3. Buyer puts up the money, seller delivers product, buyer doesn't confirm product. --> Seller doesn't get paid. Buyer remembers deposit, completes/mediates deal.
Both deposit amounts should be equal, for simplicity and also to ensure that the seller, who is listing the products by both price and deposit amounts, is doing so fairly.
Actually, now that I think about it, there should probably be a seller's deposit as well, to ensure he actually sends the product. The buyer and seller deposits make it a bit more complicated, but they ensure everyone is motivated to conclude or mediate the transaction.
If you think about the three scenarios...
Current proposed:
1. Buyer puts up the money, seller delivers product. --> Both happy, price goes to seller.
2. Buyer puts up the money, seller does not deliver product. --> Buyer's money is destroyed. Seller doesn't care.
3. Buyer puts up the money, seller delivers product, buyer doesn't confirm product. --> Seller doesn't get paid. Buyer doesn't care because, to him, he's lost the money either way.
With Buyer deposit:
1. Buyer puts up the money, seller delivers product. --> Both happy, price goes to seller. Buyer's deposit returned.
2. Buyer puts up the money, seller does not deliver product. --> Buyer's money is destroyed. Seller doesn't care.
3. Buyer puts up the money, seller delivers product, buyer doesn't confirm product. --> Seller doesn't get paid. Buyer remembers deposit, completes/mediates deal.
With Buyer and Seller deposits:
1. Buyer puts up the money, seller delivers product. --> Both happy, price goes to seller. Both deposits returned.
2. Buyer puts up the money, seller does not deliver product. --> Buyer's money is destroyed. Seller remembers that his deposit is on the line, deliver's product.
3. Buyer puts up the money, seller delivers product, buyer doesn't confirm product. --> Seller doesn't get paid. Buyer remembers deposit, completes/mediates deal.
Both deposit amounts should be equal, for simplicity and also to ensure that the seller, who is listing the products by both price and deposit amounts, is doing so fairly.
That's what we do already... Buyer and seller deposit coin in the multisig address, and that address won't unlock until both parties agree to sign a transaction that empties it.
There needs to be an additional deposit amount paid by the buyer and determined by the seller. Once the transaction is confirmed by both parties, the buyer gets this amount back. This ensures that both parties have some "skin in the game" that motivates both to confirm that transaction. This will eliminate any extraneous impulse of the buyer to simply never confirm the transaction.
Actually, now that I think about it, there should probably be a seller's deposit as well, to ensure he actually sends the product. The buyer and seller deposits make it a bit more complicated, but they ensure everyone is motivated to conclude or mediate the transaction.
If you think about the three scenarios...
Current proposed:
1. Buyer puts up the money, seller delivers product. --> Both happy, price goes to seller.
2. Buyer puts up the money, seller does not deliver product. --> Buyer's money is destroyed. Seller doesn't care.
3. Buyer puts up the money, seller delivers product, buyer doesn't confirm product. --> Seller doesn't get paid. Buyer doesn't care because, to him, he's lost the money either way.
With Buyer deposit:
1. Buyer puts up the money, seller delivers product. --> Both happy, price goes to seller. Buyer's deposit returned.
2. Buyer puts up the money, seller does not deliver product. --> Buyer's money is destroyed. Seller doesn't care.
3. Buyer puts up the money, seller delivers product, buyer doesn't confirm product. --> Seller doesn't get paid. Buyer remembers deposit, completes/mediates deal.
With Buyer and Seller deposits:
1. Buyer puts up the money, seller delivers product. --> Both happy, price goes to seller. Both deposits returned.
2. Buyer puts up the money, seller does not deliver product. --> Buyer's money is destroyed. Seller remembers that his deposit is on the line, deliver's product.
3. Buyer puts up the money, seller delivers product, buyer doesn't confirm product. --> Seller doesn't get paid. Buyer remembers deposit, completes/mediates deal.
Both deposit amounts should be equal, for simplicity and also to ensure that the seller, who is listing the products by both price and deposit amounts, is doing so fairly.
Actually, now that I think about it, there should probably be a seller's deposit as well, to ensure he actually sends the product. The buyer and seller deposits make it a bit more complicated, but they ensure everyone is motivated to conclude or mediate the transaction.
If you think about the three scenarios...
Current proposed:
1. Buyer puts up the money, seller delivers product. --> Both happy, price goes to seller.
2. Buyer puts up the money, seller does not deliver product. --> Buyer's money is destroyed. Seller doesn't care.
3. Buyer puts up the money, seller delivers product, buyer doesn't confirm product. --> Seller doesn't get paid. Buyer doesn't care because, to him, he's lost the money either way.
With Buyer deposit:
1. Buyer puts up the money, seller delivers product. --> Both happy, price goes to seller. Buyer's deposit returned.
2. Buyer puts up the money, seller does not deliver product. --> Buyer's money is destroyed. Seller doesn't care.
3. Buyer puts up the money, seller delivers product, buyer doesn't confirm product. --> Seller doesn't get paid. Buyer remembers deposit, completes/mediates deal.
With Buyer and Seller deposits:
1. Buyer puts up the money, seller delivers product. --> Both happy, price goes to seller. Both deposits returned.
2. Buyer puts up the money, seller does not deliver product. --> Buyer's money is destroyed. Seller remembers that his deposit is on the line, deliver's product.
3. Buyer puts up the money, seller delivers product, buyer doesn't confirm product. --> Seller doesn't get paid. Buyer remembers deposit, completes/mediates deal.
Both deposit amounts should be equal, for simplicity and also to ensure that the seller, who is listing the products by both price and deposit amounts, is doing so fairly.
In this proposed system, it would be possible for the vendor to deliver nothing
and offer the buyer X% of the funds or nothing, right? Or visa versa, buyer
could receive product and refuse to unlock the full payment. A sense of fairness
would motivate the cheated party to refuse the offer, but their monetary
incentives are aligned with cooperating with the cheater.
This goes a long way toward reducing the trust necessary, since a cheating party
cannot win without the cooperation of their victim, but it still requires both
parties to trust each other to a degree. I don't think it's possible for a
system involving only two parties that allows for partial refunds not to be
exploitable.
An obvious solution is to include a reputation system, but that introduces a
host of new problems to prevent the reputation system itself from being gamed; a
web of trust approach may be necessary to prevent sibyl attacks. It also opens
the possibility of extortion based on threatened reputation tarnishing.
A different approach that I've been thinking about is for both parties to, as a
matter of protocol, use their private keys to create the transactions unlocking
funds and then discard the keys. There's no way to enforce discarding of the
keys of course, but as long as a potential cheater cannot expect
potential victims to be able to cooperate in non-protocol extortion
transactions, there is no longer any way for either party to give the other a
"X% or nothing" offer. The disadvantage of this approach is that it makes it
impossible for parties to agree on such an offer when it is valid, if say the
package was damaged in the mail and both parties would want to agree to split
the loss; that would have to be handled by the buyer unlocking the funds to the
seller with the understanding that the seller will voluntarily send a partial
refund. I think the loss of the ability to handle special cases within the
system is worth the benefit of making extortion impossible, though.
Extortion-free 2-of-2 protocol:
1. Buyer and seller exchange keys, creating escrow account
2. Buyer sends seller unsigned transaction funding escrow
3. Seller sends buyer seller-signed transaction unlocking funds from (2) to seller; discards key
4. Buyer sends seller buyer-signed transaction unlocking funds from (2) to buyer
5. Buyer signs transaction from (2) and (4)
6. Buyer discards private key
7. Buyer broadcasts signed transaction funding escrow
From this point:
- Buyer can unlock funds to seller
- Seller can unlock funds to buyer
- No one can create any other kind of transaction for the account
The only possible gaming of such a system is a fake seller, who actually just
wants buyers to throw away their money. That can easily be avoided by prefacing
the above with a similarly-created inextortable bond, which could be a small
proportion of the price being exchanged (it just needs to cost something
for a party to cost the other party, since they don't stand to gain anything
from it anyway). To avoid just switching the problem to fake buyers, both
parties must contribute to the bond account.
Pre-exchange bond:
1. Parties exchange keys, creating accounts bond1 and bond2
2. Parties exchange unsigned transactions funding bond1
3. Seller sends buyer time-locked signed transaction returning buyer's funds
from bond1 (to be used if seller never funds bond)
4. Buyer signs transaction from (3), creates signed transaction moving all funds
from bond1 to bond2, discards bond1 key
5. Buyer sends seller unsigned transaction moving funds from bond1 to bond2
6. Seller signs transaction from (5), discards bond2 key, sends to buyer
7. Buyer funds bond1
8. Buyer sends seller signed transaction moving funds from bond1 to bond2
9. Seller funds bond1, signs and broadcasts transaction from ( 8 )
From this point:
- Both parties have equal bonds
- Neither party can create any transaction doing anything but releasing their
bonds
In the process of setting up the bond, at no point could any party cost the
other party anything without losing the same amount.
and offer the buyer X% of the funds or nothing, right? Or visa versa, buyer
could receive product and refuse to unlock the full payment. A sense of fairness
would motivate the cheated party to refuse the offer, but their monetary
incentives are aligned with cooperating with the cheater.
This goes a long way toward reducing the trust necessary, since a cheating party
cannot win without the cooperation of their victim, but it still requires both
parties to trust each other to a degree. I don't think it's possible for a
system involving only two parties that allows for partial refunds not to be
exploitable.
An obvious solution is to include a reputation system, but that introduces a
host of new problems to prevent the reputation system itself from being gamed; a
web of trust approach may be necessary to prevent sibyl attacks. It also opens
the possibility of extortion based on threatened reputation tarnishing.
A different approach that I've been thinking about is for both parties to, as a
matter of protocol, use their private keys to create the transactions unlocking
funds and then discard the keys. There's no way to enforce discarding of the
keys of course, but as long as a potential cheater cannot expect
potential victims to be able to cooperate in non-protocol extortion
transactions, there is no longer any way for either party to give the other a
"X% or nothing" offer. The disadvantage of this approach is that it makes it
impossible for parties to agree on such an offer when it is valid, if say the
package was damaged in the mail and both parties would want to agree to split
the loss; that would have to be handled by the buyer unlocking the funds to the
seller with the understanding that the seller will voluntarily send a partial
refund. I think the loss of the ability to handle special cases within the
system is worth the benefit of making extortion impossible, though.
Extortion-free 2-of-2 protocol:
1. Buyer and seller exchange keys, creating escrow account
2. Buyer sends seller unsigned transaction funding escrow
3. Seller sends buyer seller-signed transaction unlocking funds from (2) to seller; discards key
4. Buyer sends seller buyer-signed transaction unlocking funds from (2) to buyer
5. Buyer signs transaction from (2) and (4)
6. Buyer discards private key
7. Buyer broadcasts signed transaction funding escrow
From this point:
- Buyer can unlock funds to seller
- Seller can unlock funds to buyer
- No one can create any other kind of transaction for the account
The only possible gaming of such a system is a fake seller, who actually just
wants buyers to throw away their money. That can easily be avoided by prefacing
the above with a similarly-created inextortable bond, which could be a small
proportion of the price being exchanged (it just needs to cost something
for a party to cost the other party, since they don't stand to gain anything
from it anyway). To avoid just switching the problem to fake buyers, both
parties must contribute to the bond account.
Pre-exchange bond:
1. Parties exchange keys, creating accounts bond1 and bond2
2. Parties exchange unsigned transactions funding bond1
3. Seller sends buyer time-locked signed transaction returning buyer's funds
from bond1 (to be used if seller never funds bond)
4. Buyer signs transaction from (3), creates signed transaction moving all funds
from bond1 to bond2, discards bond1 key
5. Buyer sends seller unsigned transaction moving funds from bond1 to bond2
6. Seller signs transaction from (5), discards bond2 key, sends to buyer
7. Buyer funds bond1
8. Buyer sends seller signed transaction moving funds from bond1 to bond2
9. Seller funds bond1, signs and broadcasts transaction from ( 8 )
From this point:
- Both parties have equal bonds
- Neither party can create any transaction doing anything but releasing their
bonds
In the process of setting up the bond, at no point could any party cost the
other party anything without losing the same amount.
Quote from: 12648430
1. Buyer and Seller generate 3 keypairs, swapping pubkeys, producing 3 2-of-2 addresses
2. Buyer deposits BTCamount to address A
3. Seller deposits BTCamount to address B
Am I right so far? How does the rest go?
2. Buyer deposits BTCamount to address A
3. Seller deposits BTCamount to address B
Am I right so far? How does the rest go?
You're right so far.
The magic is that the buyer and seller exchange the release transactions partially signed to each other.
qwertyoruiop's last idea is to make two addresses instead of three :
Quote from: qwertyoruiop
One is the payment address, the other is the bond address : let it be a multisig one and make it
so the vendor signs a transaction that sends coins back to him and other coins to buyer.
So, buyer gives up his part of the privkey to the vendor, and the payment is settled, then bonds.
Vendor creates a transaction that send half of the bond to him and the other half to the buyer, signs it, doesn't broadcast it but send it over the buyer. Buyer signs it and sends it.
If anyone tries to cheat the system the other party will simply not allow it. This could also let buyer and vendor settle a % refund in case package goes missing.
First address contains payment, second multisig one contains bonds from both the buyer and seller. When buyer releases the payment the seller gets it, but then the seller wants the bond back. But to do it, buyer must sign the transaction. So, seller creates a transaction that gives the buyer bond back to buyer and his bond back to him. Seller signs it, sends to buyer. If buyer agrees with the settlement of bonds, it signs it : bonds are back.
Also lets say that vendor wants to give a % back to buyer because of an error or something, he can specify it and buyer gets it back as part of the bond.
Instead let's say vendor is dishonest and wants more money : buyer sees the settlement and doesn't agree, coin is lost, vendor just got his bond back from the unlocked payment, so both parties are at a loss, and coins can't be spent until they settle.
so the vendor signs a transaction that sends coins back to him and other coins to buyer.
So, buyer gives up his part of the privkey to the vendor, and the payment is settled, then bonds.
Vendor creates a transaction that send half of the bond to him and the other half to the buyer, signs it, doesn't broadcast it but send it over the buyer. Buyer signs it and sends it.
If anyone tries to cheat the system the other party will simply not allow it. This could also let buyer and vendor settle a % refund in case package goes missing.
First address contains payment, second multisig one contains bonds from both the buyer and seller. When buyer releases the payment the seller gets it, but then the seller wants the bond back. But to do it, buyer must sign the transaction. So, seller creates a transaction that gives the buyer bond back to buyer and his bond back to him. Seller signs it, sends to buyer. If buyer agrees with the settlement of bonds, it signs it : bonds are back.
Also lets say that vendor wants to give a % back to buyer because of an error or something, he can specify it and buyer gets it back as part of the bond.
Instead let's say vendor is dishonest and wants more money : buyer sees the settlement and doesn't agree, coin is lost, vendor just got his bond back from the unlocked payment, so both parties are at a loss, and coins can't be spent until they settle.
The fact that bitcoin is deflationary is what I think will incentivize the eventual resolution of aging disputes, because doing it will end up worth ridiculously more to both parties than leaving the coins locked forever (which is still a loss).
Quote
Let's say that you make 3 addresses. Buyer sends the price to first address. Vendor sends price to second address. Buyer sends another time the price to the 3rd address, but makes it so it cannot be spent until vendor gets his share.
And let's say that these addresses's public keys are not known by any party, and then let's say buyer generates 3 private keys and seller generates 3 private keys. They exchange the respective public keys, sum them and mod 256k1 : you now have three addresses that are pretty much dead ends, UNLESS buyer gives seller the first private key.
A has 1 coin
B has 1 coin
C has 1 coin
The user gets his stuff, releases payment by giving his part of the private key to vendor.
(They lock the price up 3 times, only one gets exchange, the only two locked until they exchange keys)
Vendor then will give his part private key for the 3rd address, which can not be spent unless the 2nd address gets withdrawn, and the only way for that to happen is for the buyer to give the vendor his part of the 2nd addr's privkey.
And let's say that these addresses's public keys are not known by any party, and then let's say buyer generates 3 private keys and seller generates 3 private keys. They exchange the respective public keys, sum them and mod 256k1 : you now have three addresses that are pretty much dead ends, UNLESS buyer gives seller the first private key.
A has 1 coin
B has 1 coin
C has 1 coin
The user gets his stuff, releases payment by giving his part of the private key to vendor.
(They lock the price up 3 times, only one gets exchange, the only two locked until they exchange keys)
Vendor then will give his part private key for the 3rd address, which can not be spent unless the 2nd address gets withdrawn, and the only way for that to happen is for the buyer to give the vendor his part of the 2nd addr's privkey.
^This part is key. A non-exploitable way to do 2-party escrow would be a game (theory) changer, and would have broad implications across a lot more media than this particular exchange. I'm not very clear on what you're describing though, could you describe what the 2 parties do, step by step? It sounds like:
1. Buyer and Seller generate 3 keypairs, swapping pubkeys, producing 3 2-of-2 addresses
2. Buyer deposits BTCamount to address A
3. Seller deposits BTCamount to address B
Am I right so far? How does the rest go?
The usual difficulty with 2-of-2 escrow is there end up being opportunities for extortion/griefing when at some point some party can get away with not unlocking the other party's funds...
[reserved just in case]
I'm a member of a group that in the past couple days worked on an implementation of a decentralized, free market. This is not drug aimed like most "free" markets involved with bitcoin. This is to markets what bitcoins is to banks, we believe.
Abstract from in-the-works whitepaper: A decentralized open market would allow online transactions to be done directly from one party to another without going through any central point of failure. Digital currencies, such as bitcoin, provide part of the solution, but they do not eliminate problems such as having a central escrow system that could possibly steal user’s money. We propose a fully distributed market, using Nash equilibrium to provide an equivalent of escrow that does not require any 3rd party. Such a system could rely on existing infrastructure, such as a blockchain-based currency to store data in a distributed fashion.
(pre-pre-pre-draft explanation)
https://ghostbin.com/paste/4k7y6
(original irc log of the discussion)
https://ghostbin.com/paste/oweqm
(reddit discussion)
http://www.reddit.com/r/Bitcoin/comments/1ryf4z/cryptoanarchy_round_two_fully_decentralized_free/
Abstract from in-the-works whitepaper: A decentralized open market would allow online transactions to be done directly from one party to another without going through any central point of failure. Digital currencies, such as bitcoin, provide part of the solution, but they do not eliminate problems such as having a central escrow system that could possibly steal user’s money. We propose a fully distributed market, using Nash equilibrium to provide an equivalent of escrow that does not require any 3rd party. Such a system could rely on existing infrastructure, such as a blockchain-based currency to store data in a distributed fashion.
(pre-pre-pre-draft explanation)
https://ghostbin.com/paste/4k7y6
(original irc log of the discussion)
https://ghostbin.com/paste/oweqm
(reddit discussion)
http://www.reddit.com/r/Bitcoin/comments/1ryf4z/cryptoanarchy_round_two_fully_decentralized_free/
Jump to: