OBPP Bitcoin Wallet Privacy Rating Report 2nd Edition

New OBPP Report Outlines Troubling State of Privacy in Bitcoin Wallets

New OBPP Report Outlines Troubling State of Privacy in Bitcoin Wallets submitted by kyletorpey to Bitcoin [link] [comments]

Are you a wallet developer or non-technical person looking to support privacy in Bitcoin? OBPP wants you to volunteer to rate wallets this summer.

Are you a wallet developer or non-technical person looking to support privacy in Bitcoin? OBPP wants you to volunteer to rate wallets this summer. submitted by catlasshrugged to Bitcoin [link] [comments]

OBPP Report Reveals Bitcoin Wallet Privacy Concerns

OBPP Report Reveals Bitcoin Wallet Privacy Concerns submitted by Blawpaw to btc [link] [comments]

New OBPP Report Outlines Troubling State of Privacy in Bitcoin Wallets

submitted by BitcoinAllBot to BitcoinAll [link] [comments]

New OBPP Report Outlines Troubling State of Privacy in Bitcoin Wallets

New OBPP Report Outlines Troubling State of Privacy in Bitcoin Wallets submitted by BTCNews to BTCNews [link] [comments]

OBPP Report Reveals Bitcoin Wallet Privacy Concerns

OBPP Report Reveals Bitcoin Wallet Privacy Concerns submitted by BitcoinAllBot to BitcoinAll [link] [comments]

OBPP Report Reveals Bitcoin Wallet Privacy Concerns

OBPP Report Reveals Bitcoin Wallet Privacy Concerns submitted by Blawpaw to Bitcoin [link] [comments]

Bitcoin Magazine: New OBPP Report Outlines Troubling State of Privacy in Bitcoin Wallets

Bitcoin Magazine: New OBPP Report Outlines Troubling State of Privacy in Bitcoin Wallets submitted by BobsBurgers3Bitcoin to btc [link] [comments]

OBPP Report Reveals Bitcoin Wallet Privacy Concerns

OBPP Report Reveals Bitcoin Wallet Privacy Concerns submitted by Blawpaw to CryptoCurrency [link] [comments]

RFC for BIP: Best Practices for Heterogeneous Input Script Transactions | Kristov Atlas | Feb 10 2016

Kristov Atlas on Feb 10 2016:
Title: Best Practices for Heterogeneous Input Script Transactions
Author: Kristov Atlas
Status: Draft
Type: Informational
Created: 2016-02-10


The privacy of Bitcoin users with respect to graph analysis is reduced when
a transaction is created that merges inputs composed from different
scripts. However, creating such transactions is often unavoidable.
This document proposes a set of best practice guidelines which minimize the
adverse privacy consequences of such unavoidable transaction situations
while simultaneously maximising the effectiveness of privacy-improving
techniques such as CoinJoin.


This BIP is in the public domain.


Heterogenous input script transaction (HIT): A transaction containing
multiple inputs where not all inputs have identical scripts (e.g. a
transaction spending from more than one Bitcoin address)
Unavoidable heterogenous input script transaction: An HIT created as a
result of a user’s desire to create a new output with a value larger than
the value of his wallet's largest unspent output
Intentional heterogenous input script transaction: An HIT created as part
of a protocol for improving user privacy against graph analysis, such as


The recommendations in this document are designed to accomplish three goals:
  1. Maximise the effectiveness of privacy-enhancing transactions:
Privacy-sensitive users may find that techniques such as CoinJoin are
counterproductive if such transactions have a distinctive fingerprint which
enables them to be censored or subjected to additional scrutiny.
  1. Minimise the adverse privacy consequences of unavoidable heterogenous
input transactions: If unavoidable HITs are indistinguishable from
intentional HITs, a user creating an unavoidable HIT benefits from
ambiguity with respect to graph analysis.
  1. Limiting the effect on UTXO set growth: To date, non-standardized
intentional HITs tend to increase the network's UTXO set with each
transaction; this standard attempts to minimize this effect by
standardizing unavoidable and intentional HITs to limit UTXO set growth.
In order to achieve these goals, this specification proposes a set of best
practices for heterogenous input script transaction creation. These
practices accommodate all applicable requirements of both intentional and
unavoidable HITs and render the two types indistinguishable to the maximum
extent possible.
In order to achieve this, two forms of HIT are proposed: Standard form and
alternate form.

