Home » Articles » Fee: A Decentralized Feedback System For Anonymous Markets

Fee: A Decentralized Feedback System For Anonymous Markets

This is an interesting thread we found on Reddit few days ago offering a method of a  decentralized feedback system for anonymous markets to help reduce scamming across the marketplaces. We wondered why this thread is not getting any attention, since these type of ideas are important for the future developments of the DarknetMarkets Community, so we decided to repost it and add links to some similar ideas that were offered and see if it can get some more attention.

You can read the OP here: http://www.reddit.com/r/DarkNetMarkets/comments/1yt1ay/a_paper_on_decentralized_anonymous_open_markets/
PDF Version: http://s000.tinyupload.com/?file_id=04828621585436522849
Related idea: http://www.reddit.com/r/Bitcoin/comments/1ryf4z/cryptoanarchy_round_two_fully_decentralized_free/
Draft Paper: https://docs.google.com/document/d/1MCBzzP6YHp92B_W3qjcUMKx9zECrz7tTH96rbQrG5a4/edit#

All the credit for this paper goes to reddit userThrasybulus
Email: [email protected]

Abstract. We have seen that centralized anonymous markets are no longer an option. Therefore we try to devise a possible system for determining trustworthiness in an open decentralized anonymous market by making use of proof of burn and the interwovenness of customers and vendors in combination with existing technologies like Bitcoin. The goal of this paper is not necessarily to offer a definitive answer to all problems encountered in anonymous trade, but more to set the tone for further development in this young and amazing movement.

1. Overview
After the fall of the anonymous marketplace Silkroad and the plenty of fraudulent clones that sprout after it, we can conclude that the future of anonymous open trade will not be with the centralized markets that exist today. They are too prone to theft and are easily taken offline by law enforcement. Therefore we propose a distributed market that separates the logical parts: listings, messaging, payment and feedback. This paper is only concerned with the most vital and difficult part of the market: the decentralized feedback system, which will be implemented using a variety of techniques, including proof of burn, interweaving and a Bitcoin like approach to reach common consensus. The crypto-currency we will use in our system is Bitcoin, but this can be any other stable crypto-currency, such as Litecoin.

2. Using proof of burn and interweaving to discourage scammers
The first difficulty with implementing a decentralized feedback system is that there is no central authority evaluating the feedback. A market that is concerned with possibly millions of dollars will of course attract attention of dishonest individuals, to which we will refer as scammers. Without any restrictions these scammers could generate large amounts of unfair feedback, luring and abusing honest customers, resulting in a loss of trustworthiness and finally the death of the entire network. To combat this without a central authority, we need to devise a way to make it too costly for a scammer to generate unfair feedback, while keeping trade affordable for the honest customers and vendors.

The first and obvious way of achieving this is to impose a mandatory transaction fee of a few percent to verify the feedback. This method is also used by centralized markets, but because we are discussing a decentralized system, without owner, we have to adjust it somewhat. One approach is to just „burn. the fee by creating a verifiable unspendable transaction, known as proof of burn, but this is wasteful and unnecessary. We will show later in this paper that we in fact need this money to create a stable framework for our feedback

system. It may also be a good idea to donate a small part of the fees to the developers in the early stages of Fee, to stimulate bug hunting and maintenance work, perhaps through a public bounty reward system.

But using proof of burn is not enough to deter scammers. Of course we would base our feedback on the amount of fee involved and not on the amount of transactions, but in a large volume market the loss of building reputation could be recovered by the scammer from malicious transactions, before the feedback of the honest customer hits in. Furthermore, if planned carefully, a scammer could make a profit doing this. One of our main objectives is to have the ability to distinguish between honest feedback and scammer generated feedback.

One solution to this problem (albeit far from perfect, much more research and review is needed) is interweaving, which makes use of the different purchase pattern of honest customers. Interweaving basically uses the fact that honest customers are more likely to buy from more different vendors rather than from one specific vendor (this is not necessarily true, but we are talking about likeliness. This buying pattern should also be recommended by the community to guarantee the functioning of the system) and therefore we can validate feedback more accurately. The interwovenness of a vendor can be calculated by counting the amount of different vendors with whom the clients of the vendor have done business with for a minimum amount of money. Thus aside from the amount of fees involved, interwovenness should be a factor in determining a vendor.s trustworthiness (rating).

To prevent one from making dozens of vendor accounts and earning a lot of reputation for fake interwovenness, an initial (high) registration fee must also be paid. This fee will be feasible (as it is a one-time fee) for an honest vendor, but will be impracticable for a scammer trying to fake interwovenness. The high registration fee will also deter the unsophisticated small-time scammers.

We will continue by sketching some of the market.s concepts mentioned above in more detail.

3. Vendors, customers, feedback, grants and ratingA vendor is an individual (or perhaps more individuals) who sells items on the anonymous market. A vendor.s main concern should be his rating, as it is what will determine his trustworthiness and therefore his successfulness. In Fee, a vendor will be represented by an abstract object consisting of the vendor.s public key, an ID (first few bits of public key hash, large enough to be unique), listing address (Tor, I2P or whatever), contact details and short description of his merchandise.

Customers are people who are interested in buying items from vendors, or preferably are already buying. To judge who is trustworthy on this anonymous decentralized network, customers will look at a vendor.s rating. Customers are represented by a public key, an ID and some contact information, like e-mail. They will not need to pay a „getting started. fee, in order to keep the network attractive to new users.

