Dropshipping on OpenBazaar

By: Dr. Washington Sanchez
Co-founder of OB1; core-developer for OpenBazaar

Since the early days of OpenBazaar, I’ve been interested in the potential for it to be used for dropshipping. But first, a quick intro:

Dropshipping is the process of selling goods to customers by placing orders on their behalf to suppliers, who ship the good directly to the customer.

Dropshipping has several advantages for individuals who want to start their own side-business:

  1. Straightforward. I won’t say it’s easy, but it is certainly far less complex and cheaper than importing and housing stock, let alone packaging and shipping to customers. Dropshipping enables you to focus that energy on sales and marketing.
  2. Flexible. You can sell a handful of products, or you can sell hundreds or thousands. It’s up to you. Running an online ecommerce store, dropshipping goods all around the world, can be done at home or in a cafe. As a side business, it doesn’t occupy too much of your time. If the business starts to scale up quickly, you can find yourself quitting your job and becoming your own boss sooner than you think!
  3. Low entry costs. This really can’t be emphasized enough. The costs of setting up a dropshipping operation can be done with very little capital up front. Also purchasing stock is only triggered when a customer has made a purchase: positive cash flow!

 

Example of a store I run that dropships items from Aliexpress
Example of a store I run that dropships items from Aliexpress

 

Even though the barriers to entry in running a dropshipping ecommerce store are low, make no mistake that it’s hard work to make it both great and scalable.

Unique Value

Now, what’s to stop the customer approaching the supplier directly and purchasing these goods? Well, nothing. This is why some dropshippers go to great lengths to hide their suppliers from potential customers.

A far better approach is to offer unique value in one way or another:

  • Niche. Focus on a niche class of goods or services so that your store becomes a lens for customers to find what they want. Individuals are more than willing to pay a small premium to avoid the inconvenience of purchasing multiple goods off different platforms.

 

Got a chance to chat with Lizzi about her amazing store; her hair game is strong!
Got a chance to chat with Lizzi about her amazing store; her hair game is strong!

 

  • Don’t suck. Form a positive relationship with your customers, and you will be rewarded. Be polite and go above and beyond for your customers.

 

Customer first
Customer first

 

  • Brand. This kinda reverses everything I’ve said about dropshipping so far, but if you can get your hands on the product before it reaches the customer (i.e. it’s a local sale, time isn’t a big factor, or it’s a popular product you can stock a little of), then add a unique brand or feature to an otherwise generic product. This immediately differentiates your products from everything else; you may even be shocked how a $2 modification can add to the retail value.
JDS Personalized Gifts are an example of a wholesaler that sells customizable stock… perfect for branding.
JDS Personalized Gifts are an example of a wholesaler that sells customizable stock… perfect for branding.

Dropshipping is both an art and a science, and there are plenty of resources you can draw from to become really great at it. Shopify has a great guide available for free that you can use for existing stores as well as OpenBazaar!

Dropshipping with Bitcoin and OpenBazaar

As you can imagine, dropshipping is a low margin business, but profitable under the right circumstances. It is particularly attractive to the Bitcoin ecosystem for 2 reasons:

  • Arbitrage. Dropshippers can take advantage of the rising value of Bitcoin, which is expected to be an upward secular trend for the true believers! As a result, they can order the good from the supplier with fiat and sell the good to the customer for Bitcoin. The price can be at a significant discount if the Vendor expects that the price of Bitcoin will rise to exceed the initial losses they experience on the transaction (i.e. it’s a time-preference thing). The price volatility of Bitcoin is a two-edged sword, so tread carefully if you apply these discounts.
  • Supply. Bitcoin is money, but it doesn’t have the chance to become the dominant international currency unless it can be used to buy anything (at least off the Internet). Bitcoin-powered dropshippers can make a meaningful impact to the ecosystem by offering a greater supply of goods and services that can be purchased with Bitcoin.

 

neo bitcoin for millions someday
My definition of success for Bitcoin

 

My definition of success for Bitcoin

Dropshipping on OpenBazaar is straightforward. Personally, I run several stores selling a variety of goods that I dropship predominantly from Aliexpress. Since April of this year, I’ve made ~40 sales, which isn’t too bad when you consider that I run these stores after-hours.