Standard form heterogenous input script transaction


An HIT is Standard form if it adheres to all of the following rules:
  1. The number of unique output scripts must be equal to the number of
unique inputs scripts (irrespective of the number of inputs and outputs).
  1. All output scripts must be unique.
  2. At least one pair of outputs must be of equal value.
  3. The largest output in the transaction is a member of a set containing at
least two identically-sized outputs.


The requirement for equal numbers of unique input/output scripts instead of
equal number of inputs/outputs accommodates privacy-enhancing UTXO
selection behavior. Wallets may contain spendable outputs with identical
scripts due to intentional or accidental address reuse, or due to dusting
attacks. In order to minimise the adverse privacy consequences of address
reuse, any time a UTXO is included in a transaction as an input, all UTXOs
with the same spending script should also be included in the transaction.
The requirement that all output scripts are unique prevents address reuse.
Restricting the number of outputs to the number of unique input scripts
prevents this policy from growing the network’s UTXO set. A standard form
HIT transaction will always have a number of inputs greater than or equal
to the number of outputs.
The requirement for at least one pair of outputs to be of equal value
results in optimal join transactions, and causes intentional HITs to
resemble unavoidable HITs.
Outside controlled laboratory conditions, join transactions will not
involve identically-sized inputs due to a lack of accommodating volume.
Without the ability to cryptographically blind output values on the
blockchain, every join transaction leaks information in the form of output
sizes. Requiring a pair of identically sized outputs creates the desired
ambiguity for spend outputs, but in most cases makes change outputs
linkable to inputs.

Alternate form heterogenous input script transactions

The formation of a standard form HIT is not possible in the following cases:
The HIT is unavoidable, and the user’s wallet contains an insufficient
number or size of UTXOs to create a standard form HIT.
The user wishes to reduce the number of utxos in their wallet, and does not
have any sets of utxos with identical scripts.
When one of the following cases exist, a compliant implementation may
create an alternate form HIT by constructing a transaction as follows:


  1. Find the smallest combination of inputs whose value is at least the
value of the desired spend.
i. Add these inputs to the transaction.
ii. Add a spend output to the transaction.
iii. Add a change output to the transaction containing the difference
between the current set of inputs and the desired spend.
  1. Repeat step 1 to create a second spend output and change output.
  2. Adjust the change outputs as necessary to pay the desired transaction
Clients which create intentional HITs must have the capability to form
alternate form HITs, and must do so for a non-zero fraction of the
transactions they create.

Non-compliant heterogenous input script transactions

If a user wishes to create an output that is larger than half the total
size of their spendable outputs, or if their inputs are not distributed in
a manner in which the alternate form procedure can be completed, then the
user can not create a transaction which is compliant with this procedure.
A working draft of this document is here:
A few points of anticipated discussion:
  1. It's possible for a CoinJoin transaction to decrease privacy by adhering
to the Standard Form in this BIP, depending on the utxos available for
creating it. For example, a typical two-person CoinJoin might look like:
input_A, input_B => spend_A, change_A, spend_B, change_B
In order to comply with the standard form, one or more parties would have
to add inputs to make this something like:
input_A_1, input_A_2, input_B_1, input_B_2 => spend_A, change_A, spend_B,
If spend_A and spend_B are the same value, then input_A_1 and input_A_2 may
be linked based on the value of change_A and input_B_1 and input_B_2 may be
linked based on the value of change_B via sudoku analysis.
In that situation, wallets can opt to use the alternate form instead, or
stick with the standard form but enjoy a non-utxo set increase and a
significantly increased inter-transactional privacy set from other BIP
  1. In a naive simulation of a wallet randomly containing 1 to 10 utxos of
random value 1 to 10 and a desired spend of random value between 1 and the
sum of the utxos, the simulated wallet is able to create an alternate form
HIT 40% of the time. If we assume that half of all desire spends are a
value half or less of the total wallet balance, this improves to around
60%. Unfortunately, I don't have any good data on what values are found in
average wallets and what desired spends look like on average.
  1. In the long-run it's better for all clients to participant in
