Weekly Development Update, October 21, 2015

Last week

Back end

Began work on OSX installer. Fixed a number of bugs in the order flow and finalized moderated orders. Continued work on direct transactions.

Second reputation article posted.

Front end

Made updates to how local data is stored, enhanced validation, added a fallback to the local server if the user adds a server that can’t be reached, made external links open in a new browser, fixed many bugs in the item editor and improved handling of different currencies.

Improved documentation for front end:

1. Order states
2. Order discussions and disputes
3. Order funds tab

Other

The Spells of Genesis game released an OpenBazaar card today!

OBSOGcard

Read More

Decentralized Reputation – Part 2

In part 1, we introduced the reputation system for OpenBazaar.

We learned that Vendor or Moderator reputation is composed of individual transaction ratings. Transaction ratings feed into a reputation score, with granular detail related to their activity as either a Vendor or Moderator. Transaction ratings are tied to a bitcoin transaction and recorded as a JSON-formatted transaction summary of the trade.

Tx summary

Transaction summaries contain the minimum amount of metadata required to provably link a Vendor to a bitcoin transaction and listing contract, while maintaining the privacy of the Buyer by default.

Users that desire to know the reputation of a Vendor can download the full history of transaction summaries directly from the Vendor or a third party (e.g. Moderator).

Towards the end of the article, I hinted that third parties could take the transaction summaries as ‘units of reputation data’ to calculate their own version of a reputation score, which would be different from OpenBazaar’s native algorithm.

In this article we will explore these concepts in greater detail, and unpack how transaction summaries can be processed to add value to reputation score in OpenBazaar.

Cost of Identity

A frequent obstacle in any system where reputation is involved is the threat of Sybil attacks.

In a Sybil attack the attacker subverts the reputation system of a peer-to-peer network by creating a large number of pseudonymous identities, using them to gain a disproportionately large influence. A reputation system’s vulnerability to a Sybil attack depends on how cheaply identities can be generated, the degree to which the reputation system accepts inputs from entities that do not have a chain of trust linking them to a trusted entity, and whether the reputation system treats all entities identically. (Source)

Previously we described the first-line of defense against Sybil attack in OpenBazaar, which was the proof-of-work required to generate a global unique identifier (GUID) for the network. Using non-specialized hardware, generating a GUID will take approximately 30 seconds. However, given the prevalence of a specialized hardware related to various proof-of-work systems, we cannot exclusively depend on this approach to impose a cost per identity.

A financial cost can be associated with an OpenBazaar GUID to help combat Sybil attacks and enhance the value of a reputation score (when the GUID of the Buyer is disclosed in the transaction summary).

Like a proof of work, a financial cost for a GUID means that contributing data to the network, in the form of ratings and reviews, is not free. This cost or reputation pledge, at some point, makes it economically irrational to create fake identities and thus fake ratings.

There are a variety of ways to make a reputation pledge:

  1. Proof of burn
  2. CHECKLOCKTIMEVERIFY
  3. Security deposit

We will briefly touch on each approach below with an example of a market price of $5 (~0.02 BTC at the time of writing) for a reputation pledge.

Proof of Burn

Proof of burn involves sending bitcoin to an address where the private key will be virtually impossible to calculate. The funds sent to this address are permanently unspendable and represent the purest form of commitment. Nevertheless, for many (including the author) there is an unsettling emotional cost, despite the net economic benefit it gives to all users.

For example, an attacking Vendor would need to burn $100 (0.4 BTC) to create 20 reputation pledges for each fake identity making a positive rating. However, the $100 burn only represents the present cost to creating these identities. There is a future cost, in terms of deflationary value, in losing 0.4 BTC that may be worth significantly more than $100 months or years from now.

In terms of implementation, OpenBazaar may support this feature, but would be unsurprised if few use it in favor over other alternatives.

CHECKLOCKTIMEVERIFY

CHECKLOCKTIMEVERIFY would have a user send bitcoin to themselves (i.e. another address that the user controls) in such a way that these funds would be ‘unspendable’ until a future date. The funds in this type of transaction will not be accepted into a block until a specific Unix time or block height.

Unlike proof of burn, the $100 reputation pledge would not be permanently lost but temporarily inaccessible to a Vendor. The time period may be anywhere from weeks, months, or even years.

This approach isn’t particularly effective against attackers with a long time preference, but should be sufficient for most users when the value of items being traded are less than the locked funds.

Security Deposit

A third party, or federation of third parties, hold a sum of funds from a user in multisignature escrow for a period of time as a security deposit. In the event of poor behavior by the user in a transaction or interaction, damages can be deducted from the security deposit to: 1) compensate the offended party, or 2) impose a punitive action.

The weakness of this approach is that the user must trust the third party, and the rest of the network must value the integrity of the third party. While certainly not ideal from a pure decentralist, zero-trust point of view, this service may emerge as a popular choice if reputable players enter this market.

Counting the Cost