Here’s how I do it:

  • Create your OpenBazaar node. For now, you’ll probably need to run your node on a VPS so that it is accessible 24/7, unless you have a desktop computer that’s always on. (Note: Later this month we will be sharing a very easy method for setting this up and will post again when it is live!) If you’re running a blog or web-facing ecommerce store on an existing VPS, you can easily install and run OpenBazaar side-by-side. There’s a great YouTube playlist with step-by-step instructions. Alternatively you can opt for hosted solutions that will set it up on your behalf.
  • Setup your store. Create an eye-catching avatar/logo and header. Fill out your About page to pitch your store; a gif or two always helps. Add your email address or social media accounts, which can help foster trust. Register a Blockchain ID, and add your OpenBazaar GUID to your new decentralized identity as well as your other accounts.

 

Vintage Fashion Shop on OpenBazaar
I bought the logo and header off a digital artist on OpenBazaar incidentally!

 

  • Choose your niche. I recommend tailoring your store according to a specific niche or product category. This helps you narrow down on a group of suppliers, helps you build a brand, and increases your chances of repeat business.
  • Choose your suppliers. Suppliers can be another ecommerce store or an entire platform. Personally, I love to use AliExpress because it has a huge range of products of different categories, free shipping, and cheap prices. Moreover, AliExpress let’s you sort listings in a category/subcategory according to the number of orders (i.e. sort by popularity). This allows you to select items that have a proven track-record of market demand. You can also target popular and reputable suppliers on AliExpress to dropship.

 

You can pick the top 20 most popular items to sell within a product category or niche on AliExpress.
You can pick the top 20 most popular items to sell within a product category or niche on AliExpress.

 

  • Optimize your listing. Product information is your friend; the more data you add to your listing description about the product, the better! I generally only set 1 image per listing to minimize the contract download time for the Buyer. In the Description section, I include as many html tags as I need for additional product images.
  • Follow everyone and be friendly. A good way to get attention is to follow other nodes on OpenBazaar and send them a short ‘hello’. Buy some items off their stores and make friends.
  • Social media. Use social media to advertise what you’re selling on OpenBazaar. Product listings from https://duosear.ch include the listing image when shared on social media sites!

 

OpenBazaar 2.0

 

OpenBazaar 2.0 Screengrab
As we previously announced, OpenBazaar 2.0 will be a paradigm shift for the protocol and the project. It more closely aligns with the functionality we envisioned in the early days of the project, as well as fixing a number of limitations we’ve been longing to address:

  1. Distributed content. Store and listing data will be hosted in a distributed manner between peers on the network. What this means is that a Vendor won’t need to run their node off a desktop computer or VPS 24/7. Individuals can contribute to the health of the network by running a Gateway node, hosting store content on behalf of other users (which may serve as the foundation of affiliate marketing rewards with Bitcoin).
  2. Web accessibility. Stores and their listings will be accessible to the web via Gateways, making it that much easier to discover and purchase anything from the OpenBazaar network.
  3. Easier installation. We expect significantly less technical issues with the installation of OpenBazaar 2.0 across all the major operating systems.
  4. Flexibility. Vendors will have greater control to create product options and shipping rules for physical listings. Digital content can also be automatically download after purchasing.

This is only a snapshot of the many changes we’re bringing to OpenBazaar, which will make it that much easier to start-up a dropshipping enterprise on the network for free, with zero restrictions!

Read More

Oracles and Risk Contracts in OpenBazaar

1-oWCGi1RYfyMAbKpobLkolA

OpenBazaar is, among other things, a contracting platform that enables two or more parties to trade any thing. But if there is a common theme to the last few articles we have published, it is that the applications don’t stop at traditional e-commerce.

One application of particular interest is the formation of speculative contracts that depend on the unknown future state of an object or event.

Speculative contracts are a fundamental component of the market economy. They form the basis of insurance policies, loans, and futures markets just to name a few.

Typically, enforcement of speculative contracts are handled through the courts or trusted third parties that have exclusive control of funds. With Bitcoin and Ricardian contracts, speculative contracts can be resolved directly between two parties, or in cooperation with a mutually selected third party in the event of a dispute.

To achieve this in OpenBazaar, we need to define a new user role on the network, an Oracle, who will report on the state of an object or event in the future. Secondly, we will need a Ricardian contract schema for various types of speculative contracts, which we will refer to as risk contracts.

This article will review the role of Oracles in OpenBazaar and how risk contracts will be settled on the platform.

Oracles

Oracles are nodes on the OpenBazaar network that report on the state of any object or event in the future. Based on the Oracle’s report, a risk contract is settled in favor of the user who correctly predicted the future state.

In OpenBazaar, the responsibilities of an Oracle will depend on the individual user. In short, they can either serve as a:

  1. Reporter
  2. Escrow agent (i.e. Moderator)

