MIME-Version: 1.0
In-Reply-To: <87k2vhfnx9.fsf@rustcorp.com.au>
References: <87k2vhfnx9.fsf@rustcorp.com.au>
Date: Fri, 5 Jun 2015 21:46:17 -0700
Message-ID: <CAOG=w-sfpgciy9AzmtjEU5-uZY5KCAuS-SGsbff81w1dGVyBPg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: multipart/alternative; boundary=90e6ba6e8642e2ede90517d216a6
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering
 in transactions
Precedence: list

--90e6ba6e8642e2ede90517d216a6
Content-Type: text/plain; charset=UTF-8

Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
assurance contracts among other things. Sometimes the ordering is set by
the signing logic itself...
On Jun 5, 2015 9:43 PM, "Rusty Russell" <rusty@rustcorp.com.au> wrote:

> Title: Canonical Input and Output Ordering
> Author: Rusty Russell <rusty@rustcorp.com.au>
> Discussions-To: "Bitcoin Dev" <bitcoin-development@lists.sourceforge.net>
> Status: Draft
> Type: Standards Track
> Created: 2015-06-06
>
> Abstract
>
> This BIP provides a canonical ordering of inputs and outputs when
> creating transactions.
>
> Motivation
>
> Most bitcoin wallet implementations randomize the outputs of
> transactions they create to avoid trivial linkage analysis (especially
> change outputs), however implementations have made mistakes in this area
> in the past.
>
> Using a canonical ordering has the same effect, but is simpler, more
> obvious if incorrect, and can eventually be enforced by IsStandard() and
> even a soft-fork to enforce it.
>
> Specification
>
> Inputs should be ordered like so:
>         index (lower value first)
>         txid (little endian order, lower byte first)
>
> Outputs should be ordered like so:
>         amount (lower value first)
>         script (starting from first byte, lower byte first, shorter wins)
>
> Rationale
>
> Any single wallet is already free to implement this, but if other
> wallets do not it would reduce privacy by making those transactions
> stand out.  Thus a BIP is appropriate, especially if this were to
> become an IsStandard() rule once widely adopted.
>
> Because integers are fast to compare, they're sorted first, before the
> lexographical ordering.
>
> The other input fields do not influence the sort order, as any valid
> transactions cannot have two inputs with the same index and txid.
>
> Reference Implementation
>
> https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--90e6ba6e8642e2ede90517d216a6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Rusty, this doesn&#39;t play well with SIGHASH_SINGLE which =
is used in assurance contracts among other things. Sometimes the ordering i=
s set by the signing logic itself...</p>
<div class=3D"gmail_quote">On Jun 5, 2015 9:43 PM, &quot;Rusty Russell&quot=
; &lt;<a href=3D"mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>&gt=
; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Title: Cano=
nical Input and Output Ordering<br>
Author: Rusty Russell &lt;<a href=3D"mailto:rusty@rustcorp.com.au">rusty@ru=
stcorp.com.au</a>&gt;<br>
Discussions-To: &quot;Bitcoin Dev&quot; &lt;<a href=3D"mailto:bitcoin-devel=
opment@lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a>=
&gt;<br>
Status: Draft<br>
Type: Standards Track<br>
Created: 2015-06-06<br>
<br>
Abstract<br>
<br>
This BIP provides a canonical ordering of inputs and outputs when<br>
creating transactions.<br>
<br>
Motivation<br>
<br>
Most bitcoin wallet implementations randomize the outputs of<br>
transactions they create to avoid trivial linkage analysis (especially<br>
change outputs), however implementations have made mistakes in this area<br=
>
in the past.<br>
<br>
Using a canonical ordering has the same effect, but is simpler, more<br>
obvious if incorrect, and can eventually be enforced by IsStandard() and<br=
>
even a soft-fork to enforce it.<br>
<br>
Specification<br>
<br>
Inputs should be ordered like so:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 index (lower value first)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 txid (little endian order, lower byte first)<br=
>
<br>
Outputs should be ordered like so:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 amount (lower value first)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 script (starting from first byte, lower byte fi=
rst, shorter wins)<br>
<br>
Rationale<br>
<br>
Any single wallet is already free to implement this, but if other<br>
wallets do not it would reduce privacy by making those transactions<br>
stand out.=C2=A0 Thus a BIP is appropriate, especially if this were to<br>
become an IsStandard() rule once widely adopted.<br>
<br>
Because integers are fast to compare, they&#39;re sorted first, before the<=
br>
lexographical ordering.<br>
<br>
The other input fields do not influence the sort order, as any valid<br>
transactions cannot have two inputs with the same index and txid.<br>
<br>
Reference Implementation<br>
<br>
<a href=3D"https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering=
" target=3D"_blank">https://github.com/rustyrussell/bitcoin/tree/bip-in-out=
-ordering</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>

--90e6ba6e8642e2ede90517d216a6--