Irrespective of the approach used to make a reputation pledge, we can arrive at an estimate of the total cost of a Sybil attack for the overall reputation score of a Vendor or Moderator. This is calculated by:

  1. Assuming all users that contributed to the reputation score are sockpuppets
  2. Summing the reputation pledges of each identity.
Assuming each identity is secretly created by Alice, it would have cost her $100 in reputation pledges.
Assuming each identity is secretly created by Alice, it would have cost her $100 in reputation pledges.

The Sybil cost represents the maximum amount Alice would have paid to create a 100% fake reputation score; the actual cost may be lower if other users have legitimately rated her positively. Ancillary costs involved in a Sybil attack are not included in this estimate, only the reputation pledge values for each identity.

Users can have some assurance when dealing with a counterparty that has a Sybil cost larger than the value to be traded. For example, if Fred wanted to sell a music track to Alice for $3, it is economically irrational for Alice to spend $100 to defraud Bob out of a $3 item. If the value of the item was $1000, then Bob would need to carefully consider his counterparty risk if Alice’s Sybil cost is only $100.

While seemingly complex, this economic reputation calculation exists in TaoBao, where Vendors put up security deposits in exchange for a badge to solicit trust from potential Buyers. The larger the security deposit, the more likely Buyers will feel safer transacting with the Vendor.

Transaction Summaries

The aggregate history of transaction summaries of a user is the data-set to calculate the reputation score. However, transaction summaries can be excluded from the calculation based on certain criteria. The purpose of this is to enhance the value of a reputation score to more accurately predict the integrity of a user in future trades.

The 3 Seashells

One approach is to break up the reputation score, of the Vendor or Moderator, into 3 classes or the ‘3 seashells’.

The 3 Seashells… yes I’m a fan of Demolition Man
The 3 Seashells… yes I’m a fan of Demolition Man

Seashell 1: All (red; low reliability)

The reputation score is calculated from all transaction summaries that can be found on the network for a Vendor or Moderator. The GUID of the Buyer does not need to be disclosed. Equal weight is assigned to all transaction summaries on the assumption they are all from authentic trades.

All transaction summaries are counted, even if the Buyer’s GUID isn’t not disclosed.
All transaction summaries are counted, even if the Buyer’s GUID isn’t not disclosed.

If Buyer’s GUID is undisclosed, they are represented by the Bitcoin address (and signature) from the payout transaction from multisignature escrow address or input address in a direct transaction.

Seashell 2: Public (yellow: some reliability)

The reputation score is calculated from transaction summaries where the GUID of the Buyer is disclosed. Any transaction summaries where the Buyer is only represented by a Bitcoin address (i.e. an anonymous transaction) are discarded.

Transaction summaries without the Buyer GUID disclosed are discarded.
Transaction summaries without the Buyer GUID disclosed are discarded.

The assumption here is that the requirement of the Buyer’s GUID subjects the rating to:

  1. A minimum proof-of-work to create an OpenBazaar identity
  2. Transparency on the network
  3. An association of a GUID with a bitcoin transaction; coin analysis can be performed

Seashell 3: Web-of-Trust (green: excellent reliability)

The reputation score is calculated from transaction summaries where theBuyer’s GUID is within the user’s web-of-trust graph (WoT).

If Alice is the target and Ed is the observer, only the transaction summaries in Ed’s web-of-trust are accepted when calculating Alice’s reputation score.
If Alice is the target and Ed is the observer, only the transaction summaries in Ed’s web-of-trust are accepted when calculating Alice’s reputation score.

The assumption here is that you are more likely to believe ratings made by people you trust compared to pseudonymous or random identities on the network.

Web-of-Trust

There are several WoT architectures to choose from. In OpenBazaar, the WoT can be as simple as a graph of nodes that the user follows. Alternatively, there are more complex proposals that we will briefly touch on below.

Web-of-trust #1: Zindros

Zindros web-of-trust
Zindros web-of-trust

This approach was named after OpenBazaar core contributor Dionysis Zindros, who wrote up a comprehensive specification outlined here.

The Zindros WoT uses proof-of-burn to introduce a cost to create an identity. Only partial knowledge of the whole web-of-trust graph is known by any one user.

To calculate the reputation score of a target node Bob (in context of transaction summaries used in OpenBazaar), Alice queries her friends (i.e. nodes within her WoT) to return:

  1. Transaction summaries of Bob
  2. Transaction summaries of Bob that their friends and friends-of-friends (up to n degrees of freedom) may have

The overall reputation score would be calculated based transaction ratings weighted based on the proximity of the target (Bob) to Alice’s friends in her WoT.

Web-of-trust #2: Line of Credit

This designs differs from traditional web-of-trust designs in that is uses a Bitcoin line of credit as the trust edges (i.e. the connections between nodes) rather than esoteric ratings, vouches, or points. If a user on the network has large and multiple lines of credit from other nodes, then this would be a quantifiable financial indicator of trust.