As a reporter, the Oracle can publicly report on the state of an object or event over time, which will serve as a data input for risk contracts between other users. These users may have little or no interaction with the Oracle directly, who can serve state reports in plain-text publicly or via OpenBazaar’s instant messaging service. Oracles may even report the state of an object or event using their own sophisticated APIs similar to Reality Keys. Critically, reporterOracles do not handle any user funds and are not Moderators.

Oracles can also serve as the escrow agent or Moderators, where the futurestate of the object or event, which they report on, is the basis of releasing funds from multisignature escrow to the appropriate party. Releasing funds would be done in cooperation with the winning party. This service may only be necessary if the losing party is a sore loser, refusing to release funds for immature reasons. Ideally, Oracles would only be required to release funds in the event of a dispute.

Just as with Moderators, an open market for Oracles introduces competitive forces and diversity to improve the quality and range of data sources. Oraclescan advertise what categories of objects or events they will report on, and why they are uniquely qualified over their peers. The Oracle’s reputation system will reflect how accurately they report state and citing reputable sources.

Any user can become an Oracle.

Risk Contracts

Risk contracts are a class of Ricardian contract that settle the transfer of funds to a party based on the future state of an object or event. There are four types of risk contracts that OpenBazaar will support:

  1. Lending and Bonds (peer-to-peer loans, debt securities)
  2. Insurance (dispute insurance, traditional consumer/business insurance)
  3. Forward and Futures (asset price speculation)
  4. Prediction/Information (object or event state speculation)

For nearly all of these classes of risk contracts, an Oracle is required to validate the state of an object or event. In some contracts, the Moderator will act as the Oracle.

The risk contract schema is comparable to that of typical e-commerce Ricardian contracts in OpenBazaar. As a quick refresher, every listing contracthas the following objects that are filled with data:

  1. Metadata object — related to the type of contract and version of the contract
  2. ID of the Vendor object — e.g. GUID, blockchain ID (if stated), public keys
  3. Market object — semantic properties of the thing being sold
  4. Policy object— Terms and conditions, returns (if relevant)
  5. Moderator object— ID and public keys of the Moderator

All of the above objects are signed with the Vendor’s GUID to complete the listing contract that is published to the network.

In e-commerce contracts, the market object describes the physical/digital good or the type of service the user will perform. For example, this is the market object for a physical item:

"item" : {
    "title" : "",
    "description" : "",
    "condition" : "",
    "price_per_unit" : {
       "bitcoin" : "",
       "fiat" : {
          "price" : "",
          "currency_code" : ""
       }
    },
    "item_properties" : "",
    "quantity" : "",
    "category" : [ "" ],
    "image_hashes" : [ "" ],
    "keywords" : [ "" ],
    "process_time" : "",
    "sku" : ""
}

The market object will list specific contract details depending on the type of risk contract it is (e.g. loans: principal, interest, term; insurance: policy T&Cs, premiums, excess etc). The reference market object, which captures the details for all types of risk contracts, is:

