MIME-Version: 1.0
In-Reply-To: <20150606082447.GA12749@amethyst.visucore.com>
References: <87k2vhfnx9.fsf@rustcorp.com.au>
	<CAOG=w-sfpgciy9AzmtjEU5-uZY5KCAuS-SGsbff81w1dGVyBPg@mail.gmail.com>
	<20150606082447.GA12749@amethyst.visucore.com>
Date: Sat, 6 Jun 2015 02:45:23 -0700
Message-ID: <CAOG=w-v_wHdTEzRn2ej292c4x72C0d4bmp40wrGRmwMsXFi+EQ@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Wladimir <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b10ce478eee470517d644db
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering
 in transactions
Precedence: list

--047d7b10ce478eee470517d644db
Content-Type: text/plain; charset=UTF-8

Certainly, but I would drop discussion of IsStandard or consensus rules.
On Jun 6, 2015 1:24 AM, "Wladimir J. van der Laan" <laanwj@gmail.com> wrote:

> 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
>

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

<p dir=3D"ltr">Certainly, but I would drop discussion of IsStandard or cons=
ensus rules.</p>
<div class=3D"gmail_quote">On Jun 6, 2015 1:24 AM, &quot;Wladimir J. van de=
r Laan&quot; &lt;<a href=3D"mailto:laanwj@gmail.com">laanwj@gmail.com</a>&g=
t; 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">On Fri, =
Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote:<br>
&gt; Rusty, this doesn&#39;t play well with SIGHASH_SINGLE which is used in=
<br>
&gt; assurance contracts among other things. Sometimes the ordering is set =
by<br>
&gt; the signing logic itself...<br>
<br>
But in that case (unconstrained) randomization can&#39;t be used either. Th=
is is posed as an alternative to randomization. So in that regard, the prop=
osal still makes sense.<br>
I think this move to verifyable, deterministic methods where possible is go=
od.<br>
<br>
Wladimir<br>
</blockquote></div>

--047d7b10ce478eee470517d644db--