diff options
| author | Kristov Atlas <kristovatlas.lists@gmail.com> | 2016-05-19 00:18:15 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-05-19 04:18:17 +0000 |
| commit | df5af9e7b832a9b9e58d66412e0f3fddd4e1d62b (patch) | |
| tree | 9aeb32a5d35929daddf410793e6c531cf58227b9 | |
| parent | f984eeafc40b9bb281e160c998ab7639a6758ff6 (diff) | |
| download | pi-bitcoindev-df5af9e7b832a9b9e58d66412e0f3fddd4e1d62b.tar.gz pi-bitcoindev-df5af9e7b832a9b9e58d66412e0f3fddd4e1d62b.zip | |
Re: [bitcoin-dev] RFC for BIP: Best Practices for Heterogeneous Input Script Transactions
| -rw-r--r-- | 6b/468837af7863a705632ed5566c04b73a7d2937 | 308 |
1 files changed, 308 insertions, 0 deletions
diff --git a/6b/468837af7863a705632ed5566c04b73a7d2937 b/6b/468837af7863a705632ed5566c04b73a7d2937 new file mode 100644 index 000000000..0e793e9ac --- /dev/null +++ b/6b/468837af7863a705632ed5566c04b73a7d2937 @@ -0,0 +1,308 @@ +Return-Path: <kristovatlas.lists@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id E07BB256 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 19 May 2016 04:18:17 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com + [209.85.213.49]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D1FF71AD + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 19 May 2016 04:18:16 +0000 (UTC) +Received: by mail-vk0-f49.google.com with SMTP id c189so88042606vkb.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 18 May 2016 21:18:16 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to; + bh=7CtH+gLb7sO7ftA0NBzmTQQk+5pgaKa98+eJ3iBEfWM=; + b=nPIpvmMJNyKMUJEXvUoJeD4iBZDJPPgw5CLhF0sj4iRqAJp4vuAL6LTmMfp6FdIloX + ceywmM0oG2Q6X2aDWH3KhMJlm//c6xomgmPgFKgNgKQx/fleB4sjEuNn3mEco5uco7VK + 0ueMP82AgMmnDPzImOMx1vPQnN3PNMe0ZfG5gm7wRZWTDw4XS7pcgQ774jOHFAMK3s0H + aLWRfoVfzdoMjQ+bpZ7Gz9ihbOOKF46Yvanr5ahK6LEmfMgbOonBFocgKqFtqLj1cEKh + slJSybcJ5s6o6NxpYynEMCb2M7YgvzbwjjjXPVwajtYmhxsDo0kSALugCPY+T3eYQ+5W + 6rDg== +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=7CtH+gLb7sO7ftA0NBzmTQQk+5pgaKa98+eJ3iBEfWM=; + b=NUsWhpoZ+XrMQ9CCi9oGpjbItAtYPw15OvQhy8J6divsx3igcQrp4U9wuSSLeSnsxY + yPEAzKGO0qaqE15bDXELPPCs/sL6hi14AoS2BN94lUmJoAkg0KSDbPsgjIxlGTwzG2er + DVF///NciYP5oeMz3RvBBDHbPujOotQmaF3EKaTj0f/mkyn1mWDMCKtdouzfWmujRy0m + 76TMSR7tF7wO6043JX/Wguy2jKk5pvl1uxUuQK5LsQjevATR7CASHR8kwXRDKs35JK+d + zCK8srDMG87XlWK7t7hruMQdp5o2IfZDJ7/eSW2gPtodG0z9NfNEFVzDgnmI8//TjdE1 + EPkQ== +X-Gm-Message-State: AOPr4FX2VAQinC8NqCgH5vGCV0UvNyhykWgNMP45ThjoVZAKXhGj4NAj+MM0D7Ni7mWJYuY6WdRF40XD1uO5xg== +MIME-Version: 1.0 +X-Received: by 10.159.33.179 with SMTP id 48mr5339163uac.14.1463631495886; + Wed, 18 May 2016 21:18:15 -0700 (PDT) +Received: by 10.176.64.225 with HTTP; Wed, 18 May 2016 21:18:15 -0700 (PDT) +In-Reply-To: <CAGH37SKQ_Ny1WjgosNUvObkD0PSyKmLdt4ejHb4f-AM+n4LLUQ@mail.gmail.com> +References: <CAGH37SKQ_Ny1WjgosNUvObkD0PSyKmLdt4ejHb4f-AM+n4LLUQ@mail.gmail.com> +Date: Thu, 19 May 2016 00:18:15 -0400 +Message-ID: <CAGH37SLBesCESaAY60UUc=B=0szZjL1KS6=oqWDBeTbdYKqEfw@mail.gmail.com> +From: Kristov Atlas <kristovatlas.lists@gmail.com> +To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=001a113aa96264fd5205332a43cd +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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: Thu, 19 May 2016 10:15:02 +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 19 May 2016 04:18:18 -0000 + +--001a113aa96264fd5205332a43cd +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +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> + +=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 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. + +=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 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) + +=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 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. + +=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 at +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 standar= +d 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. + +=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 insuffi= +cient +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 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. + +--001a113aa96264fd5205332a43cd +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">I've updated the language of the BIP. New version:<div= +><br></div><div><div><pre></div><div>=C2=A0 BIP: TBD</div><div>=C2=A0= + Title: Best Practices for Heterogeneous Input Script Transactions</div><di= +v>=C2=A0 Author: Kristov Atlas <<a href=3D"mailto:kristov@openbitcoinpri= +vacyproject.org">kristov@openbitcoinprivacyproject.org</a>></div><div>= +=C2=A0 Status: Draft</div><div>=C2=A0 Type: Informational</div><div>=C2=A0 = +Created: 2016-02-10</div><div></pre></div><div><br></div><div>=3D=3DA= +bstract=3D=3D</div><div><br></div><div>The privacy of Bitcoin users with re= +spect to graph analysis is reduced when a transaction is created that conta= +ins inputs composed from different scripts. However, creating such transact= +ions is often unavoidable.</div><div><br></div><div>This document proposes = +a set of best practice guidelines which minimize the adverse privacy conseq= +uences of such unavoidable transaction situations while simultaneously maxi= +mising the effectiveness of user protection protocols.</div><div><br></div>= +<div>=3D=3DCopyright=3D=3D</div><div><br></div><div>This BIP is in the publ= +ic domain.</div><div><br></div><div>=3D=3DDefinitions=3D=3D</div><div><br><= +/div><div>* '''Heterogenous input script transaction (HIT)'= +'': A transaction containing multiple inputs where not all inputs h= +ave identical scripts (e.g. a transaction spending from more than one Bitco= +in address)</div><div>* '''Unavoidable heterogenous input scrip= +t transaction''': An HIT created as a result of a user=E2=80=99= +s desire to create a new output with a value larger than the value of his w= +allet's largest existing unspent output</div><div>* '''Inte= +ntional heterogenous input script transaction''': An HIT create= +d as part of a user protection protocol for reducing uncontrolled disclosur= +e of personally-identifying information (PII)</div><div><br></div><div>=3D= +=3DMotivations=3D=3D</div><div><br></div><div>The recommendations in this d= +ocument are designed to accomplish three goals:</div><div><br></div><div># = +Maximise the effectiveness of user-protecting protocols: Users may find tha= +t protection protocols are counterproductive if such transactions have a di= +stinctive fingerprint which renders them ineffective.</div><div># Minimise = +the adverse consequences of unavoidable heterogenous input transactions: If= + unavoidable HITs are indistinguishable from intentional HITs, a user creat= +ing an unavoidable HIT benefits from ambiguity with respect to graph analys= +is.</div><div># Limiting the effect on UTXO set growth: To date, non-standa= +rdized intentional HITs tend to increase the network's UTXO set with ea= +ch transaction; this standard attempts to minimize this effect by standardi= +zing unavoidable and intentional HITs to limit UTXO set growth.</div><div><= +br></div><div>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 intentiona= +l and unavoidable HITs while maximising the effectiveness of both in terms = +of preventing uncontrolled disclosure of PII.</div><div><br></div><div>In o= +rder to achieve this, two forms of HIT are proposed: Standard form and alte= +rnate form.</div><div><br></div><div>=3D=3DStandard form heterogenous input= + script transaction=3D=3D</div><div><br></div><div>=3D=3D=3DRules=3D=3D=3D<= +/div><div><br></div><div>An HIT is Standard form if it adheres to all of th= +e following rules:</div><div><br></div><div># The number of unique output s= +cripts must be equal to the number of unique inputs scripts (irrespective o= +f the number of inputs and outputs).</div><div># All output scripts must be= + unique.</div><div># At least one pair of outputs must be of equal value.</= +div><div># The largest output in the transaction is a member of a set conta= +ining at least two identically-sized outputs.</div><div><br></div><div>=3D= +=3D=3DRationale=3D=3D=3D</div><div><br></div><div>The requirement for equal= + numbers of unique input/output scripts instead of equal number of inputs/o= +utputs accommodates user-protecting UTXO selection behavior. Wallets may co= +ntain spendable outputs with identical scripts due to intentional or accide= +ntal address reuse, or due to dusting attacks. In order to minimise the adv= +erse consequences of address reuse, any time a UTXO is included in a transa= +ction as an input, all UTXOs with the same spending script should also be i= +ncluded in the transaction.</div><div><br></div><div>The requirement that a= +ll 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 standard form HIT transaction wi= +ll always have a number of inputs greater than or equal to the number of ou= +tputs.</div><div><br></div><div>The requirement for at least one pair of ou= +tputs in an intentional HIT to be of equal value results in optimal behavio= +r, and causes intentional HITs to resemble unavoidable HITs.</div><div><br>= +</div><div>=3D=3DAlternate form heterogenous input script transactions=3D= +=3D</div><div><br></div><div>The formation of a standard form HIT is not po= +ssible in the following cases:</div><div><br></div><div># The HIT is unavoi= +dable, and the user=E2=80=99s wallet contains an insufficient number or siz= +e of UTXOs to create a standard form HIT.</div><div># The user wishes to re= +duce the number of utxos in their wallet, and does not have any sets of utx= +os with identical scripts.</div><div><br></div><div>When one of the followi= +ng cases exist, a compliant implementation may create an alternate form HIT= + by constructing a transaction as follows:</div><div><br></div><div>=3D=3D= +=3DProcedure=3D=3D=3D</div><div><br></div><div># Find the smallest combinat= +ion of inputs whose value is at least the value of the desired spend.</div>= +<div>## Add these inputs to the transaction.</div><div>## Add a spend outpu= +t to the transaction.</div><div>## Add a change output to the transaction c= +ontaining the difference between the current set of inputs and the desired = +spend.</div><div># Repeat step 1 to create a second spend output and change= + output.</div><div># Adjust the change outputs as necessary to pay the desi= +red transaction fee.</div><div><br></div><div>Clients which create intentio= +nal HITs must have the capability to form alternate form HITs, and must do = +so for a non-zero fraction of the transactions they create.</div><div><br><= +/div><div>=3D=3DNon-compliant heterogenous input script transactions=3D=3D<= +/div><div><br></div><div>If a user wishes to create an output that is large= +r than half the total size of their spendable outputs, or if their inputs a= +re 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 w= +ith this procedure.</div></div><div><br></div></div> + +--001a113aa96264fd5205332a43cd-- + |