"risk" : {
   "type" : "",                // Risk contract type
   "description" : "",         // Description of loan, policy, etc
   "loan" : {                  // Denominated in bitcoin or fiat
      "bitcoin" : "",
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "loan_repayments" : {
      "interest_rate_pa": 0,   // % per annum
      "interest_calc": "",     // Daily, monthly, year
      "repayments_sched": "",  // Repayment schedule
      "bitcoin" : "",          // Denominated in bitcoin or fiat
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "loan_collateral" : {       // Denominated in bitcoin or fiat
      "bitcoin" : "",
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "insurance_type" : "",      // Full, partial, zero-limit
   "policy_limit" : {          // Denominated in bitcoin or fiat
      "bitcoin" : "",
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "insurance_reserve" : 0,    // % collateral to be kept in escrow
   "insurance_coverage" : "",  // What the policy covers
   "insurance_premium" : {     
      "type" : "",             // One-off or regular
      "schedule" : "",         // Payment frequency
      "bitcoin" : "",          // Denominated in bitcoin or fiat
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "insurance_excess" : {      // Denominated in bitcoin or fiat
      "bitcoin" : "",
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "futures_asset" : "",       // Name of the asset
   "limit_per_unit": {         // Max up/down exposure
      "bitcoin" : "",
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "prediction_state" : "",    // Future state of object/event
   "units" : "",               // Quantity of asset/shares purchased
   "price_per_unit" : {        // Future price; bitcoin or fiat
      "bitcoin" : "",
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "position" : "",            // Short, long
   "term_days": "",            // Term of the contract
   "oracle_source" : "",       // Oracle user ID + sources
   "keywords": []              // Enhanced search
}

For each type of risk contract discussed below, we will examine the schema of the market object and briefly touch on the mechanics of the trade flow.

Lending and Bonds

Peer-to-peer loans and bonds can be offered in OpenBazaar using the following market object:

"risk" : {
   "type" : "loan",
   "description" : "",         // Description of the loan
   "loan_repayments" : {
      "interest_rate_pa": 0,   // % per annum
      "interest_calc": "",     // Daily, monthly, year
      "repayments_sched": "",  // Repayment schedule
      "bitcoin" : "",          // Denominated in bitcoin or fiat
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "term": "",                 // Term of the loan
   "loan_collateral" : {       // Denominated in bitcoin or fiat
      "bitcoin" : "",
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "keywords": []
}

For this type of contract, the Moderator acts as the Oracle, as the repayments are made to the Lender from the Buyer in bitcoin. The role of the Oracle in this scenario is to regulate the release of collateral (i.e. a reserve requirement) from the multisignature escrow address once the loan is repaid or the borrower has defaulted.

In terms of discovery, the borrower may place an invitation to tender for a loan, where the above listing contract is a tender proposal. Creditors can submit their loan offers to the borrower, who sorts through the competing offers to select one with the best terms.

This approach would give creditors a great deal of flexibility to tailor and compete on parameters such as the interest rate, reserve requirement, term, and repayment schedule based on the reputation of the borrower. Indeed, the creditor may require higher interest rates and collateral for pseudonymous users with a limited or poor reputation, relative to pseudonymous users with a high reputation or users with several public endpoints connected to their Blockchain ID.

An alternate approach is for the creditor to offer standardized loans (i.e. bonds) on the network. Other users can purchase these bonds from the creditor, receiving interest repayments as per a normal bond. As this market matures, users will buy and sell bonds as a typical financial asset on the OpenBazaar network.

Unlike physical or digital goods, or services, the trade flow is more straightforward after the loan is approved/bond purchased. Bitcoin repayments on principal and interest payments are made to addresses specified in the contract (stage 3 of the trade flow).

The OpenBazaar application will keep track of repayments and manage dispute resolution through the Moderator as per normal.

Insurance

Insurance contracts in OpenBazaar can be offered in one of three forms:

  1. Fully collateralized
  2. Partially collateralized
  3. No limit

A fully collateralized insurance contract would lock the entire value of the policy (i.e. the maximum coverage limit) in multisignature escrow, while the policyholder pays regular premiums to the insurer.

Theoretically, the accrued premiums plus collateral would be equal to the policy limit, but this may place the insurer at a financial disadvantage given that the policy funds are locked and are not yielding any interest.

However, if there is no claim on the policy, the insurer will collect premiums that can be loosely considered a financial coupon that yields the insurer a reward for risking funds up-front for the policyholder. The pseudo coupon rate may be higher than low-yield government bonds, but significantly more risky. This may also turn insurance policies in OpenBazaar into tradeable financial instruments.

Premiums for this type of insurance contract may be higher than standard policies, and may even exceed the policy limit. However, in exchange for the higher premiums, the policyholder is secure in the knowledge that if the policy is triggered, all of the funds are accessible.

Unlike partially collateralized insurance contracts, there is zero chance of the insurer defaulting due to an inability to pay the policy limit, at the cost of the policyholder. This represents a significant technological advance in the insurance industry.

A partially collateralized insurance contract only locks a percentage of the policy’s value in multisignature escrow throughout the life of the policy.

As the full limit of the insurance policy is no longer locked in a multisignature escrow, the policyholder is now trusting the insurer to transfer the necessary amount of funds in the event of a claim. There is a risk of the insurer defaulting, which may be caused by financial mismanagement, higher than expected frequency/severity of claims, or simply fraud. A combination of regulation, reinsurance contracts, and transparent proof of reserves could potentially be used to mitigate the risk of the insurer defaulting.

Partially collateralized insurance contracts characterizes the modern regulated insurance industry. This is only possible for traditional insurance companies because of the pooling of contracts, regulation, and access to reinsurance.

A no limit insurance contracts technically fall under the ‘partially collateralized’ category. This contract doesn’t set a maximum coverage (i.e. the insurer is fully exposed to the total value of the item insured). Any amount of funds may be locked in multisignature escrow as collateral.

The market object for all insurance contracts:

"risk" : {
   "type" : "insurance",
   "description" : "",         // Description of policy
   "insurance_type" : "",      // Full, partial, zero-limit
   "policy_limit" : {          // Denominated in bitcoin or fiat
      "bitcoin" : "",
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "insurance_reserve" : 0,    // % collateral to be kept in escrow
   "insurance_coverage" : "",  // What the policy covers
   "insurance_premium" : {     
      "type" : "",             // One-off or regular
      "schedule" : "",         // Payment frequency
      "bitcoin" : "",          // Denominated in bitcoin or fiat
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "insurance_excess" : {      // Denominated in bitcoin or fiat
      "bitcoin" : "",
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "term_days": "",            // Term of the contract
   "keywords": []              // Enhanced search
}

If a claim is triggered, it may require the existing insurance contract to be replaced with a new insurance contract.

Insurance contracts could be created for several applications such as:

  1. Dispute resolution insurance — in the event that a Vendor loses a disputed transaction in OpenBazaar
  2. Traditional consumer/commercial insurance — e.g. car insurance, house insurance, health insurance
  3. Credit default swaps — an insurance risk contract can be taken out to hedge against the risk of a loan/bond defaulting.

Some of these contracts may require interaction with legacy stakeholders (i.e. the government), which will be the subject of a future article.

Forward and Futures

Forward and futures contracts allow two parties to speculate or hedge against the price of any asset.

For example, a wheat farmer may take out a forward contract locking a sell order at a price of $100/bushel a year from now. This price would presumably guarantee the farmer to profit by an acceptable margin (provided at least X bushels are sold at that time), irrespective of whatever the actual market price is at the time.

With the forward contract, the farmer sacrifices any profit that he might have gained had he risked selling at the market price a year later, if the market price had risen (e.g. $150/bush). Simultaneously, the forward contractprotects the farmer from potential losses if the market price decreases a year from now (e.g. $50/bushel).

Typically, neither party intend to physically purchase/sell the underlying asset. Rather, they novate to settle the contract. Pure price speculation/hedging is the common purpose of forward/futures contracts.

The unique design of forward/futures contracts in OpenBazaar is described in some detail here. The updated market object schema for forward/futures contracts:

"risk" : {
   "type" : "forward/futures", 
   "description" : "",         // Description of forward/future
   "futures_asset" : "",       // Name of the asset
   "price_per_unit" : {        // Future price; bitcoin or fiat
      "bitcoin" : "",
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },   
   "limit_per_unit": {         // Max up/down exposure
      "bitcoin" : "",
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "units" : "",               // Quantity of asset purchased
   "position" : "",            // Short, long, moderator
   "term_days": "",            // Term of the contract
   "oracle_source" : "",       // Oracle user ID + sources
   "keywords": []              // Enhanced search
}

Under the ‘spot_price_source’ object, either an API source or an Oracle ID can be added to establish consensus on the tie-breaking rules governing the settlement of the contract.

Prediction/Information

While forward and futures contract speculate and hedge against the price of an asset, prediction markets speculate and hedge against the future state any object or event.

For example, a prediction contract can be established between Alice and Bob based on whether it will rain the next day in Brisbane, Australia. Alice and Bob deposit 0.5 bitcoin into 2-of-3 multisignature escrow (Moderator as backup); the total value in escrow is 1 bitcoin. Alice goes long (i.e. predicts rain) while Bob goes short on rain tomorrow. The next day comes and it rains; 1 bitcoin is paid out to Alice from escrow. If Bob doesn’t live in Brisbane, he may check with the Oracle (or the Weather Channel) to confirm that it did indeed rain before releasing the funds.

In this example, the chance of rain was 50%. But imagine that Alice and Bob both know that the chances of rain the next day, according to the Weather Channel, is 90%. Alice, predicting rain, deposits 0.9 bitcoin into multisignature escrow, while Bob deposits 0.1 bitcoin. As before, the winner is paid out 1 bitcoin from escrow. While ostensibly it seems that Alice is risking more than Bob, in reality her risk is lower than Bob based on the knowledge provided by the Weather Channel. In other words, the odds are overwhelmingly in Alice’s favor to collect Bob’s 0.1 bitcoin. Another way to see it is that Alice is paying a premium, in terms of risk, to entice Bob to risk his bitcoin on the outcome of an event that is unlikely to go in his favor.

There are a few key components to prediction markets:

  1. Selecting an appropriate Oracle
  2. Listing and/or discovering available prediction contracts

Selecting an Oracle

The OpenBazaar application will allow users to query the network for nodes that have identified themselves as Oracles, much in the same way that Moderators will be selected.

Users will be able to sort through Oracles based on reputation, category (e.g. Oracles dedicated to reporting sports games, weather, news etc), or fees. Oracles can also describe on their store-front in detail what type of reporting they perform and the sources they rely on.

As stated earlier, an Oracle may act as either a reporting source or Moderator in a prediction contract.

Discovering Prediction Contracts

Discovery of prediction contracts is a key challenge to form an efficient prediction market.

Prediction contracts can be formed between two users on an ad hoc basis, with the details negotiated directly between them. In this case, either party can create the listing contract.

Alternatively, prediction contracts could be created by Oracles who commit to: 1) reporting on the state of a future event, and 2) acting as a Moderator for any prediction contracts that arise from that report. Oracles would create the contract as a Moderator, leaving open slots for a long and short position on the event. The price per share of each contract, which reflects the likelihood of the event occurring, can be dynamically updated by the Oracle in real time based on their ability to match users going long or short.

OpenBazaar has a ‘follow’ feature to enable notifications, which means that a user can be notified from the Oracle when new events will be reported on or new prediction contracts become available.

To minimize trust, prediction contracts can be coordinated by neutral Moderators who are not Oracles, who rather cite a user(s) or source as theOracle.

The market object for prediction contracts:

"risk" : {
   "type" : "prediction",
   "description" : "",         // Description of prediction
   "prediction_state" : "",    // Future state of object/event
   "units" : "",               // Quantity of shares purchased
   "price_per_unit" : {        // Future price; bitcoin or fiat
      "bitcoin" : "",
      "fiat" : {
         "price" : "",
         "currency_code" : ""
      }
   },
   "position" : "",            // Short, long
   "term_days": "",            // Term of the contract
   "oracle_source" : "",       // Oracle user ID + sources
   "keywords": []              // Enhanced search
}

There are several projects attempting to create decentralized prediction markets, such as Augur and Truthcoin. Undoubtedly there are potential collaborative opportunities, particularly when it comes to resolving state in a decentralized manner.

What is the key difference between what we hope to implement in OpenBazaar versus say Augur? The core difference is mostly philosophical: we believe that low friction markets for third party Oracles can create a supply of highly reputable state reporting, at near marginal cost and at scale, over time.

While Augur is attempting to create the purest form of near-trustless state reporting (kudos to them!), we believe that markets for third party Oraclescan solve most of the challenges associated with creating a decentralized prediction market at a fraction of the technical difficulty. High value prediction contracts may benefit from the more sophisticated and lower trust-dependent approach taken by Augur.

Deployment

Implementation of risk contracts by OB1 developers is not expected until sometime next year. However, deployment may occur sooner with the help of volunteer and/or commercial contributors or partners.

That said, the existing contract schema can be tailored to include the semantic data required for most risk contracts described in this article. Moderators can also include Oracle-based services in their store description. As a result, we may see some early experiments in risk contracts in lieu of an official implementation.

TL;DR

  • OpenBazaar will enable a new user role: Oracles
  • Anyone can be an Oracle
  • Oracles can choose the level of involvement in individual transactions, from reporting to Moderating transactions
  • Risk contracts to be supported by OpenBazaar that will enable lending, insurance, forward/futures, and prediction markets

Acknowledgements

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

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

Digital Assets in OpenBazaar

Digital assets are obligations to real-world items, content, or services that are digitally recorded. Digital assets are issued by individuals or corporations, and the bearers of the assets are entitled to the obligation promised by the issuer. In simple terms, they are the digital equivalent of a poker chip in a casino, redeemable for cash at the end of a game.

To make digital assets immutable and unforgeable, they are issued and transferred over Bitcoin’s blockchain as transactional metadata and is associated with a unique Bitcoin address. Using public key encryption, only the private key associated with that address can be used to authenticate and receive a digital asset obligation.

Digital assets can be used in a number of different ways. Here are three concrete examples:

  1. Gold certificates
    • The bearer can redeem physical ounces of gold from a depository institution after proving ownership of the address through a digital signature
  2. Keys
    • A electronically-activated lock can be triggered on/off only with the digital signature from the private key of the digital asset bearer
    • After selling the car, the digital asset is transferred to the new owner’s address; the lock will now exclusively respond to the new owner
  3. Coupons and Gift Certificates
    • The bearer can digitally sign a message to claim a shopping discount or gift certificate issued by a Vendor

The applications of digital assets are limited by a combination of tools and creativity. Over the past several years, the tools and protocols to create and transfer digital assets have matured. Presently there are three major digital asset protocols (not counting metacoin/altcoin-based protocols):

  1. Open Assets
  2. CoinSpark 
  3. Colored coins 
DAP Transaction Share
Transaction share covers the past week

These protocols generally share the same approach:

Generalised Digital Asset Protocol

Bitcoin transactions make use of OP_RETURN to embed metadata to create or transfer digital assets to an output(s). These outputs can be audited for transactions on the blockchain to determine who the rightful owner of a digital asset is and how much of it they have.

 

The Bottleneck

The challenge with digital assets is discovery and security (i.e. secured vs unsecured loan).

In the gold certificate example, how do I find gold certificates to purchase, with the intention of taking delivery of physical ounces at some later date? How does the buyer know that the issuer of gold certificates will deliver physical ounces to the bearer? Is the depository institution reputable? Can I purchase gold certificates at a lower premium from someone else?

All of these questions are solved by OpenBazaar.

 

Selling Digital Assets over OpenBazaar

The core of OpenBazaar is a combination of the following components:

  1. A contracting platform
    • Allows a buyer and seller to lock in the terms of trade for the transfer of a digital asset via a Ricardian contract.
  2. A discovery network
    • Permits users to scan the distributed peer-to-peer network for users selling digital assets you’re interested in.
  3. A marketplace for dispute resolution
    • Empowers contracting users to find a reputable agent to resolve any potential disputes, or release locked funds in escrow if one is unresponsive or incapacitated.
  4. A distributed reputation system
    • Allows users to assess the transactional history and ratings of a Vendor within OpenBazaar.
  5. Bitcoin for payments
    • Enables rapid and global payments as well as a powerful escrow system to prevent any one person from stealing funds.

For issuers to sell their digital assets, they would firstly need to create a listing or ‘ask order’ on their node. Listings are simply JSON-formatted text files that fit the properties of a Ricardian contract, which are parsed and formatted in a user-friendly interface for buyers. The Ricardian contract schema for selling physical items, digital content (e.g. music), or services is not well suited for listing digital assets. As a result, we have created a new contract schema to list digital assets for sale.

Listing Schema for the Digital Asset in the Ricardian Contract.

Schema objects:

  • Issuance
    • Boolean value to indicate whether the contract is issuing a digital asset or not
  • Asset
    • ID – what is the identity of the digital asset (typically defined by the protocol used to create it)
    • Source – the transaction ID and bitcoin address that the digital asset is associated with, as well as the protocol used to issue/transfer the asset
    • Properties – the schema nested within this object would be unique to the type of the digital asset; in the above example, the schema is for an equity security (i.e. stocks)
  • Quantity
    • Number of units of the digital asset to be transferred
  • Price per asset
    • Bitcoin – if the digital asset is to be priced in bitcoin directly
    • Fiat – if the digital asset is to be priced in fiat, the seller needs to identity the fiat currency and price (at the time of sale, the necessary quantity of bitcoin will be calculated based on the exchange rate)

As with all Ricardian contracts in OpenBazaar, each stage of the trade flow will be signed using the Seller and Buyer GUID keys.

Trade Flow for Digital Assets

  1. The Seller creates a listing for the digital asset (equivalent of an ask order)
  2. Buyer sends a purchase order to the Seller
    • The order includes an unsigned transaction
    • Transaction has n inputs and 1 output to send the purchase amount of the digital asset to the Seller
  3. The Seller acknowledges the order and replies with a signed transaction
    • The Seller adds two components to the unsigned transaction:
      • 1 input from their digital asset address, transferring the equivalent of a miner’s fee to the Buyer’s new digital asset address
      • An OP_RETURN output embedded with data (recognized by a specific digital asset protocol) releasing assets to the Buyer’s digital asset address
  4. The Buyer receives the transaction, signs it, and broadcasts it to the network

Final state: the funds are released to the Seller, and the digital asset is transferred to the Buyer.

Note that for direct exchanges of Bitcoin for a digital asset, no multisignature escrow is required as a single transaction with multiple inputs and outputs can simultaneously fund the Seller and transfer the digital asset to the Buyer.

 

Securitized Digital Assets

Every digital asset has an underlying value it represents. A gold certificate – it is a promise to redeem physical ounces of gold. A gift certificate – any items purchased at a store up to a certain value. A concert ticket – the price of admission to the concert.

For the digital asset holder, they must have trust in issuer to fulfill their obligation. For large and reputable institutions that are legally accessible, a Buyer may feel comfortable trusting their counterparty. However, this approach means that smaller institutions or pseudonymous individuals are unlikely to solicit enough trust from potential buyers.

One possible solution is to secure (financially) these digital assets by placing the purchase amount in multisignature escrow. This way, a Buyer can be refunded if the issuer fails to deliver on their obligation. This comes with a trade-off to digital asset liquidity, and therefore may only be practical to certain high value digital assets where trust is low and risk is high.

Alternatively, if a Moderator is involved in the transaction, they can purchase the escrow amount (to be released in the future) for a discounted present value. For example:

  1. Alice purchases 1 BTC worth of gold as a digital asset from Bob
  2. Charlie (the Moderator) sell 0.9 BTC to Bob in exchange for the 1 BTC in escrow to be released in the future
  3. Bob gets the funds immediately, while Charlie makes a profit at a later time point

This scenario breaks down if Bob fails to deliver any gold to Alice, defaulting on his obligation that triggers a refund to Alice. As a result, Charlie is taking a risk with this approach for the chance for profit, all the while Alice is protected.

 

When will it be ready?

We aim to release a completely overhauled version of the client in the next few months that is focused on e-commerce (physical items, digital content, and services). Shortly after this, we will be progressively adding support to new types of Ricardian contracts and their corresponding trade flows to expand the use-cases of OpenBazaar. If you’re a developer who wants to see this vision completed sooner rather than later, get in touch with us at project [at] openbazaar dot org or join our community in Slack.

 

 

Written by:

Dr Washington Sanchez (drwasho)

 

Special thanks to:

Read More

Guide – How to Setup/Run an OpenBazaar Node on a VPS

Note: This blog post is outdated. Read this article for the latest code.

If you want to test out OpenBazaar, but don’t want to install it (or can’t) on your own computer, you can rent a Virtual Private Server (VPS) instead.

If you already have a VPS, you can run the OpenBazaar installation and then skip to this section.

There are many different VPS services available, and they typically provide the same services. One of the more popular is Digital Ocean. You can sign up and start running a VPS with their service easily, or shop around and choose another service.

You can choose how large you want the space to be. OpenBazaar and it’s dependencies are around 5 GB, so we recommend 7 GBs or more. You don’t need large amounts of RAM or anything fancy. These types of installs are typically inexpensive, $5 or $10 a month.

You can then choose your OS. I recommend Ubuntu, either 12 or 14 should be fine.

Once you’ve rented a VPS, chosen and installed your OS, you should receive instructions on how to ssh into your machine, or some VPS allow you to access the terminal via web interface. Either way, you can now install OpenBazaar by following these instructions.

One tip: it can sometimes take a long time to generate a key pair. If you run this command first, it will speed up that process considerably:

sudo apt-get install haveged

Configuring Your SSH Client

For your desktop or laptop, I recommend using PuTTY. vSSH is the clear winner for iPhone or Android; please purchase the full featured app to support the devs for making an excellent application. The configuration is somewhat similar for PuTTY and vSSH.

Firstly, add in the host IP address of your VPS (remember to save your configuration once your done to save time):

Putty 01

Depending on how you configured your VPS above, you may have a password or private key for authenticating your session. If you have a ppk (like me), select the file’s location on laptop or mobile device (this may be more difficult with iOS as it lacks any sort of accessible file system, so you may be better off going with a password):

Putty 02

Setup your port forwarding so that port 8888 from your VPS is forwarded to your localhost port 8888.

  • Your source port is ‘8888’ and source IP is 127.0.0.1
  • Your destination port is ‘8888’ and destination IP is 127.0.0.1
  • Type = Local

Putty 03

In PuTTY, the end result should look like this:

Putty 04

Running Your Node

Assuming you have configured your VPS and SSH client correctly, all you have to do is start a session with your VPS and navigate to your OpenBazaar folder to run the node as instructed.

The best way to do that is to run your node with UPnP disabled and forcing the node to use port 8888 (doesn’t have to be port 8888, you can select any port number you want… just make sure your SSH client is forwarding the right port to your local host). This can be achieved through the following command:

./openbazaar -q 8888 --disable-open-browser start

Recommended: Your node will go down the moment you disconnect your SSH session. To keep running your OpenBazaar node after your session has ended, enter the following command to run your node (instead of above):

$ nohup ./openbazaar -q 8888 --disable-open-browser start &

Open up your browser and enter the following address to access your OB node:

127.0.0.1:8888

This works surprisingly well on mobile devices using vSSH and is a testament to how powerful OpenBazaar can become in the future!

Read More