From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z1604-00018Y-7e for bitcoin-development@lists.sourceforge.net; Sat, 06 Jun 2015 04:46:28 +0000 X-ACL-Warn: Received: from mail-ie0-f173.google.com ([209.85.223.173]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z15zz-00026c-LI for bitcoin-development@lists.sourceforge.net; Sat, 06 Jun 2015 04:46:28 +0000 Received: by iebmu5 with SMTP id mu5so35088300ieb.1 for ; Fri, 05 Jun 2015 21:46:18 -0700 (PDT) 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:cc:content-type; bh=FXnM1gFVrGfUh3/u7exlMvWfbvWxC8PZ5vuKE4x6hYM=; b=OpM4vXp/TTiSyt+k94qlW6BPzEOCIjajD5USboGDIAUSd1m3ib2eSjHW3q43DKFa0V mIJeeFuyvc2toeDWJ1+Ftl70cwvZTaHtX7O5l5Q2Fs5+keJGEVNQpHAVn+ZUe5Hn9fvl q1PnGokOPlieH71LOnvOwVJSSo08RXoi13U1NZUOp5z+Rx9axgYN27wWUs4alCddC6+9 NYbcjO9IpPcIBFLVnM8uY8WA3LTUok3LNc2vZkNJJ+ZLhRGQtjztIIBmPw2M8ATRl6Oa B+e3fUMwn+E6VZ9Ef5W/cBqxjxIgcYk/nLXnscd/f4QQeZ5NRxlFrxfdauC3FZEAu7f7 ka8g== X-Gm-Message-State: ALoCoQluttPp5e1+6dj5Asui+CznTLuiv5VaghAYZl0A48AvXvNgbuCdQPUldST4iWkz6b3Vj3Nz MIME-Version: 1.0 X-Received: by 10.42.176.8 with SMTP id bc8mr13778268icb.22.1433565978088; Fri, 05 Jun 2015 21:46:18 -0700 (PDT) Received: by 10.107.10.197 with HTTP; Fri, 5 Jun 2015 21:46:17 -0700 (PDT) X-Originating-IP: [172.56.17.6] Received: by 10.107.10.197 with HTTP; Fri, 5 Jun 2015 21:46:17 -0700 (PDT) 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: From: Mark Friedenbach To: Rusty Russell Content-Type: multipart/alternative; boundary=90e6ba6e8642e2ede90517d216a6 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Z15zz-00026c-LI Cc: Bitcoin Development Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 04:46:28 -0000 --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" wrote: > Title: Canonical Input and Output Ordering > Author: Rusty Russell > Discussions-To: "Bitcoin Dev" > 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

Rusty, this doesn'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...

On Jun 5, 2015 9:43 PM, "Rusty Russell"= ; <rusty@rustcorp.com.au>= ; wrote:
Title: Cano= nical Input and Output Ordering
Author: Rusty Russell <rusty@ru= stcorp.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:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 index (lower value first)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 txid (little endian order, lower byte first)
Outputs should be ordered like so:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 amount (lower value first)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 script (starting from first byte, lower byte fi= rst, 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.=C2=A0 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<= br> 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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--90e6ba6e8642e2ede90517d216a6--