OpenBazaar Threat Model

This blog post outlines the security model and policies of OpenBazaar. It is written for contributors with push access who are asked to review and merge pull requests, external developers who are interested in submitting pull requests, and end-users who are interested in understanding the security model of OpenBazaar. We will also be including this threat model in our project documentation, but we are sharing on our blog first to solicit feedback from our users and security experts in the field.

Every contributor with push access must read this document.

Threat model

OpenBazaar makes important assumptions about the strength of its adversaries. To understand how to properly develop code for OpenBazaar, it is crucial to understand who the adversaries of OpenBazaar can be, what resources they are able to employ, and what their goals are. Furthermore, it is important to understand what the adversaries are not capable of.

Assumed adversaries

Our adversaries can be broadly categorized as 4 different entities:

  1. Malicious users
  2. Malicious corporations
  3. Malicious governments
  4. Malicious developers

Each of these constitutes a separate entity with different resources and different goals. These are explained below.

Malicious users

A malicious user is a user who tries to break the security of OpenBazaar, usually for financial gain. We treat malicious users as game-theoretic agents who are able to invest approximately as much as they would win out of a security breach, as long as their winnings are significantly larger than their losses.

The goal of malicious users is to make money. The two primary ways of making money by breaking the security of OpenBazaar are these:

  • Being able to receive a product without making a proper payment
  • Being able to receive money without delivering a product

As these attacks are financially incentivized, there is no limit as to what capital can be invested in such attacks if it’s possible to earn it back. However, for our purposes, we assume that such attackers are limited to up-front investments of $1,000,000 per year collectively. Thus, they are not able to, for example, break the bitcoin network security, or attack 1024-bit RSA keys.

These attackers are the easiest to model, as they play within the closed OpenBazaar system and can be treated game-theoretically. Generally, in our games, these agents can be assumed to be ε-good, meaning they will not attempt a malicious strategy if there is no financial gain in it. We aim to fully protect users from such malicious actors.

Malicious corporations

Certain corporations may find the OpenBazaar network undesirable and may want to break its security in order to bring it down. Their financial incentive may not be part of the closed OpenBazaar system: They may be able to make profits outside of OpenBazaar by making OpenBazaar unreliable and insecure.

The goals of such agents are the following:

  • Bringing down the majority of OpenBazaar nodes
  • Disrupting the majority of connectivity of the OpenBazaar network
  • Breaking the trust people have on the OpenBazaar network

“Breaking the trust” here means creating arbitrary buyers and sellers that do not follow the expected strategy and default on their payments or shipping.

The incentive for such corporations may be that they are losing money because of competitive sales on the OpenBazaar network.

We currently assume that such corporations are able to spend similar monetary amounts as malicious users to attack the network.

However, malicious corporations cannot be modeled as ε-good, as they wish to cause harm on the network through external incentives. We aim to partially protect our users from such malicious actors, through reputation systems and positive margins in our nash equilibria that can decentivize such malicious actors. Reputation systems which require proof-of-burn or similar sybil-resistant schemes help in making these attacks more costly. Webs-of-trust can fully protect careful users from such malicious actors, although great care is required from the user side.


Malicious governments

As the OpenBazaar software can be operated worldwide, malicious governments should be taken into account. Malicious governments may wish to bring the network down for censorship reasons or for legal reasons.

The goals of such agents are similar to the goals of malicious corporations. In addition, a malicious government has the following goals:

  • Unmask the anonymity of an OpenBazaar user
  • Block certain categories of products or individual products from being traded

A malicious government has similar resources as a malicious corporation.

Malicious governments can be categorized into active and passive based on their willingness to interfere with networks. A passive government is unwilling to manipulate data as a man-in-the-middle at the network level, and is only willing to be a passive eavesdropper. An active government is happy to interfere with network traffic by manipulating it.

A passive government has access to these additional resources:

  • They can manipulate the legal framework of their country
  • They can introduce new laws
  • They can issue arbitrary subpoenas and warrants
  • They can issue secret warrants and take decisions in secret courts

