From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0791E42F for ; Mon, 23 May 2016 17:44:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com [209.85.192.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F2AEE172 for ; Mon, 23 May 2016 17:44:06 +0000 (UTC) Received: by mail-pf0-f176.google.com with SMTP id b124so9812556pfb.0 for ; Mon, 23 May 2016 10:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samouraiwallet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=ieYGNu/24MWkdmha4G79saBlf3b9STRQmvrogoSW7P8=; b=NKJAjVIE51+rP7nzN2H7h8W/3/2mv7EeXfjJ3A4lZjmDLqO1HziUfNdlVlTdSeSujz aNk8GASsYO/zUdHVUUwbaRyB2Tn+BYE7yKMRFdy3crd6qZaiTbkvceaWNTC4HB2ZaqyS 2qL6IAiv5J7GWod0dUo86a3GQImxvVe2UvZ7iWE8FZ+f7t+Clf3wADNvCgqUjjY0OQpO tDbkAJW8Tgcla/RH4+KDpNeTRr3udfdsIMUZiphGDj8EXVdMyMstC7QzPmRkPcluXQvG ytNLPCQE/BoO7tVu9mx3Qk4klAXyo+b5A7/tiAbT2pTV/d5s898M+gu5gIHgX6PcR7Tf YaZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=ieYGNu/24MWkdmha4G79saBlf3b9STRQmvrogoSW7P8=; b=XwsxlR7YlMeQcgI7aHvfHNFEH6zd1LKThXE2En6z1OPMvDawoLZu4+fDxBQh9aGvq+ k1yj3raps//Hw8LaHIl0oo5pSs6BysNpRJXlwsWBWEwHTUJ+W9KRomUoWeezQR3wX38o bn98UNtv8IXeehDx/mvkT35EZ19hdES/MdhPVcvL6yPEtocACdsC+P0mHYzorRFRsLNb 1d62tIKIpcEEwjba4QnfDUyJmyg4B44l1ps9uw1EuYdeyx+HMRFJL6E4ORFgdeAyJcM3 aNzibBv26bGAbXhlCFd25d7IlFRvJzmHgO6mWTLrZmOIM/x95Sz06ANbjvWWhIK+XI4Y Wqtw== X-Gm-Message-State: ALyK8tK2saFe+p0Ph1Cauq2BtUFT4qIXtZgi+zV0/Agb/arT5cIJChBdzUrEKrvBQpVtPGuK8OSzBpoCwSi1kQ== MIME-Version: 1.0 X-Received: by 10.98.55.195 with SMTP id e186mr148459pfa.12.1464025446087; Mon, 23 May 2016 10:44:06 -0700 (PDT) Received: by 10.66.100.228 with HTTP; Mon, 23 May 2016 10:44:05 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 May 2016 18:44:05 +0100 Message-ID: From: "T. DeV D" To: Kristov Atlas , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c0c035ea81554053385fc26 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 23 May 2016 20:46:43 +0000 Subject: Re: [bitcoin-dev] RFC for BIP: Best Practices for Heterogeneous Input Script Transactions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 17:44:09 -0000 --94eb2c0c035ea81554053385fc26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: > > 
>   BIP: TBD
>   Title: Best Practices for Heterogeneous Input Script Transactions
>   Author: Kristov Atlas 
>   Status: Draft
>   Type: Informational
>   Created: 2016-02-10
>
> > =3D=3DAbstract=3D=3D > > The privacy of Bitcoin users with respect to graph analysis is reduced > when a transaction is created that contains inputs composed from differen= t > 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 situatio= ns > while simultaneously maximising the effectiveness of user protection > protocols. > > =3D=3DCopyright=3D=3D > > This BIP is in the public domain. > > =3D=3DDefinitions=3D=3D > > * '''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=E2=80=99s desire to create a new output with a valu= e 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 disclosur= e > of personally-identifying information (PII) > > =3D=3DMotivations=3D=3D > > 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 bes= t > 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 an= d > alternate form. > > =3D=3DStandard form heterogenous input script transaction=3D=3D > > =3D=3D=3DRules=3D=3D=3D > > 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 a= t > least two identically-sized outputs. > > =3D=3D=3DRationale=3D=3D=3D > > 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=E2=80=99s UTXO set. A stand= ard 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 HIT= s > to resemble unavoidable HITs. > > =3D=3DAlternate form heterogenous input script transactions=3D=3D > > The formation of a standard form HIT is not possible in the following > cases: > > # The HIT is unavoidable, and the user=E2=80=99s wallet contains an insuf= ficient > 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: > > =3D=3D=3DProcedure=3D=3D=3D > > # 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. > > =3D=3DNon-compliant heterogenous input script transactions=3D=3D > > 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 i= n > 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 > > --=20 dev@samouraiwallet.com PGP public key fingerprint: ED1A 1280 DEFC A603 14CD 15BF 72B5 BACD FEDF 39D7 --94eb2c0c035ea81554053385fc26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ACK

We have already started work on Coi= njoin simulated transactions and are very interested in working on an imple= mentation of this proposal with a view towards making wallet footprints les= s identifiable.

On Thu, May 19, 2016 at 5:18 AM, Kristov Atlas via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr= ote:
I've updated th= e language of the BIP. New version:

<pre>
=C2=A0 BIP: TBD
=C2=A0 Title: Best Practi= ces for Heterogeneous Input Script Transactions
=C2=A0 Author: Kr= istov Atlas <kristov@openbitcoinprivacyproject.org>
=C2= =A0 Status: Draft
=C2=A0 Type: Informational
=C2=A0 Cre= ated: 2016-02-10
</pre>

=3D= =3DAbstract=3D=3D

The privacy of Bitcoin users wit= h respect to graph analysis is reduced when a transaction is created that c= ontains inputs composed from different scripts. However, creating such tran= sactions is often unavoidable.

This document propo= ses a set of best practice guidelines which minimize the adverse privacy co= nsequences of such unavoidable transaction situations while simultaneously = maximising the effectiveness of user protection protocols.

=3D=3DCopyright=3D=3D

Th= is BIP is in the public domain.

=3D=3DDefin= itions=3D=3D

* '''Heterogenous input s= cript transaction (HIT)''': A transaction containing multiple i= nputs where not all inputs have identical scripts (e.g. a transaction spend= ing from more than one Bitcoin address)
* '''Unavoida= ble heterogenous input script transaction''': An HIT created as= a result of a user=E2=80=99s desire to create a new output with a value la= rger than the value of his wallet's largest existing unspent output
* '''Intentional heterogenous input script transaction&#= 39;'': An HIT created as part of a user protection protocol for red= ucing uncontrolled disclosure of personally-identifying information (PII)

=3D=3DMotivations=3D=3D
=
The recommendations in this document are designed to accompl= ish three goals:

# Maximise the effectivene= ss of user-protecting protocols: Users may find that protection protocols a= re counterproductive if such transactions have a distinctive fingerprint wh= ich renders them ineffective.
# Minimise the adverse consequences= of unavoidable heterogenous input transactions: If unavoidable HITs are in= distinguishable from intentional HITs, a user creating an unavoidable HIT b= enefits 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 sta= ndard attempts to minimize this effect by standardizing unavoidable and int= entional HITs to limit UTXO set growth.

In order t= o achieve these goals, this specification proposes a set of best practices = for heterogenous input script transaction creation. These practices accommo= date all applicable requirements of both intentional and unavoidable HITs w= hile maximising the effectiveness of both in terms of preventing uncontroll= ed disclosure of PII.

In order to= achieve this, two forms of HIT are proposed: Standard form and alternate f= orm.

=3D=3DStandard form heterogenous input= script transaction=3D=3D

=3D=3D=3DRules=3D=3D=3D<= /div>

An HIT is Standard form if it adh= eres to all of the following rules:

# The n= umber of unique output scripts must be equal to the number of unique inputs= scripts (irrespective of the number of inputs and outputs).
# Al= l output scripts must be unique.
# At least one pair of outputs m= ust be of equal value.
# The largest output in the transaction is= a member of a set containing at least two identically-sized outputs.
=

=3D=3D=3DRationale=3D=3D=3D

Th= e requirement for equal numbers of unique input/output scripts instead of e= qual number of inputs/outputs accommodates user-protecting UTXO selection b= ehavior. Wallets may contain spendable outputs with identical scripts due t= o intentional or accidental address reuse, or due to dusting attacks. In or= der 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 preven= ts address reuse. Restricting the number of outputs to the number of unique= input scripts prevents this policy from growing the network=E2=80=99s UTXO= set. A standard form HIT transaction will always have a number of inputs g= reater than or equal to the number of outputs.

<= div>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 HI= Ts to resemble unavoidable HITs.

=3D=3DAlternate f= orm heterogenous input script transactions=3D=3D

The formation of a standard form HIT is not possible in the= following cases:

# The HIT is unavoidable,= and the user=E2=80=99s wallet contains an insufficient number or size of U= TXOs to create a standard form HIT.
# The user wishes to reduce t= he number of utxos in their wallet, and does not have any sets of utxos wit= h identical scripts.

When one of = the following cases exist, a compliant implementation may create an alterna= te form HIT by constructing a transaction as follows:

<= /span>
=3D=3D=3DProcedure=3D=3D=3D

# Find the = smallest combination of inputs whose value is at least the value of the des= ired 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 necessar= y 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 transac= tions they create.

=3D=3DNon-compliant hete= rogenous input script transactions=3D=3D

If a user wishes to create an output that is larger than half the t= otal size of their spendable outputs, or if their inputs are not distribute= d 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 procedur= e.


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev




-- 
<=
a href=3D"mailto:dev@samouraiwallet.com" style=3D"font-family:arial,sans-se=
rif;font-size:13px" target=3D"_blank">dev@samouraiwallet.com
PGP public key fingerprint:
ED1A 1280 DEFC A603 14CD  15BF 72B5 BACD FEDF 39D7





--94eb2c0c035ea81554053385fc26--