Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.181 as permitted sender)
	client-ip=209.85.212.181; envelope-from=laanwj@gmail.com;
	helo=mail-wi0-f181.google.com; 
Date: Sat, 6 Jun 2015 10:24:48 +0200
From: "Wladimir J. van der Laan" <laanwj@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Message-ID: <20150606082447.GA12749@amethyst.visucore.com>
References: <87k2vhfnx9.fsf@rustcorp.com.au>
	<CAOG=w-sfpgciy9AzmtjEU5-uZY5KCAuS-SGsbff81w1dGVyBPg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOG=w-sfpgciy9AzmtjEU5-uZY5KCAuS-SGsbff81w1dGVyBPg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering
 in transactions
Precedence: list

On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote:
> 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...

But in that case (unconstrained) randomization can't be used either. This is posed as an alternative to randomization. So in that regard, the proposal still makes sense.
I think this move to verifyable, deterministic methods where possible is good.

Wladimir