An active government has, in addition, access to the following resources:

  • They can sybil-attack the issue of identification documents such as passports
  • They can man-in-the-middle Internet connections within their country (up to the Tor security assumptions)
  • They can break Internet connectivity within their country
  • They can issue arbitrary PKI certificates for HTTPS and TLS protocols

Malicious governments are the hardest attack to guard against. While our goal is to be able to defend against malicious governments, we are not able to do this currently. Our decentralization efforts are oriented around the idea that basic protection from malicious governments should be possible.

We aim to provide full protection against a passive malicious government, and partial protection against active malicious governments.

On the topic of denial-of-service attacks by breaking network connectivity completely, we do not have a mechanism of defence. We rely on the fact that countries will prefer to keep Internet connectivity for the most part of their users. Mesh networks can be used to guard against such attacks, but these are beyond the scope of our threat model.

Malicious developers

The last malicious actor is a malicious developer with commit access. These developers are manipulated by one of the above actors through law (secret subpoenas) or bribery in order to achieve their end-goals. Therefore, the goals of a malicious developer are aligned with the goals of those above.

We prefer to list this malicious actor separately, as they have access to a different arsenal of attacks.

In particular, a malicious developer has access to the following resources:

  • They can merge arbitrary pull requests, in effect writing arbitrary code

Our primary means of defence against malicious developers are secure development practices, some of which we explain later in this document.

Security assumptions

We rely on the assumption that certain systems are secure. We make the assumption that the following constituent parts of our system are secure:

  • RSA, ECDSA, SHA256, AES and the rest of the cryptographic primitives used by the software
  • GPG
  • Bitcoin
  • Namecoin
  • Tor (including its assumptions on network monitoring)
  • The browser used by the user
  • The user’s computer
  • Our implementation languages and frameworks (Python, Javascript, Angular)
  • The libraries we rely on which are listed here:

Beta status

OpenBazaar is currently in beta and is facing multiple security issues, in addition to the assumptions above. These issues can cause your transactions to be compromised, your money not to go through or be stolen, or your products not to be delivered, even by attackers with very limited resources. We estimate that an attacker could possibly compromise the system’s security for less than a few thousand dollars. Please be careful when using OpenBazaar at this stage. If you’re using the regular bitcoin network, keep the amounts exchanged low (less than a few hundred dollars). Don’t sell your car on OpenBazaar yet!

For the beta version, we rely on the security of HTTPS and PKI. This is needed, as we rely on pip for securely fetching python packages, which relies on HTTPS. Therefore, an active malicious government is able to interfere with OpenBazaar. The specific assumptions are listed below.

However, we are interested in dropping this requirement for stable versions. We are still unsure of the distribution channels to achieve this.

As part of our beta status, we also rely on a few centralized pieces of infrastructure, all of which we would like to replace with decentralized systems. These are our assumptions for the beta version:

  • PKI is secure. CAs are not compromised or government-controlled.
  • HTTPS is secure.
  • The operators of seed servers are not interested in performing denial-of-service attacks.
  • Obelisk and the official obelisk servers are secure and their owners not malicious.
  • The official DNSChain servers are secure and their owners not malicious.

The last two requirements are strong. A user who is concerned with these last points can lift these requirements by running their own Obelisk server or using a trusted Obelisk server, which requires maintaining a bitcoin blockchain copy, and their own DNSChain server, which requires maintaining a namecoin blockchain copy. We have plans to use SVP systems as a replacement for these.

We may introduce additional points of centralization for future beta versions in order to create a working product, which we plan to lift later.

As part of our Beta status, we do not currently employ any anonymity-preserving mechanisms. All transactions are completely trackable. Therefore, malicious governments with the goal of uncovering your identity will succeed trivially.

Development infrastructure

We also rely on certain pieces of centralized infrastructure for development. Here are our assumptions about services we use for development and we assume are secure and with no malicious operators:

  • GitHub
  • Slack
  • Gmail

We also rely on OTR and GPG for secure development-related communications.

Development process

