JoinMarket-Org / joinmarket

CoinJoin implementation with incentive structure to convince people to take part
398 stars 119 forks source link

Internal reviewing of makers. #57

Open chris-belcher opened 9 years ago

chris-belcher commented 9 years ago

Imagine if after every coinjoin, the taker calculated a measure related to how 'good' the coinjoin was. This would take into account the response time, whether the connection dropped halfway through and some other things.

When the taker then went to choose again who to coinjoin with, it would take this measure into account along with the offered price. This measure could be called 'rating' or 'reputation' or a word to that effect. Takers which use the market a lot would build up a detailed ranking of makers.

Makers would now have an incentive to have a low-latency reliable internet. Slower than average responding to requests, or connections cutting out, would reduce the maker's income. It should help solve Mike Hearn's user experience criticism of CoinJoin from his Merge Avoidance blog post. People operating coinjoins from a flaky network should be gradually forced from the market.

Problem: This creates a disincentive for using tor by makers. Solution is that tor yield generators will simply have to offer lower prices.

Also it could be an incentive for yield generators to use Bitcoin Core's json_rpc interface instead of a blockchain explorer like blockr.io, solving Issue https://github.com/chris-belcher/joinmarket/issues/55 Because it's faster to look up txID's from your hard disk or chainstate than to download them from a website.

Also it could act as a barrier to DOS'ing against the taker.

There would need to be some time decay element involved in the measure, to give makers second chances and slowly forgive their past mistakes. Also an increase in reputation by time, to encourage makers which are permanently around.

Reputations would be associated with the IRC or subspace nickname. If a yield-generator ended up with such a bad reputation they could change nicks although they would again start from zero, far behind others who may have built up long reputations.

chris-belcher commented 9 years ago

In coinjoins with multiple makers, must take into account the fact that tcp/ip is a queue of data.

Meaning in the naive implementation, if one maker sends in data and takes a long time, all the makers that send data after him will appear to take a long time too.

chris-belcher commented 8 years ago

Problem: This creates a disincentive for using tor by makers.

This could be solved by quantizing times, same as quanizing prices as in https://github.com/chris-belcher/joinmarket/issues/14#issuecomment-143509788

In other words, penalties only start after 2-3 seconds.

inaltoasinistra commented 8 years ago

Where the reputation information can be stored? How is it possible to verify that the information is correct?

chris-belcher commented 8 years ago

Each user would store the information locally and only would trust themselves.