The line-of-credit (LoC) may either be a 1-of-2 (high liquidity, high trust) or 2-of-2 (low liquidity, low trust) escrow address where funds are deposited between two nodes. If Alice is added to Bob’s WoT, Bob would deposit bitcoin in a 1-of-2 escrow address that Alice can draw from at any time for any purpose.

Trust is measured by the total amount of credit a user can draw from other users on the network.
Trust is measured by the total amount of credit a user can draw from other users on the network.

The OpenBazaar application would keep track of funds borrowed, interest levels, repayment schedules etc, which would contribute to more public metadata to assess the trustworthiness of a user. Users are incentivized to open a line of credit to a reputable Vendor, who is likely to earn them interest.

One advantage of this approach is that it simultaneously requires a cost for each identity to establish trust, creating a financial disincentive for Sybil attacks.

Some variations of this idea may be extended to bi-directional micropayment channels to be used in the lightning network.

Filters

In addition to the three major classes above, transaction summaries can be filtered according various parameters to calculate the reputation score.

Blockchain ID

Only transaction summaries with a disclosed GUID and a Blockchain ID are included in the reputation score calculation. Furthermore, transaction ratings may be weighted based on the number of external verified accounts associated with a Blockchain ID (i.e. Facebook, Twitter, PGP etc). This approach would attempt to favor transaction ratings from verifiable real world identities rather than anonymous or purely pseudonymous users.

Coin Analysis

Each transaction summary is tied to bitcoin transaction where funds are released to the Vendor as a result of a successful OpenBazaar trade. This transaction can be analysed in conjunction with other transactions associated with the user to assess the likelihood the same coins were used for both transactions.

If the same coins were used, then there is a high chance that the user is attempting to fake a rating, and the associated transaction summary with the rating data can be discarded from calculating the reputation score (in addition to any punitive measures).

This filter may become less effective as tools such as JoinMarket and confidential transactions are deployed.

Reputation Score Algorithm

Irrespective of what pool of transaction summaries will be sampled for ratings, users or items will need to be sorted from most reputable to least reputable. The reputation score can be a contentious issue, but there are several factors to consider when selecting a reputation score algorithm. These factors are reviewed in this excellent article, and a slightly easier to understand version here.

In short, OpenBazaar will use the lower bound of the Wilson score confidence interval, for a Bernoulli parameter, calculate the reputation score of a user. Incidentally, Reddit also uses this approach to rank stories.

Third party services can collect transaction summaries, filter, and experiment with alternative algorithms to calculate the reputation score of a user.

Conclusion

Transaction summaries are units of reputation data in OpenBazaar. This data can be parsed in a variety of ways to either enhance the reputation score or form an alternative reputation score that is more relevant to a subset of users. Thus, OpenBazaar is a platform for developing decentralized reputation systems as well as for marketplaces.

While most of these ideas will not be implemented in time for our upcoming release, they may serve as a foundation/inspiration for new contributors and/or third party developers to build on the reputation platform.

Acknowledgements

Read More

Weekly Development Update, October 14th, 2015

Last week

Back end

Many bug fixes. Payout tx work. Continued work on Windows installer.

Published reputation article to community for feedback on our current approach.

Front end

Store wizard is complete aside from moderator assignment, major updates to the user page design have been integrated, and many user page editing controls have been improved.

Created documentation for both the notifications and the trade flow UI.

Read More

Decentralized Reputation in OpenBazaar

Decentralized reputation small

Decentralized reputation is one of the most sought after prizes in the cypherpunk community: to invent a censorship-resistant protocol to make and parse unforgeable trust relationships between pseudonymous identities.

The problem is that trust and reputation are both abstract concepts that aggregate the subjective value judgements of unrelated experiences between people. Fundamentally, trust and reputation are highly contextual, and merely attributing a number or karma points to ascertain the overall trustworthiness of an identity is not very informative or useful.

OpenBazaar’s reputation system is granular and contextual to trade that takes place within the network.

  • Granular in that ratings are made according to multiple criteria evaluating different components of an e-commerce transaction
  • Contextual in that ratings are made on a per-transaction basis, rather than goodwill points

The reputation of a user is the weighted-average of their transaction ratings. In summary, you cannot make a rating without showing evidence of a transaction over OpenBazaar.

While we earlier explored the web of trust (WoT) model, the system described in this article is not a web of trust. OpenBazaar’s reputation system is similar to eBay and Taobao in that it is transaction-based. Where necessary, we have made some improvements that are described below.

To get a sense of how the reputation system works, we must examine the following components in the OpenBazaar protocol:

  1. Identity
  2. Ricardian Contracts and the Trade Flow
  3. Ratings and Reviews
  4. Reputation Score

This article is adapted from slides we published earlier.

 

Identity

Any reputation system begins with a network of identities. In OpenBazaar, these identities are pseudonymous, which is to say that they are not inherently tied to your real world identity.

The OpenBazaar network uses a Kademlia-style distributed hash table (DHT) to connect peers, similar to BitTorrent. Public key cryptography is used to generate a global unique identifier (GUID), which represents a pseudonymous node on the network.

