Re: [bitcoin-dev] RFC for BIP: Best Practices for Heterogeneous Input Script Transactions
I've updated the language of the BIP. New version: BIP: TBD Title: Best Practices for Heterogeneous Input Script Transactions Author: Kristov Atlas <kris...@openbitcoinprivacyproject.org> Status: Draft Type: Informational Created: 2016-02-10 ==Abstract== The privacy of Bitcoin users with respect to graph analysis is reduced when a transaction is created that contains 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 user protection protocols. ==Copyright== This BIP is in the public domain. ==Definitions== * '''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 existing unspent output * '''Intentional heterogenous input script transaction''': An HIT created as part of a user protection protocol for reducing uncontrolled disclosure of personally-identifying information (PII) ==Motivations== The recommendations in this document are designed to accomplish three goals: # Maximise the effectiveness of user-protecting protocols: Users may find that protection protocols are counterproductive if such transactions have a distinctive fingerprint which renders them ineffective. # Minimise the adverse 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. # 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 while maximising the effectiveness of both in terms of preventing uncontrolled disclosure of PII. In order to achieve this, two forms of HIT are proposed: Standard form and alternate form. ==Standard form heterogenous input script transaction== ===Rules=== An HIT is Standard form if it adheres to all of the following rules: # The number of unique output scripts must be equal to the number of unique inputs scripts (irrespective of the number of inputs and outputs). # All output scripts must be unique. # At least one pair of outputs must be of equal value. # The largest output in the transaction is a member of a set containing at least two identically-sized outputs. ===Rationale=== The requirement for equal numbers of unique input/output scripts instead of equal number of inputs/outputs accommodates user-protecting 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 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 in an intentional HIT to be of equal value results in optimal behavior, and causes intentional HITs to resemble unavoidable HITs. ==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: ===Procedure=== # Find the smallest combination of inputs whose value is at least the value of the desired spend. ## Add these inputs to the transaction. ## Add a spend output to the transaction. ## Add a change output to the transaction containing the difference between the current set of inputs and the desired
[bitcoin-dev] segwit subsidy and multi-sender (coinjoin) transactions
Has anyone thought about the effects of the 75% Segregated Witness subsidy on CoinJoin transactions and CoinJoin-like transactions? Better yet, has anyone collected data or come up with a methodology for the collection of data? >From this link: https://bitcoincore.org/en/2016/01/26/segwit-benefits/ "Segwit improves the situation here by making signature data, which does not impact the UTXO set size, cost 75% less than data that does impact the UTXO set size. This is expected to encourage users to favour the use of transactions that minimise impact on the UTXO set in order to minimise fees, and to encourage developers to design smart contracts and new features in a way that will also minimise the impact on the UTXO set." My expectation from the above is that this will serve as a financial disincentive against CoinJoin transactions. However, if people have evidence otherwise, I'd like to hear it. I noticed jl2012 objected to this characterization here, but has not yet provided evidence: https://www.reddit.com/r/Bitcoin/comments/4gyhsj/what_are_the_impacts_of_segwits_75_fee_discount/d2lvxmw A sample of the 16 transaction id's posted in the JoinMarket thread on BitcoinTalk shows an average ratio of 1.38 or outputs to inputs: https://docs.google.com/spreadsheets/d/1p9jZYXxX1HDtKCxTy79Zj5PrQaF20mxbD7BAuz0KC8s/edit?usp=sharing As we know, a "traditional" CoinJoin transaction creates roughly 2x UTXOs for everyone 1 it consumes -- 1 spend and 1 change -- unless address reuse comes into play. Please refrain from bringing up Schnorr signatures in your reply, since they are not on any immediate roadmap. Thanks, Kristov ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] RFC for BIP: Best Practices for Heterogeneous Input Script Transactions
BIP: TBD Title: Best Practices for Heterogeneous Input Script Transactions Author: Kristov Atlas <kris...@openbitcoinprivacyproject.org> Status: Draft Type: Informational Created: 2016-02-10 # Abstract 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. # Copyright This BIP is in the public domain. # Definitions 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 CoinJoin # Motivations 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. 2. 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. 3. 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 ## Rules 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). 2. All output scripts must be unique. 3. At least one pair of outputs must be of equal value. 4. The largest output in the transaction is a member of a set containing at least two identically-sized outputs. ## Rationale 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 fo
Re: [bitcoin-dev] Open Bitcoin Privacy Protect Privacy Questionnaire, Mid-Year 2015 report
Hi Wei, As you know, I'm not a developer of Bitcoin-Qt, but we'll need to make our best guesses for these answers if the developers won't reply. I'm going to post my best guesses here so that people reading the list have a short window of opportunity to correct me if they wish. On Fri, Aug 7, 2015 at 2:46 PM, Wei via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Transaction Formatting 1. Does your application take any steps to create ambiguity between transactions which unavoidably spend from multiple addresses at the same time and intentional mixing transactions? No, Bitcoin-Qt does not try to make non-mixing transactions look like mixing transactions. 2. What algorithms does your application use for ordering inputs and outputs in a transaction? In particular, how do you handle the change output and do you take into account common practices of other wallet applications when determining ordering? Not yet BIP 69. These notes suggest that outputs are randomized: https://bitcoin.org/en/release/v0.8.1 3. Does your application minimize the harmful effects of address reuse by spending every spendable input (“sweeping”) from an address when a transaction is created? Unknown 4. Does your application fully implement BIP 62? Here's a detailed answer on stack exchange: http://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented By item, my extremely brief interpretation: Non-DER encoded ECDSA signatures: BIP66 soft fork has happened, so this is presumed to be implemented Non-push operations in scriptSig: Implemented Push operations in scriptSig of non-standard size type: Implemented in 0.9.0 Zero-padded number pushes: Implemented in 0.10.0 (current available version is 0.11.0) Inherent ECDSA signature malleability: ...implemented? Superfluous scriptSig operations: implemented 0.6.0 Inputs ignored by scripts: Only partly addressed by 0.10.0. It appears that the rest would require changes to consensus rules, so Bitcoin-Qt is as compliant as it can be. Sighash flags based masking and New signatures by the sender: Can't be implemented without changes to consensus rules. I would summarize this as a yes. Mixing 5. If your application supports mixing: It doesn't. There's an issue for CoinJoin here: https://github.com/bitcoin/bitcoin/issues/3226 a. What is the average number of participants a user can expect to interact with on a typical join transaction? b. Does your application attempt to construct join transactions in a way that avoids distinguishing them from non-join transactions? c. Does your application perform any kind of reversibility analysis on join transactions prior to presenting them to the user for confirmation? d. Is the mixing technique employed secure against correlation attacks by the facilitator, such as a CoinJoin server or off-chain mixing service? e. Is the mixing technique employed secure against theft of funds by the facilitator or its participants? Donations 6. If your application has a fee or donation to the developers feature: No donation feature last time I checked. a. What steps do you take to make the donations indistinguishable from regular spend in terms of output sizes and destination addresses? Balance Queries and Tx Broadcasting 7. Please describe how your application obtains balance information in terms of how queries from the user’s device can reveal a connection between the addresses in their wallet. a. Does the application keep a complete copy of the blockchain locally (full node)? Yes b. Does the user’s device provide a filter which matches some fraction of the blockchain while providing a false positive rate (bloom or prefix filters)? No, it just downloads the whole blockchain and performs local queries. i. If so, approximately what fraction of the blockchain does the filter match in a default configuration (0% - 100%)? 100%, unless a user bootstraps downloading the blockchain. Bootstrapping will potentially limit the user's anonymity set to other people who have downloaded that bootstrap.dat file. c. Does the user’s device query all of their addresses at the same time? N/A d. Does the user’s device query addresses individually in a manner that does not allow the query responder to correlate queries for different addresses? No. Just download blocks and processes that information locally. e. Can users opt to obtain their balance information via Tor (or equivalent means)? If Tor is set up as a SOCKS proxy, you can configure Bitcoin-QT download the blockchain and broadcast txs through a single Tor circuit. This can be configured once before opening Bitcoin-Qt. 8. Does the applications route outgoing transactions independently from the manner in which it obtains balance information? Can users opt to have
Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
Hi Justus, What are the potential applications for this BIP? -Kr On Jun 30, 2015 1:53 PM, Justus Ranvier justus.ranv...@monetas.net wrote: Monetas has developed a Bitmessage address derivation method from an HD seed based on BIP-43. https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki We're proposing this as a BIP per the BIP-43 recommendation in order to reserve a purpose code. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
