Skip to content
This repository has been archived by the owner on May 13, 2022. It is now read-only.

Internal reviewing of makers. #57

Open
chris-belcher opened this issue Mar 17, 2015 · 4 comments
Open

Internal reviewing of makers. #57

chris-belcher opened this issue Mar 17, 2015 · 4 comments

Comments

@chris-belcher
Copy link
Collaborator

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 chris-belcher changed the title Internal reviewing / of makers. Internal reviewing of makers. Mar 25, 2015
@chris-belcher
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Contributor

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

@chris-belcher
Copy link
Collaborator Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants