From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z15wB-0002oU-Rh for bitcoin-development@lists.sourceforge.net; Sat, 06 Jun 2015 04:42:27 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of ozlabs.org designates 103.22.144.67 as permitted sender) client-ip=103.22.144.67; envelope-from=rusty@ozlabs.org; helo=ozlabs.org; Received: from ozlabs.org ([103.22.144.67]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z15wA-0004Pc-0N for bitcoin-development@lists.sourceforge.net; Sat, 06 Jun 2015 04:42:27 +0000 Received: by ozlabs.org (Postfix, from userid 1011) id 9257214027F; Sat, 6 Jun 2015 14:42:18 +1000 (AEST) From: Rusty Russell To: "Bitcoin Dev" User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sat, 06 Jun 2015 14:12:10 +0930 Message-ID: <87k2vhfnx9.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.8 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record 0.8 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z15wA-0004Pc-0N Subject: [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:42:27 -0000 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