Feedback can be applied to both customer and vendor, but the focus here is to apply it to the vendor (this paper is a sketch, a request for comment, not a fully detailed working implementation). Feedback is represented by the vendor.s public key, a Bitcoin transaction ID (of a confirmed transaction) paying both the item price to the vendor and the fee (these values must be of the correct magnitude, otherwise the feedback will be discarded), a UTC timestamp and the type of feedback (either positive or negative).

Also both customer and vendor need to sign the feedback in order for it to be valid, because otherwise competing vendors could easily kill another vendor.s rating, since negative feedback weights more than positive. The same argument holds for customers, albeit less of an issue, but there can still be trolls, jealous users or people wanting to prevent someone from becoming a competitor, in the case we allowed feedback trade. Note that implementing a functioning signing schema is more difficult than one might first think, since a grant from a vendor to a customer cannot rely on the Bitcoin transaction ID, because when this ID is valid, the transaction has already taken place and is irreversible for the customer.

A possible granting schema can be implemented as follows: a customer requests a grant from a vendor (i.e. requesting permission to do a purchase). If he considers the customer to be trustworthy enough, he responds by sending him a singed message with the customer.s public key, the current block number and a nonce (we do not really need the vendor to keep record of his used nonces, just make sure the nonce is large enough to be never seen again). The current block number will be used by miners later when the feedback is included in a block, to identify and discard feedback using an ancient grant (i.e. when the current block number differs to much from the included signed number), because otherwise these could be collected over time, and to prevent having to search the entire block chain for feedback using the same grant. Then the customer adds the other information needed for feedback object described above and signs it.

The Rating of a vendor (can be applied to both customer and vendor, but we will focus on vendor rating) in Fee is the only sign of his trustworthiness and is determined by taking the amounts of fee involved in combination with his interwovenness. Rating will be represented by an integer type.

4. Distributing network information and obtaining common consensus
We still need, however, to create a stable framework for the distribution of feedback, vendor information and customer information, as well as a way to manage conflicting feedback with different timestamp or type. Especially the possibility of forging a new fake timestamp for a transaction can be abused, as the rating algorithm will use it to let feedback fade away over time.

For the distribution of network information we could use a distributed hash table (DHT), with the vendor’s public key being the index to the vendor’s feedback and information tracker. This would only require vendors to publicly advertise their public key, which is acceptable, but it still does not provide any common consensus over conflicting feedback.

Using Bitcoin technology, however, we can solve both problems. It also has the advantage of being freely available and open source software that can be adapted quickly to our needs. In our modified version of Bitcoin transactions will be replaced by feedback and vendor information. We also do not need coin generation. In order to keep things interestingfor miners and acquire the needed hashing power, we need to offer them a reward: the “burned” fee. There are a couple of pitfalls, however, we need to be aware of when implementing this recycling system.

Suppose the current block is block n, we can then recycle the fee by only accepting feedback in blocks that includes a fee transaction to one of the blocks between n-6-x and n-6 (supposing that blocks buried under 6 other blocks cannot be changed), where x is a small number representing a buffer of blocks, so that feedback can be included before it is rendered invalid. The problem now is that malicious vendors can also start mining without much investment and, when finding a block by luck, outputting large amounts of free fake feedback while still in the range of x, thus recycling their generated fee.

This can be partly prevented by having a large buffer of size b, which is not moved continuously, but stepwise. Also, instead of letting the customers decide who to pay the fee to in the buffer, they have to pay everyone an equal amount of the fee. If the buffer is largeenough (cannot be any size, because we have to deal with the restrictions of Bitcoin transaction sizes) then the vendor cannot easily recycle his own fees without losing most of it, because the odds of mining a specific percentage of the buffered blocks decreases with larger size, when hashing power remains constant.

We still need to prevent the invalidation of feedback sent right before buffer advancement. This could be accomplished by restricting users to send their feedback only right after advancement, but this is a bad choice, because people would have to be online at that particular moment. A better strategy is to place the buffer at least at a distance b+6 before the head of the chain and to pay the fee to the next buffer. This would only require nodes to maintain a pool of to-be-included feedback. The first blocks would have to be mined without including feedback of course.

We Would love to hear your comment about this idea!

Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS

2 comments

  1. hm, this idea must be implemented by someone who is trusted, even making website like hub forum or decentralized feedback, can bring in danger people who buy and sell drugs. remember freedom hosting schema of cops to catch visitors, they can use similar schema with php code at Hub or this feedback site. they can download malware to our computers even when we just click register button. therefore any site that collect many users (and proof about their activities) must be created only by trusted person (backopy and similar).

  2. hm, this idea must be implemented by someone who is trusted, even making website like hub forum or decentralized feedback, can bring in danger people who buy and sell drugs. remember freedom hosting schema of cops to catch visitors, they can use similar schema with php code at Hub or this feedback site. they can download malware to our computers even when we just click register button. therefore any site that collect many users (and proof about their activities) must be created only by trusted person (backopy and similar).
    By the way, I am not sure but I think even deepdotweb is behind CloudFlare, NSA shit that collect information about visitors. therefore use proxy or tor when you visit deepdotweb.
    Venrock & Union Square Ventures financed CloudFlare with 50M & Venrock is in possession of Rockfeller family that surely don’t resist to the government than work together with FBI. CloudFlare monitor, observe and scrutinize all of your site’s traffic, it means they monitor visitors of deepdotweb. They cache websites and give it to you through their servers, they even edit content for specific visitors. 13% if internet users pass through cloudflare network at least one time per month.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">