Internal reviewing of makers.

[chris-belcher]

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 #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]

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]

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

This could be solved by quantizing times, same as quanizing prices as in #14 (comment)

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

[inaltoasinistra]

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

[chris-belcher]

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