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; 
From: Rusty Russell <rusty@rustcorp.com.au>
To: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <CAOG=w-sfpgciy9AzmtjEU5-uZY5KCAuS-SGsbff81w1dGVyBPg@mail.gmail.com>
References: <87k2vhfnx9.fsf@rustcorp.com.au>
	<CAOG=w-sfpgciy9AzmtjEU5-uZY5KCAuS-SGsbff81w1dGVyBPg@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1
	(x86_64-pc-linux-gnu)
Date: Sat, 06 Jun 2015 16:14:07 +0930
Message-ID: <87h9qlfia0.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering
	in transactions
Precedence: list

Mark Friedenbach <mark@friedenbach.org> writes:
> 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...

Ah, I forgot about that particular wart. Yech.  Implies that you can
order inputs or outputs, not both.

Something like "outputs must be in order, inputs which do not
CHECK(MULTI)SIG_(VERIFY) a SIGHASH_SINGLE sig must be in order with
respect to each other".  But that's much less trivial since it implies
script evaluation.

In other news, I noticed Kristov Atlas's concurrent proposal just after
I posted this (via reddit).  He used far more words, but didn't note
this issue either AFAICT.

Thanks!
Rusty.