In order to guard against actors such as malicious developers, we are publishing all of the source code of OpenBazaar as open source under the MIT license. We encourage security experts to audit our code for security vulnerabilities. Don’t take our word on the security of OpenBazaar; inspect the code yourself. Don’t trust the OpenBazaar developers. While we’re doing our best to provide secure software, the reason it’s open source is so that it can be reviewed and audited.

Our development process is transparent and security-oriented. We follow certain contributing guidelines which require code reviews and follow proper release cycles. The details of our contributing procedures can be found in the CONTRIBUTING document. We don’t just make our code open source. Our reviews and commit history are also available for inspection, so that differential audits are possible.

We GPG-sign our releases with contributor keys in the strong GPG set. Currently, Dionysis Zindros signs releases. The signature signifies that the release maintainer believes the source code to be secure at the time of release, and that it was intentionally released by the team, without backdoors or intentional vulnerabilities as far as we know. These signatures are hard to fake by someone who wishes to introduce backdoors in the future. If you require strong security, do not run releases that have not been GPG-signed, or manually inspect the code. Otherwise, at least make sure your binaries and sources are at least downloaded via HTTPS.

Our decision-making procedure is transparent too. We use 2-of-4 multisig decision-making for financial decisions. The details of our transparency in decision making can be found in our transparency post.

Some of our commits are GPG-signed. The GPG-signed commits signify that:

  • The code introduced in the commit is believed to be secure by the signer
  • The parent of the commit is the currently available branch to the signer

Please note that signing a commit, contrary to popular belief, does not indicate that all the previous commits have been checked by the committer. It only indicates that the particular commit code really is written by the person who signed the commit, and this is it.

It is very easy to introduce fake commits on git and GitHub, using usernames and e-mails of existing contributors. Therefore, we prefer signing individual commits instead of tagging and signing only occassionally to show a full good history. It’s impractical to create a tag for every commit one creates.

Read More

OpenBazaar goes to FOSDEM

The OpenBazaar team is going to FOSDEM 2015 in Brussels, Belgium on January 31st and February 1st.


Several core members of the team and contributors are going to be there. We’re joining forces from all over the world:

So, come and say hello.

We’ll be giving a 20-minute lightning talk on Sunday afternoon. But most importantly, we’ll stick around and will be happy to demo OpenBazaar to you on Saturday and Sunday, answer your questions, talk about code, trade, law, anonymity, privacy, politics, and bitcoin, and discuss our vision for the future. Of course, we won’t be skipping the traditional FOSDEM beer either.

We’ll be happy to present you our GPG keys so that you can verify their authenticity in person.

We’re very much looking forward to meeting you!

See you in Brussels!

Read More

Security incident: Developer impostor

We recently faced a minor security incident at the OpenBazaar GitHub repository.

An attacker was able to briefly gain push access and make code changes that remained undetected for about one hour, by pretending to be a developer with contributor access who lost access to his normal account. The changes that the attacker made to the code were insignificant and were not related to security – they were mostly tests. Only the “develop” branch was affected, not the “master” branch. As our users run the “master” branch, we expect no users to be affected by this breach.

We reverted the code changes immediately and access rights were restored. We don’t expect anyone to be affected by this attack. As a response to the attack, we are on the process of developing more rigorous security policies which would require proper authentication for committer username changes. Our new policies will also include operational security requirements for existing developers. In response to the attack and in coordination with GitHub, we have ensured that the accounts of the attacker have been appropriately banned.

As part of our transparency commitment to our users, we are publishing this security incident so that people are aware of our potential problems and solutions.

Our full incident response post-mortem report is made available for the community to read.

Read More

Migration of our project funds to a multisig address.

We, the undersigned core developers of OpenBazaar, have decided with consensus
on the following on November 4th, 2014:

Because of the facts that:

(1) Developers can be malicious

Our threat model involves powerful agents at play. These can include malicious
governments who have the ability to issue secret warrants legally requiring
developers to take certain actions. We therefore follow a trust-but-verify
model in all our development process. As such, certain developers of the
project may in the future be legally required to perform actions that they do
not agree with, without the ability to communicate this fact to others. Through
multisig, we are requiring at least one more developer to perform a check on
financial decisions as a safety-net.

