Skip to content

Latest commit

 

History

History
262 lines (256 loc) · 9.86 KB

criteria.md

File metadata and controls

262 lines (256 loc) · 9.86 KB
Raw

Bitcoin Wallet Privacy Ratings Criteria

This document outlines the OBPP criteria for rating the privacy strength of Bitcoin wallets. Each item represents an objectively-measurable test of how well a rated wallet implements countermeasures for the attacks identified in the [threat model](threat model.wiki). The result of each test is converted into a numeric score via a method decribed below or in the methodology.

Our metrics are based on feature completeness and user experience. To evaluate user experience, we utilize a "minimum number of clicks to perform action" metric. This metric is easily standardized between wallets, minimizes subjectivity, and can be measured by a single tester.

Each sub-category of privacy, such as "Change Address Generation," is broken down into between one and three areas of consideration, including usability, quality, and user feedback.

Criteria

  1. Receiving Addresses
    1. Generation
      1. Usability:
        1. Number of clicks required to deviate from the default receiving functionality and generate a new receiving address for an existing wallet (8.89%)
      2. Feedback:
        1. Receiving addresses are hidden from the default view once they have been used? (3.11%)
        2. Preemptively indicates a loss of privacy when user elects to receive funds at a previously-used addresses? (4.67%)
    2. Backup
      1. Usability:
        1. Number of clicks to backup a newly-generated receiving address from an existing wallet (worst case), from the default window/authenticated home page (1.39%)
      2. Quality:
        1. Does the backup process leak information about wallet addresses (e.g. each time a new change address is created on-demand, an email backup is triggered immediately)? (1.39%)
      3. Feedback:
        1. Indicates a reduction in wallet safety when receiving address backups are stale, or uses eternal backups? (1.11%)
  2. Change Addresses
    1. Generation
      1. Usability:
        1. Number of clicks required to deviate from the default change functionality and receive change at a newly generated address (5.95%)
      2. Quality:
        1. The position of the change output(s) in the transaction is random? (2,98%)
        2. One or more change outputs are created which are close to the value of the desired spend? (1.98%)
        3. Some change output values are intentionally set to “round numbers” (a.k.a low number of significant digits)? (0.99%)
      3. Feedback:
        1. Change addresses are hidden from the normal receiving workflow by default to discourage using them as receiving addresses? (1.90%)
        2. Preemptively indicates a loss of privacy when user elects to reuse change addresses as receiving addresses? (2.86%)
    2. Backup
      1. Usability:
        1. Number of clicks to backup a newly-generated change address from an existing wallet (worst case), apart from the sending workflow (1.39%)
      2. Quality:
        1. Backups can occur offline, or are encrypted client-side with data that only the user controls e.g. password? (1.39%)
      3. Feedback:
        1. Indicates a reduction in wallet safety when change address backups are stale, or uses eternal backups? (1.11%)
  3. Sender Privacy vs Blockchain Observers
    1. Mixing
      1. Usability:
        1. Number of clicks required by user for inputs/outputs to be mixed with one or more other users (2.38%)
      2. Quality:
        1. Average number of other users whose funds are mixed with yours when sending through a mixing process (0.79%)
        2. Mixing is secure against correlation attacks by the facilitator? (0.79%)
        3. Mixing is secure against theft of funds? (0.79%)
      3. Feedback:
        1. Warns the user when a proposed mix is easy to reverse? (1.90%)
    2. Address Reuse
      1. Feedback:
        1. Warns user when sending to an address that the user has sent to before? (3.89%)
    3. Input Merging
      1. Quality:
        1. When an outgoing transaction must merge inputs, and when mixing is not being used, is the transaction constructed in a way that plausibly resembles a mixing transaction? (3.33%)
      2. Feedback:
        1. Outside of a mixing transaction, preemptively indicates a loss of privacy when merging inputs from different addresses in the same transaction? (2.22%)
    4. Identity Separation
      1. Quality:
        1. Avoids creating transactions which contain inputs from different identity containers, except optionally if the user has intentionally overridden this behavior? (6.67%)
  4. Receiver Privacy
    1. ECDH Address Support
      1. Usability:
        1. Number of clicks required by user to generate a ECDH receiving address, from the default window/authenticated home page. (5.56%)
    2. Receiver Identity
      1. Quality:
        1. Wallet avoids leaking information about recipients via an external identity lookup? (5.56%)
  5. Sender Privacy vs Network Observers
    1. Balance Information
      1. Usability:
        1. Number of clicks required by user to connect to the source of balance information without leaking their identity over the network (3.97%)
      2. Quality:
        1. Is balance information obtained in a manner which avoids leaking the addresses in a wallet to network peers? (3.97%)
          • 100: Full node - the wallet is part of, or works with, a full node under the user’s exclusive control
          • 75: Carefully filtered - address filters are used, but filters are never updated and when a new one is required it is registered with a brand new peer
          • 50: Unsafely filtered - address filters are used, and they are updated or reuse peers.
          • 0: Unfiltered - Balance is obtained from a peer which can easily connect wallet addresses to a specific connection/wallet
      3. Feedback:
        1. Client provides a visual indication if the balance information is not being obtained through an anonymizing network, including IP address information? (3.17%)
    2. Outgoing Transactions
      1. Usability:
        1. Number of clicks required by user to route outgoing transactions through an anonymizing network (1.98%)
      2. Quality:
        1. Are outgoing transactions routed through a different entry point into the network than the source of balance information? (1.98%)
      3. Feedback:
        1. Client provides a visual indication if outgoing transactions are not being routed through an anonymizing network, including IP address information? (1.59%)
    3. Identity Separation
      1. Usability:
        1. Number of clicks to create a new identity container ( 1.32%)
        2. Number of clicks to assign an imported address to an identity container (0.66%)
      2. Quality:
        1. Avoids including addresses from multiple identity containers in the same address filter? (0.99%)
        2. Avoids broadcasting outgoing transactions from different identity containers via the same network access path? (0.99%)
      3. Feedback:
        1. Visually indicates to user when inputs from different accounts/pockets are merged before the transaction is broadcast, or prohibits this operation entirely?(1.59%)
    4. Operating System Support
      1. Usability:
        1. Compatible with latest version of Tails? (2.78%)
          • 100: Actually included in the Tails live cd
          • 75: Program and any dependencies are packaged into a single file which can be easily installed
          • 50: Installation is possible, but requires multiple complex steps
          • 0: WIll not run on Tails