decentralized-anonymous-marketplace-concept
decentralized-anonymous-marketplace-concept copied to clipboard
goshacmd
Transaction Tracking
There is one problem which has not been addressed in the concept: it is possible to track transactions between bitcoin wallets, making the fact of the establishment of a link between a buyer and a seller visible to the world.
Silk Road had a "Tumbler" System in place to make this link virtually invisible... what is your suggested way to fix this?
The people on HN suggest looking into Zerocoin.
I am not entirely sure that there is a way to implement contracts with it though.
I see no reason why BTC escrow services couldn't arise. They'd receive the BTC, put it through a hopper that provided anonymization, and wait for the transaction to be approved by two parties before sending the final amount (minus a small fee) to the seller. They'd have a reputation system similar to the buyers and sellers.
The key here is that the escrow service is general-purpose and otherwise ignorant of the transaction. They'd have to be fully decoupled from the arbitrator.
There's 5 roles, as I see it. The more decoupled each of these gets from each other, the better: Seller, Buyer, Marketplace, Escrow, Arbitrator. Each would have their own reputation, the latter three would collect nominal fees on every transaction they service.
@subwindow haven't we seen that depositing your money to a third party, even a trust-worthy one, is dangerous because of presence of other violent parties that might intimidate escrow? It opens up the possibility to someone other than buyer or seller of getting hold of the coins.
As a probable solution, buyers might manually create a new wallet specifically for this transaction and put the money through to hopper from their primary wallet to this one-time one, and then use it to pay.
Sellers too might have multiple wallets that they are receiving money on (having multiple "primary" wallets makes it a bit harder to follow the money), or, if we suppose that every seller runs their own marketplace, their marketplace instance can be generating one-time wallets for the orders (since it is fully in their control, there would probably be no issue with the software generating wallets for them and forwarding money to their primary wallet through tumblers).
Those sound as a bit more difficult solutions and would probably require more interaction to complete the order, but it least it assures that nobody but the original sender or recipient can use the money. Which is kinda the idea behind DAM.
haven't we seen that depositing your money to a third party, even a trust-worthy one, is dangerous because of presence of other violent parties that might intimidate escrow? It opens up the possibility to someone other than buyer or seller of getting hold of the coins.
This is why there should be many escrow services, each with a reputation. If a transaction is large enough to make the escrow service a target of violence, it should be split up. Perhaps that would be an eventual feature of the system.
if we suppose that every seller runs their own marketplace
That's certainly an achievable goal. The only problem then would be distributing reputation amongst the nodes, which is a solvable problem with prior art. I see no reason, however, to couple them together in the architecture.
Certainly, the seller and marketplace could be the same actor, and escrow and arbitration are optional. Therefore, if both parties agreed, it could be a strictly two-party transaction. However, for those instances when either party wants extra transactional insurance, the framework could theoretically be capable of supporting it.
This is why there should be many escrow services, each with a reputation. If a transaction is large enough to make the escrow service a target of violence, it should be split up. Perhaps that would be an eventual feature of the system.
As you probably may know, reputation had nothing to with a recent hit, and it's by no means a way to prevent further attacks on the marketplaces.
It is not the specific transaction size that does matter. It's the volume. And the fact that the money doesn't immediately go through (like a tumbler), but rather sits there for indefinite amount of time. Even assuming there will be more than one escrow, their volumes each won't probably be very small, so that potentially makes them a target.
Trust and probability of intimidation shouldn't probably be the motives to rely on an optional third party. Mathematical model should. (I.e. scripts in transactions.)
Just because it helps you stay more anonymous, it does not mean that such a risk should be taken, I think.
If there were an easy way to do this programmatically, I would totally agree that would be a preferable solution.
The idea behind real-entity escrows is that they would be compensated for the risk that they would be taking on. In addition, I see no reason why these escrows would be more of a target than any other institution that holds a large amount of money.
I suppose, if you care more about the decentralization and less about the anonymity, this is not really an issue.
It is pseudo-anonymous. We all know that "jackDaniels" paid "ganjaQueen" 30 coins, but still there is no way to tell the real identities behind those usernames.
See mixcoin concept as presented at fincrypto14
(( http://www.jbonneau.com/doc/BNMCK14-FC-mixcoin.pdf ))
for some additional ideas relative to anonymity.
See the Accountability section on page 2 of mixcoin paper: it's relevant in some respects to this Transaction Tracking issue for decentralized-anonymous-marketplace-concept.
See also (mixcoin paper) sections 4, 7.2, and 7.5 in particular.