(2) Mistakes happen

We are human and often make mistakes. This can include lost wallet keys,
or destroyed laptops. Multisig will allow us to migrate our funds in case one
developer loses their keys.

We also sometimes make transactions that may be incorrect. A second pair of
eyes is good to make sure we don’t burn our funds or we don’t send them to the
wrong third party.

(3) Developers can become unavailable

Developers may become unavailable for various reasons such as accident or
death. We do not want to depend on one individual for all our funds. In case of
unavailability, multisig allows us to move our funds to a new address.

(4) Dictatorship is evil

We take team decisions with consensus. However, sometimes consensus cannot be
reached. We have never had this problem in our team yet, but it is bound to
happen in the future. In cases where consensus cannot be reached, an individual
developer should not have the power to act solely as a dictator and enforce
their opinion. Multisig requires at least one more party to consent. This acts
as a safety net.

(5) Transparency is good

We believe in a transparent development model. All our code is open source. We
interact with the community through public chat on IRC, on a public subreddit,
and in forums, all viewable by anyone. We plan features and submit bug reports
through GitHub issues, which are public. Anyone is able to criticize us through
these channels directly, even pseudonymously.

As of Beta 3, we are also making all all-hands developer video calls publicly
available through live streaming, and they are recorded for future reference.
We wish to be held accountable for our actions, and we invite the criticism of
the community.

In this direction, as we are funded through donations, we believe the public
should know exactly how much money we have and where and when exactly it is
spent. By publishing our multisig address, we submit our financial records to
public scrutiny.

Now, therefore, we are announcing the following:

(1) Ownership of public keys

Each of us controls one of the following public bitcoin keys. We are
providing bitcoin signatures as proof that we are in control of each.

Brian Hoffman:

Address: 12khSGHCvJoB7d5evWykvgeJVdYtSgAaxo
Uncompressed Pubkey:
Message: This is Brian and I own 12khSGHCvJoB7d5evWykvgeJVdYtSgAaxo

Sam Patterson:

Address: 19xZbcnF9HB3ycfFJmQS5Gr7eJ7riJKrWc
Uncompressed Pubkey:
Message: This is Sam. I own 19xZbcnF9HB3ycfFJmQS5Gr7eJ7riJKrWc and will use
it for the OpenBazaar multisignature fund.

Washington Sanchez:

Address: 19fQbq6egzREyDSt8R1zGPAFoR1THWSV4g
Uncompressed Pubic Key:
Message: This is Washington, confirming that I own this address.

Dionysis Zindros:

Address: 1HA6tFUGQrzrwGDDVp9dHivNRyhuT37dCh
Uncompressed Public Key:
Message: This is Dionysis Zindros, confirming that I own this address.

We invite the public to verify our signatures above.

(2) Multisig address migration

We are designating the following 2-of-4 multisig address for the storage of
OpenBazaar funds:


The address is constructed with the above 4 public keys. We invite the public
to check that the multisig address is a 2-of-4 address and that it is
constructed using the above 4 public keys. For verification purposes, the
bitcoin script is given below:


(3) Mandatory transparency

We have transfered all our funds to the multisig address and published it
to be used for donations. While we still have access to our old donations
address for donations coming from people who have stored it, we will be
using the new address for all donation purposes from now on. Any funds
donated to the old address will be immediately transfered to the multisig

We will make all our organizational payments directly from our multisig
address. We vow to publish the following information for every transaction
originating from our project multisig address from now on:

  • The recipient bitcoin address
  • The date of the transaction
  • The recipient actual name or company name
  • The reason for the expenses

In case of conversion to fiat currency, we will state the above data for the
recipient of the converted fiat currency.

We invite the public to verify our GPG signatures on the above announcement.

Brian Hofmann, Project Lead
Sam Patterson, Operations Lead
Washington Sanchez, Research Lead
Dionysis Zindros, Trust & Identity Developer

Please verify the authenticity of this message using GPG. Our public keys are available on popular keyservers.

Read More

OpenBazaar is now MIT licensed

We are happy to announce that we decided to release OpenBazaar under the MIT license.

OpenBazaar had previously been released under AGPL. After lengthy discussions on the matter, the team arrived at the consensus to move forward with relicensing under MIT.

We believe the MIT license will help us better achieve our vision of building a platform of free trade, where anyone can exchange goods and services via the Internet in an uncensored and privacy-respecting manner. We feel it is crucial to publish our code under a very permissive open source license in order to let people freely build software upon our platform as they see fit.

While we’re building the canonical OpenBazaar node software, we believe the power and accessibility of the OpenBazaar network will thrive through the use of a multitude of clients who have access to our secure, pseudonymous, and decentralized system of trade. We expect others to build both commercial and free clients that can access our network, leverage the versatility of the Ricardian contract system, utilize powerful blockchain-based transactions to ensure safety, and support their own systems with our trust and identity service.

By releasing under MIT, we are allowing these things to happen, and we hope this will, in turn, empower the OpenBazaar network to widen.

This is our way of saying we invite you to participate in our platform, whoever you may be. We hope this will encourage developers to start building code which makes use of these virtues and feel free to base it on our own code, so that, together, we can create a world where people can trade with freedom and safety.

Read More

Why proof-of-burn?

We’ve had many people commenting on our proof-of-burn scheme as the basis for our reputation pledge system which forms one of the core pillars of our identity and trust platform for OpenBazaar.

As previously explained on our blog, with proof-of-burn, you’ve invested resources that create an incentive to keep a good reputation and impose a significant cost for abandoning that reputation. This reputation is associated with your pseudonymous identity.

Some of the technical details behind these ideas are detailed on my paper, but read on if you want to see why we chose proof-of-burn instead of other alternatives.

People have expressed concerns about how the reputation pledging scheme alone is able to prevent us from fraud. I wanted to point out that we’re still in beta 1 and that we’re working hard to address all of these concerns: This reputation pledge system will not be used on its own. Our trust and identity system is far from complete, and we aim to combine several powerful tactics to achieve a system in which each node’s reputation is reliable. We’re researching ways to do this and we’re working on several drafts, including a web-of-trust, surety bonds, trust-as-risk, and other alternatives, which can be combined together to form a more powerful scheme and ensure safety on the network. We will publish more information and details on these schemes as they solidify. We understand that trust is a core component of a decentralized market, and we are making it our priority to build a truly free marketplace where people can be trusted even though pseudonymous.

There are two popular schemes that people are suggesting to us to use instead of proof-of-burn: These are proof-to-miner and proof-of-donation. We’ve heard about these suggestions on reddit and elsewhere. While we do like charities and wish we could donate burned money to them, this is simply not feasible, and the reasons are security-related and technical. The same applies to donating to miners, or others schemes in which funds are allocated at random. In fact, some people suggested that nodes acquire reputation by donating to the OpenBazaar development team itself, but again this has the same issues that I’m explaining below (although you can always donate directly :D).

The reason why a donation to a charity or a list of charities does not work (at least naively) is because it introduces a single-point-of-failure to the system. It is important to note here that our threat model is widely more paranoid than that employed by traditional e-shops. We aim to protect buyer and seller privacy and make the market impossible to censor by governments, big corporations, or other powerful agents. In this endeavor, one possible enemy is a malicious government which, through its legal system, issues a, perhaps secret, warrant which aims to shut down or otherwise disrupt the market. This is something we want to guard against, as we’ve seen it used again and again against various pieces of software that contained centralized components. We simply do not wish to rely on law to ensure the privacy and trustworthiness of our system. The way to guard against such attacks is through true decentralization.