CoinJoin-like operations, but this should significantly increase the cost
and decrease the signal of passive blockchain analysis attacks until that
becomes feasible.
Thanks in advance for your feedback.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160210/56f223bb/attachment.html
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012434.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Open Bitcoin Privacy Project Spring 2015 Report | Justus Ranvier | May 18 2015

Justus Ranvier on May 18 2015:
Hash: SHA1
We're produced the first in what we hope to be a long series of
reviews of Bitcoin wallet privacy features, available here:
Specifically from the readers of this list, we are very interested in
feedback regarding our privacy threat model and the rating criteria we
derive from it.
Threat model:
Please send any suggestions or corrections via a GitHub issue to the
wallet-ratings repository so that we can incorporate it into future
Justus Ranvier
Open Bitcoin Privacy Project
justus at openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18381 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150518/fd9f9a2c/attachment.bin>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008193.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Request for Comment: Bitcoin Wallet Privacy Ratings Criteria | Kristov Atlas | Jan 20 2015

Kristov Atlas on Jan 20 2015:
The Open Bitcoin Privacy Project is seeking public comment on our ratings
criteria for Bitcoin wallet privacy. Please provide your feedback within
the next week through Jan 23, 2015 to ensure that it will be considered for
version 1.0 of the document.
In conjunction with a scoring matrix that will determine the weight of each
sub-category, this criteria will be used to evaluate and score a variety of
Bitcoin wallets, which will be published on our website at
Feedback through this mailing list is, of course, welcome; if you have a
GitHub account, this is the preferred medium for proposing changes to the
The current version of the criteria was authored by myself, as well as
other OBPP members including Justus Ranvier (Monetas), Chris Pacia (Bitcoin
Authenticator), and Samuel Patterson (Open Bazaar).
Thank you in advance for your feedback,
Kristov Atlas
kristovatlas at gmail.com
author at anonymousbitcoinbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150120/994fedb5/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007152.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Bitcoin Wallet ✅ How To Withdraw Bitcoin From Cash App To A Different Wallet How to create Bitcoin wallet How To Buy Bitcoin On Cash App Then Send To A Digital Wallet ✅ How to Set Up Cash App Bitcoin Wallet Tutorial

The Airbitz Bitcoin wallet, first released in early 2014, is a light client available for mobile devices The mobile app features sending and receiving functionality, the ability to record transaction details, and a bitcoin merchant directory that allows users to search for nearby bitcoin-accepting businesses Much of the Bitcoin-specific code is Dismiss Join GitHub today. GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together. Improvements are desperately needed to keep Bitcoin independent and safe. If you’re like me, and you want to see more progress in this area in 2016, it’s time to vote with your wallet. Let companies know that you care about privacy, and choose the wallets that respond to this demand.… Coinbase Places Last Again. Coinbase is the service that placed last in the OBPP's original review of Bitcoin wallets in the spring of last year, and the a16z-backed company has taken the bottom - Bitcoin wallet client privacy reports - An ever-evolving Bitcoin wallet client threat model - Gathering and visualizing blockchain privacy statistics - Collaboration on proposals to improve Bitcoin privacy, such as BIP-47 and BIP-69 - Ongoing support for Bitcoin wallets and services seeking advice on improving their privacy - An open Wiki

[index] [16057] [30120] [17836] [18028] [24013] [28967] [12089] [22074] [18436] [22714]

Bitcoin Wallet

How To Use A Bitcoin Hardware Wallet: Ledger Nano X - Duration: 39:02. BTC Sessions 39,876 views. 39:02. Using Cash App To Fund Broker Accounts - Duration: 8:34. Nes Vquez 18,225 views. Best Bitcoin Wallet 2020: Safest Cryptocurrency Hardware Wallet? (Better than Ledger & Trezor?) - Duration: 31:00. Crypto Casey Recommended for you. 31:00. How to Set Up Cash App Bitcoin Wallet Tutorial With Cash App there are only a few functions for Bitcoin. However, the Cash App Bitcoin wallet does allow for with buying, selling, and withdrawing. To verify your Bitcoin Wallet on Cash App, it takes about 24 hours, then you can follow this video to withdrawal your Bitcoin to another wallet like Coinbase. ----- Get in touch! email ... You may be wondering, so that someone can send you bitcoin into your wallet in Cash App. Unfortunately, Cash App does not have a wallet address that allows you to accept Bitcoin in your wallet.

Flag Counter