The GUID is a key that multiple values can be attributed to (e.g. an IP address and port). The key remains immutable (unchangeable) while the value is mutable (changeable). For example, Alice’s GUID on the OpenBazaar network remains constant even though her IP address/port changes depending on whether she connects to the network from home or work.

1 GUID = 1 node on OpenBazaar

In OpenBazaar, a large random number (2^256) is initially generated, which is the private key of the GUID keypair. A corresponding public key is generated from the private key. The GUID is generated using a proof-of-work scheme to introduce computational difficulty in generating identities, to mitigate against a variety of sock-puppet attacks. With the target difficulty, GUID generation should take approximately 30 seconds.

GUID = first 20 bytes of SHA256(self-signed public key), where the last 32 bytes < a difficulty target

OpenBazaar uses Ed25519 for digital signatures.

The GUID keys are used for:

  1. Authenticating network messages between peers
    • GUID keys used for initial authentication
    • Ephemeral key pair generated to encrypt subsequent messages between peers for forward secrecy
  2. Digitally signing Ricardian contracts
    • Digital agreements on the subject and terms of trade
  3. Generate a hierarchical deterministic (HD) keychain for multisignature transactions
    1. HD master private key = SHA256(GUID private key)

 

The GUID is the network identity of OpenBazaar

The GUID is long, complex, and prohibitively difficult for people to remember. Fortunately, we have added option support for Onename’s Blockchain ID to register an OpenBazaar GUID to a memorable handle (e.g. @drwasho).

A Blockchain ID can also be associated with other real world and digital identities such as Facebook, Twitter, Github, or your PGP keys. This allows users to leverage their real world identities to build initial trust connections for trade. Alternatively, a user can not associate any real world identity with their Blockchain ID to preserve a purely pseudonymous identity.

If a user registers their OpenBazaar GUID to a Blockchain ID handle, you will be able to search for that identity by that handle in the application.

Future features include ‘sub-domain’ namespaces that can link to the same root identity, but map to different OpenBazaar GUIDs. Similarly, a user can acquire multiple handles that map to the same OpenBazaar GUID.

As an OpenBazaar identity is based on the generation of a cryptographic keypair, rather than divulging personally identifiable information, the user ultimately retains control over their privacy and can choose the level of association with their real world identity. Upon this foundation of identity we can begin to construct reputation based on transaction ratings.

 

Ricardian Contracts & the Trade Flow

Ricardian contracts are simply digital documents that define the terms and conditions of an interaction, between two or more peers, which is cryptographically signed and verified. It is a tamper-proof contract that is formatted in XML or JSON and designed to be both human and machine readable.

Ricardian contract have the following components:

  1. Cryptographic keys to establish identity
  2. Semantic data to establish the terms and conditions of an interaction (e.g. money exchanged for a good/service)
  3. Digital signatures to create fraud-proof evidence that an identity agreed to these terms and conditions
  4. Cryptographic hash of the contract, as a reference identifier, to create a tamper-proof record of the contract

OpenBazaar extends the utility of the Ricardian contract, originally designed by the eminent Ian Grigg, to act as a ledger of the transaction or trade flow between the contracting parties. The final version of the Ricardian contract, with a completed and digitally signed record of the execution of the contract, is called a trade receipt. The data within the contract is signed with the GUID keys of the participants.

OpenBazaar’s Ricardian contract schema for physical items:

 

 

The contract itself is broken up into the 4 stages of the trade flow:

Stage 1: Listing/Vendor Offer

  • The Vendor lists what is for sale (physical item, digital content, services etc)
  • There are some prior steps regarding Moderator selection that won’t be elaborated on in this article

Stage 2: Buyer Order

  • The Buyer sends an order to the Vendor
  • The Vendor acknowledges the order, sending a digital signature that will serve as a Vendor authentication of the order (prevents attackers from making fake ratings of the Vendor)
  • Buyer funds the multisignature escrow address
  • Order processing time begins: ~1-3 days to ship the item

Stage 3: Vendor Order Confirmation

  • The Vendor confirms to the Buyer that the order has been processed and the item has been shipped
  • Gives the Buyer any shipping related data, for physical goods
  • Gives the Buyer a download address and password, for digital content
  • Gives the Buyer any relevant data to perform the service
  • Sends partially signed transaction releasing funds from the multisignature escrow address to the Vendor (still requires Buyer to sign after receiving the item)

Stage 4: Buyer Receipt

  • Buyer acknowledges that the item, content, or service was delivered/performed
  • Signs a transaction releasing funds from multisignature escrow
  • Makes a rating and review of the Vendor, sends the transaction summary to the Vendor and Moderator for storage

There is more detail to each of these stages, but for the purpose of this article we’ll move on.

 

Ratings and Reviews

Initially, OpenBazaar will support ratings for Vendors (including the product/service they sell) and Moderators, who play a crucial role in the trust infrastructure of the network.

We expect that in the early days of OpenBazaar’s release, Moderators will need to leverage their external reputation to gain trust from users on the network. This represents a unique opportunity for groups such as BitRated to extend their services into a decentralized markeplace.

Rating a Vendor

As mentioned earlier, the rating model for Vendors is comparable to eBay and TaoBao, and thus leverages the user experience most e-commerce users are familiar with.

Vendors will be rated in 5 categories:

  1. Feedback rating
  2. Item/content/service quality
  3. Item/content/service listing description
  4. Item/content/service delivery
  5. Customer service

Each rating criteria will be rated out of 5 stars.

Unlike eBay and TaoBao though, the meaning of these stars are not left open to subjective interpretation, but reflect an objective assessment criteria in order to more accurately standardize Buyer ratings.

In addition to these ratings, the Buyer can also write a text review of the transaction.

Feedback Rating

What was the overall feedback when purchasing the product from the Vendor?
  • 5 stars = I would do business with them again without hesitation.
  • 4 stars = I will probably to do business with them again.
  • 3 stars = I would only do business with them if I couldn’t find anyone else.
  • 2 stars = I will not do business with them again.
  • 1 star = This is a scam, avoid at all costs.

Item/Content/Service Quality

What was the quality of the item, content, or service from the vendor?
  • 5 stars = I would purchase it again and recommend it to others without hesitation.
  • 4 stars = I might purchase it again and recommend it, but I’d still look for alternatives first.
  • 3 stars = I would only purchase and recommend it if I couldn’t find anything else like it first.
  • 2 stars = I wouldn’t purchase it again or recommend it.
  • 1 star = It is a scam, avoid this product.

Item/Content/Service Listing Description

How accurate was the listing description of the item, content or service?
  • 5 stars = Perfectly accurate.
  • 4 stars = Mostly accurate.
  • 3 stars = Barely acceptable.
  • 2 stars = Mostly inaccurate.
  • 1 star = 100% false.

Item/Content/Service Delivery

How quickly was the item sent, content accessible, or service performed after ordering?
  • 5 stars = Delivered earlier than the estimated delivery date.
  • 4 stars = Delivered by the estimated delivery date.
  • 3 stars = Delivered <5 days later after the estimated delivery date.
  • 2 stars = Delivered >5 days after the estimated delivery date.
  • 1 star = Never delivered.

Customer Service

How do you rate the quality of the Vendor’s communication?
  • 5 stars = The Vendor kept in contact with me at every stage of the trade. The Vendor answered my questions, clearly and concisely, <12 hours after I asked.
  • 4 stars = The Vendor only contacted me if there was a problem. The Vendor answered my questions, with some clarity, <24 hours after I asked.
  • 3 stars = The Vendor only contacted me after I reached out to them. The Vendor answered some questions, with passable clarity, >24 hours after I asked.
  • 2 stars = The Vendor rarely responded. The Vendor was not clear or understandable.
  • 1 star = The Vendor never communicated.

Text Review

Similar to eBay, written reviews have a size limit of 80 characters.

Making a Rating

Ratings are made in the last stage of the trade flow (see above; Stage 4 Buyer Receipt). When a user receives an item, they need to confirm that the item was received in order to release funds from escrow to the Vendor. During that process, they will be asked to make a rating and write a text review as described above.

While the data is stored within the trade receipt, it isn’t efficient (and doesn’t scale) to download a Vendor’s entire trade receipt history just to extract the rating and review data for that user (or for an item they sell).

Instead of a trade receipt, Vendors will serve transaction summaries that contain the relevant data to validate a transaction and calculate the reputation score.

The schema of a transaction summary is:

{
  "tx_summary" : {
      "vendor" : {
        "guid" : "",
        "pubkey" : ""
      },
      "transaction" : {
        "listing" : "",
        "bitcoin_address" : "",
        "price" : "",
        "buyer_pubkey" : "",
        "moderator_guid" : "",
        "moderator_pubkey" : ""
      },
      "vendor_tx_signature" : "",
      "txid" : "",
      "trade_receipt_hash160" : "",
      "rating" : {
        "feedback": 0,
        "quality" : 0,
        "description" : 0,
        "delivery_time" : 0,
        "customer_service" : 0,
        "review" : ""
      }
  },
  "buyer_signature" : ""
}

One of the most important elements of the transaction summary is the vendor’s signature of the transaction object, which contains the listing hash, bitcoin address, price etc. When the Buyer places the initial order with the Vendor, the Vendor’s client will send a digital signature of the transaction object. This will be a cryptographic proof of the Vendor’s involvement in the trade, which is necessary before any rating is made — otherwise a Vendor could refuse to attribute themselves to a transaction summary with a negative rating.

The rest of data such as transaction ID (txid), the trade receipt hash, the rating and review text is added at the conclusion of the transaction and sent to the Vendor for their records. The transaction summary can also be sent to the Moderator for storage, in case the Vendor omits summaries with negative ratings.

Overall, the transaction summary is a more compact proof of the Vendor and Buyer’s exchange and subsequent rating than the entire trade receipt. Future releases will address the issue of long term storage of transaction summaries and Vendor transparency, potentially with technologies such as Blockstore and/or IPFS.

Rating a Moderator

Rating a Moderator for their service is significantly more complex task. To our knowledge, it is entirely without precedent. Users should expect this area of reputation to evolve as we learn what transpires over the network in the years to come. Below we describe a system we feel comfortable launching and learning from.

The task of Moderation is to pick a winning and losing side from a dispute between two parties (the Vendor and Buyer). Unfortunately, the rating of a Moderator will be heavily biased depending on whether the user has won or lost the dispute.

In other words, if the Moderator decides that you are the winner in a dispute, you are more likely to rate the Moderator positively for their ‘wise and noble decision’. The opposite is true if you are on the losing side.

As a result, OpenBazaar must show the rating/review — for each disputed transaction — from both sides. The goal is to highlight any potential agreement between the winner/loser in the rating criteria.

Moderators will be rated in 4 categories:

  1. Feedback Rating
  2. Dispute Resolution Listing Description
  3. Resolution Time
  4. Customer Service

As with Vendors, each rating criteria will be rated out of 5 stars. Each star has an objective meaning that will be displayed to the user. Users can also submit a text review of the Moderator.

Feedback Rating

What was the overall feedback to the Moderator?
  • 5 stars = I would choose them again without hesitation.
  • 4 stars = I will probably do business with them again.
  • 3 stars = I would only do business with them if I couldn’t find anyone better.
  • 2 stars = I will not do business with them again.
  • 1 star = This is a scam, avoid at all costs.

Dispute resolution listing description

How accurate was the Moderator's dispute resolution description service?
  • 5 stars = Perfectly.
  • 4 stars = Mostly accurate.
  • 3 stars = Barely acceptable.
  • 2 stars = Mostly inaccurate.
  • 1 star = 100% false.

Dispute resolution time

How quickly was the dispute resolved by the Moderator?
  • 5 stars = Resolved earlier than the estimated time.
  • 4 stars = Resolved earlier the estimated time.
  • 3 stars = Resolved <5 days later after the estimated time.
  • 2 stars = Delivered >5 days after the estimated time.
  • 1 star = Never delivered.

Customer Service

How do you rate the quality of the Moderator’s communication?
  • 5 stars = The Moderator kept in contact with me and answered my questions, clearly and concisely, <12 hours after I asked.
  • 4 stars = The Moderator only contacted me if they had a specific question/resquest from me. The Moderator answered my questions, with some clarity, <24 hours after I asked.
  • 3 stars = The Moderator only contacted me after I reached out to them. The Vendor answered some questions, with passable clarity, >24 hours after I asked.
  • 2 stars = The Moderator rarely responded. The Moderator was not clear or understandable.
  • 1 star = The Vendor never communicated.

Text Review

Written reviews have a size limit of 80 characters.

Making a Rating

Broadly speaking, there are 2 classes of dispute that may arise:

  1. The Buyer failing to release funds from escrow
  2. The Buyer being unsatisfied with the contents or delivery of the item

Dispute: The Buyer failing to release funds from escrow

This scenario will be due to the Buyer being incapacitated or forgetting to release funds. If the Buyer fails to respond after a reasonable number of attempts over time, the Moderator will collaborate with the Vendor to release the funds.

This process is initiated by the Vendor, who flags a dispute to the Moderator and Buyer (if online). To flag the dispute, the Vendor sends the dispute claim (with a digital signature) to the Moderator and Buyer:

  1. The hash of the transaction object
  2. Who the claimant is (i.e. the Vendor in this example)
  3. The written claim (80 characters long)

If the Buyer fails to respond to the Moderator, the Moderator will issue their resolution. The resolution, digitally signed by the Moderator, will include:

  1. The hash of the dispute claim
  2. The written resolution outcome and justification (character length to be decided)

The resolution is then sent to both the Vendor and Buyer (if online) and a transaction releasing the funds from escrow to the Vendor is created and signed.

A transaction summary is automatically generated at the end of this process, as described earlier, that also includes the dispute claim, the resolution, and the Moderator review.

Both the Vendor and Moderator will host and serve this transaction summary to other users.

Vendor transaction summary

{
  "tx_summary" : {
      "vendor" : {
        "guid" : "",
        "pubkey" : ""
      },
      "transaction" : {
        "listing" : "",
        "bitcoin_address" : "",
        "price" : "",
        "buyer_pubkey" : "",
        "moderator_guid" : "",
        "moderator_pubkey" : ""
      },
      "vendor_tx_signature" : "",
      "txid" : "",
      "trade_receipt_hash160" : "",
      "dispute" : {
        "transaction_hash160" : "",
        "claimant" : "",
        "claim" : ""
      },
      "claimant_signature" : "",
      "moderator_resolution" : {
        "dispute_hash160" : "",
        "summary" : ""
      },
      "moderator_signature" : "",
      "vendor_rating" : {
        "feedback": 0,
        "quality" : 0,
        "description" : 0,
        "delivery_time" : 0,
        "customer_service" : 0,
        "review" : ""
      },
      "moderator_rating" : {
        "feedback" : 0,
        "description" : 0,
        "time" : 0,
        "customer_service" : 0,
        "review" : ""
      }
  },
  "buyer_signature" : ""
}

Dispute: The Buyer being unsatisfied with the contents or delivery of the item

This dispute will arise if the Buyer claims that the item was not delivered or if the item delivered was incorrect, damaged, or significantly different from the product description. Whatever the circumstance, the Buyer will be attempting to obtain a full refund.

Typically, the Buyer will be the one to initiate a dispute and submit a dispute claim to the Moderator and Buyer. After this step, most of the dispute resolution process will transpire over the internal messaging channel we have built into OpenBazaar, which is encrypted with the participants’ public keys.

After the Moderator has come to a decision to who the winning party is, they will issue a resolution as described above.

When the funds are finally released from escrow to the winning party, both the Buyer and Vendor can generate a transaction summary. Here they will both have an opportunity to rate the Moderator on the dispute resolution. The Buyer’s transaction summary will also have the rating/review of the Vendor, which may not be counted in the final reputation score of the Vendor if the Buyer lost the dispute.

The Moderator will host the transaction summaries from both parties, which will be available for users to inspect.

Buyer transaction summary

{
  "tx_summary" : {
      "vendor" : {
        "guid" : "",
        "pubkey" : ""
      },
      "transaction" : {
        "listing" : "",
        "bitcoin_address" : "",
        "price" : "",
        "buyer_pubkey" : "",
        "moderator_guid" : "",
        "moderator_pubkey" : ""
      },
      "vendor_tx_signature" : "",
      "txid" : "",
      "trade_receipt_hash160" : "",
      "dispute" : {
        "transaction_hash160" : "",
        "claimant" : "",
        "claim" : ""
      },
      "claimant_signature" : "",
      "moderator_resolution" : {
        "dispute_hash160" : "",
        "summary" : ""
      },
      "moderator_signature" : "",
      "vendor_rating" : {
        "feedback": 0,
        "quality" : 0,
        "description" : 0,
        "delivery_time" : 0,
        "customer_service" : 0,
        "review" : ""
      },
      "moderator_rating" : {
        "feedback" : 0,
        "description" : 0,
        "time" : 0,
        "customer_service" : 0,
        "review" : ""
      }
  },
  "buyer_signature" : ""
}

Vendor transaction summary

{
  "tx_summary" : {
      "vendor" : {
        "guid" : "",
        "pubkey" : ""
      },
      "transaction" : {
        "listing" : "",
        "bitcoin_address" : "",
        "price" : "",
        "buyer_pubkey" : "",
        "moderator_guid" : "",
        "moderator_pubkey" : ""
      },
      "vendor_tx_signature" : "",
      "txid" : "",
      "trade_receipt_hash160" : "",
      "dispute" : {
        "transaction_hash160" : "",
        "claimant" : "",
        "claim" : ""
      },
      "claimant_signature" : "",
      "moderator_resolution" : {
        "dispute_hash160" : "",
        "summary" : ""
      },
      "moderator_signature" : "",
      "moderator_rating" : {
        "feedback" : 0,
        "description" : 0,
        "time" : 0,
        "customer_service" : 0,
        "review" : ""
      }
  },
  "vendor_signature" : ""
}

Reputation Score

The reputation score of a Vendor is the average feedback rating from all of their transactions. A user can expand the reputation score to see a Vendor’s average ratings for item quality, listing description, delivery time, and customer service.

Vendor Reputation Score

The reputation scores of a Moderator are the average feedback ratings from the winning and losing sides of disputed transactions. As with the Vendors, the average ratings for each criteria can be expanded from both sides.

Moderation Reputation Score

Challenges

To put it plainly, no reputation system is resistant to a Vendor purchasing their own items and making false-positive ratings.
This is especially true of a pseudonymous decentralized marketplace, where Buyer identities are – by default – undisclosed. Even a web-of-trust model, which is excellent at detecting suspicious islands of ‘reputable’ users, will not be able to distinguish between real and fake ratings of a Vendor. Why? As discussed, Buyer identities are not disclosed in the transaction summaries (unlike trade receipts, which is necessary for dispute resolution); Buyers are only represented by a bitcoin address. This is the equivalent of a single-use pseudonymous identity that would be the cause of suspicion in a web-of-trust model. As the GUID is directly mapped to the IP address (DHT), disclosing the GUID may compromise the real world privacy and security of the Buyer (as well as their spending habits).
That said, a web-of-trust graph based off transaction summaries where the Buyer is known (i.e. the GUID and Blockchain ID is voluntarily disclosed) would be a useful tool.
As transaction ratings in OpenBazaar must be tied to a bitcoin transaction, there is a cost – albeit a small one – to making a rating. Furthermore, the bitcoin transaction graph may emerge as a useful filter to assess/score the legitimacy of a transaction rating. For example, if an attacking Vendor uses the same coins to make 100 transactions in order to create 100 transaction ratings, this can be easily spotted with little analytical sophistication. There are many opportunities for third parties to build entire services on assessing the reputation of a Vendor.

The Future

A reputation system within OpenBazaar may facilitate the emergence of new types of markets to be supported on the network. The reputation of a Vendor may be used to assess the risk associated with that identity for loans or insurance policies issued over OpenBazaar. This is an fascinating subject that we’ll be exploring in future articles.

Going forward, past the initial release, will be the development of:

  1. Asynchronous ordering and network message caching
    Needs to be compatible with the rating system
  2. Rating system for Buyers?
    Is there any value in implementing a rating system for Buyers, or would this lead to a negative rating Mexican standoff?

 

Final Thoughts

OpenBazaar doesn’t claim to create or try to create a global decentralized reputation system for everything. What we have designed is a highly contextual rating system, similar to the standard e-commerce experience (with some improvements in our view), which will establish Vendor and Moderator reputations. The latter is really breaking new ground, which will undoubtedly be the subject of revision after seeing it run in the wild.

Finally, the transaction rating data can be parsed by third party developers to analyse and calculate the reputation scores according to the other approaches such as the Bayesian average. A high priority for future releases will be the long-term distributed free storage of transaction summaries.

Read More

Weekly Development Update, October 5th, 2015

Last week

Back end

API documentation rough draft completed. Work on finalizing orders nearly completed. Can now create contracts, send funds to multisig, release funds from multisig and create vendor rating. Working on moderators being able to release funds. Fixed API calls. Reworked reputation system since previous version ran into unforeseen technical challenges.

Front end

Fixed various issues with image uploading, added the ability to upload a custom store image, added a custom color picker that was much better than the native HTML one, and began work on the store wizard. Also coordinated efforts by open source contributors on the currency conversion and miscellaneous tasks. Integrated the new and improved add/edit contract page into OpenBazaar-Client and lots of misc. style enhancements throughout the app.

Read More

CNN Falsely Quotes Europol Report Mentioning OpenBazaar

On October 2nd CNN Money wrote an article entitled, “Police: High-tech criminals have us outmatched and outgunned.” In the article, they discuss a Europol report on cybercrime.

This article mentions OpenBazaar multiple times – and in every mention CNN gets the facts wrong.

1. “…underground marketplaces online are getting smarter. They’re now decentralized too. No one person is in control. There’s no single computer server to shut down, no dragon’s head to chop off.”

Only one problem: OpenBazaar is not an underground marketplace. Those marketplaces were built specifically for illicit goods, and rely on technology (such as Tor) which obfuscates identity online.

OpenBazaar is entirely different. It’s a decentralized platform, not controlled by anyone, and not run for profit. It’s not being built for any subset of trade, but gives anyone in the world the power to buy and sell any type of goods and services with anyone else. It doesn’t use Tor or any tool to obfuscate identity.

2. “But now police are starting to see marketplaces like OpenBazaar. It’s a peer-to-peer operation, just sellers and buyers. There’s no kingpin to arrest. Europol compares OpenBazaar to BitTorrent, where people trade pirated movies and music.”

Police are not starting to see marketplaces like OpenBazaar, because OpenBazaar hasn’t launched yet. In the Europol report OpenBazaar is briefly mentioned under the “Future Threats and Developments” section. They clearly refer to OpenBazaar as “emerging technology.”

3. “The fight against OpenBazaar is going just about as well as the fight against illegally copied media (not well).”

This claim is a complete fabrication. There is no “fight against OpenBazaar” or any conflict between the marketplace and law enforcement at all, for several reasons. The most obvious reason is that it’s impossible, since OpenBazaar hasn’t launched yet. Equally important is the point that OpenBazaar isn’t an underground marketplace at all, and law enforcement has no more reason to “fight against OpenBazaar” as they have to fight against any other online platform.

In fact, this one bullet point is the entire extent of the recommentations the Eurpol report had regarding OpenBazaar:

  • “Law enforcement should collaborate with private sector andacademia to explore investigative and research opportunitiesrelated to emerging technologies such as decentralised marketplaces like OpenBazaar.”

CNN took a brief mention of OpenBazaar in a Europol report and turned it into a false narrative of law enforcement against decentralized markets. There is no conflict. OpenBazaar exists to eliminate the middleman from ecommerce, taking fees down to 0% and allowing people to trade directly with each other online.

The world doesn’t have a standard protocol for trading goods and services online, nor does it have a network to share information about those goods and services. OpenBazaar finally creates a protocol and network that is free and open for all. As such, we expect that the use of OpenBazaar will largely reflect how society trades at large – almost entirely legitimate, positive trade with a small portion of people using it for illicit activity. We’re excited to see – once we’ve actually launched – how people will use OpenBazaar to make their own lives better.

Read More