<= /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)

* '''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

* '''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)

=3D= =3DMotivations=3D=3D

The recommendations in this d= ocument are designed to accomplish three goals:

# = 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.

# 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.

# 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.

<= br>

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.

In o= rder to achieve this, two forms of HIT are proposed: Standard form and alte= rnate form.

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

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

An HIT is Standard form if it adheres to all of th= e following rules:

# 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).

# 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 conta= ining 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/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.

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.

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.

=3D=3DAlternate form heterogenous input script transactions=3D= =3D

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

# 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.

# 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.

When one of the followi= ng 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 combinat= ion of inputs whose value is at least the value of the desired spend.

## Add these inputs to the transaction.

## Add a spend outpu= t to the transaction.

## Add a change output to the transaction c= ontaining 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 desi= red transaction fee.

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>

=3D=3DNon-compliant heterogenous input script transactions=3D=3D<= /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.

--001a113aa96264fd5205332a43cd--