When a charity or the OpenBazaar development team is receiving the funds of reputation pledges, this means that the people holding the private keys to the funds have the ability to centrally control the OpenBazaar network and break its security. Assume we decided to use reputation pledges to fund OpenBazaar development (a similar argument exists for charities). In this case, a malicious government who wishes to circumvent our security, must follow these steps:

  1. First, create an OpenBazaar market.
  2. Then, issue a secret warrant against the OpenBazaar developers asking them to forfeit their private keys. In multisig cases, ask for all the private keys.
  3. Subsequently, donate some amount X to the OpenBazaar development team in a “reputation pledging” move.
  4. Use the private keys obtained in step 2 to access the funds “pledged” and move it back to your own address. No money has been spent to do this.
  5. Repeat ad infinitum.

By following these steps, the malicious party can arbitrarily increase the reputation of any node they choose. One easy way to disrupt the market is then to randomly choose nodes on the network and increase their reputation arbitrarily, rendering our reputation system completely useless. In fact, the malicious agent in this case can increase reputation as much as they want instantaneously.

In case a proof-to-miner scheme is used, a malicious party can act to disrupt the market even without the legal power of warrants. The malicious party in this case can be any miner, even with little mining power. In this scheme, the malicious miner follows these steps:

  1. First, create an OpenBazaar market.
  2. Then, create a proof-to-miner transaction with some amount X which is a “reputation pledge” for your identity towards miners, but keep it secret.
  3. Start mining the next block, and include your secret transaction in your attempt.
  4. If you mine successfully, you’ve acquired reputation. No money has been spent to do this, as they are “donated” back to you. In this case, publish your secret transaction to the network.
  5. If you fail to mine this block, double-spend the amount from the secret transaction in a new reputation pledge attempt. The network won’t see the double-spending, as the first transaction remains secret.
  6. Repeat ad infinitum.

Again, a miner would be able to create an arbitrary amount of reputation for any node they choose and disrupt the network. However, in this case, the rate at which a miner can generate reputation is proportional to the money they own multiplied by their mining power.

As you can see, these naïve attempts to avoid proof-of-burn are unsuccessful. However, there have been several alternative suggestions, and we welcome your opinion in designing our schemes. While more complicated ideas are welcome and we are happy to discuss them, one of our priorities is to have a usable yet secure product by the end of the year, and some of these schemes are simply not feasible to implement in such a short timeframe; let’s keep in mind that shorter code means code that is easier to review and audit for security issues, and we want trust-related code to be thoroughly audited for security.

It seems that many people feel uncomfortable burning coins, and I wish to address their concerns in this post. As Vitalik Butern of Ethereum points out:

The destruction of BTC does not translate into a destruction of economic value; the value simply gets redistributed proportionately among everyone else. Hence, the protocols are actually efficient (i.e. not wasteful).

Or, to quote Satoshi Nakamoto:

Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone.

The best and simplest explanation as to why value is not lost comes from /u/Amanojack:

There seems to be a widespread perception that destroying coins is somehow related to destroying wealth. It’s just a name; nothing is actually being destroyed in terms of real world wealth or purchasing power, but just being moved around. Proof of burn is actually proof of donation (to every other bitcoin holder, in proportion to how many bitcoins each person holds).

Money is just a form of memory: it records, either in a low-tech way (gold/paper) or high-tech way (Bitcoin), who did what for whom in society. It’s a kind of favor-voucher that you give to people who did something for you and you receive when you do something for someone else. Destroying your favor-vouchers of course doesn’t hurt anyone else; in fact it makes everyone else’s worth more. There are now fewer vouchers chasing the same amount of available favors (goods and services) in society, since one person – the voucher burner – was nice enough to throw away his right to collect goods and services from others.

With these schemes, it will be the first time it becomes possible to trust truly pseudonymous individuals without the need of trusting any authority or centralized system. While we’re very excited to address these issues, they are hard problems that require experimentation, thorough security reviews and auditing, as well as theoretical work as their foundation, so all of this requires time to mature. We ask for your patience as we build this system and further explore its possibilities.

We’re looking forward to building a market where sellers and buyers can trade safely, in which trust can be established between transacting parties by the network without sacrificing any anonymity. We want people to feel secure in their transactions, so that they can finally trade online with privacy and freedom.

Read More