Re: [bitcoin-dev] RFC for BIP: Best Practices for Heterogeneous Input Script Transactions

["T. DeV D" <dev@samouraiwallet.com>]

[-- Attachment #1: Type: text/plain, Size: 6686 bytes --]

ACK

We have already started work on Coinjoin simulated transactions and are
very interested in working on an implementation of this proposal with a
view towards making wallet footprints less identifiable.

On Thu, May 19, 2016 at 5:18 AM, Kristov Atlas via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I've updated the language of the BIP. New version:
>
> <pre>
>   BIP: TBD
>   Title: Best Practices for Heterogeneous Input Script Transactions
>   Author: Kristov Atlas <kristov@openbitcoinprivacyproject.org>
>   Status: Draft
>   Type: Informational
>   Created: 2016-02-10
> </pre>
>
> ==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 spend.
> # Repeat step 1 to create a second spend output and change output.
> # Adjust the change outputs as necessary to pay the desired transaction
> fee.
>
> 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.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 

dev@samouraiwallet.com

PGP public key fingerprint:

ED1A 1280 DEFC A603 14CD  15BF 72B5 BACD FEDF 39D7

[-- Attachment #2: Type: text/html, Size: 8614 bytes --]