MIME-Version: 1.0
In-Reply-To: <87eglcelf3.fsf@rustcorp.com.au>
References: <87k2vhfnx9.fsf@rustcorp.com.au>
	<CAAS2fgRgWZX_O_2O1bgdFd_04xVp5Lnpw4hf=v6RSTXmsbdzPQ@mail.gmail.com>
	<87r3pdembs.fsf@rustcorp.com.au>
	<CAAS2fgTY5cqwj5XuKtkD8Z8N1vF=PZMba8EtGkbWnEackOcN8Q@mail.gmail.com>
	<CAOG=w-tJjzrR_REJOShULfSO=T3ueHko-oQHdhqMCdZD0G_BDA@mail.gmail.com>
	<87eglcelf3.fsf@rustcorp.com.au>
Date: Tue, 16 Jun 2015 09:10:17 +0200
Message-ID: <CABm2gDpBn744G0AbWDYj5aXQ6XbRzfnLpS=3z6NoWosaseFAWQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: multipart/alternative; boundary=001a11c260e23a1d1205189d4484
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering
 in transactions
Precedence: list

--001a11c260e23a1d1205189d4484
Content-Type: text/plain; charset=UTF-8

On Jun 15, 2015 11:43 PM, "Rusty Russell" <rusty@rustcorp.com.au> wrote:

> Though Peter Todd's more general best-effort language might make more
> sense.  It's not like you can hide an OP_RETURN transaction to make it
> look like something else, so that transaction not going to be
> distinguished by non-canonical ordering.

What about commitments that don't use op_return (ie pay2contract
commitments)?

In any case, if the motivation is ordering in multi-party transactions
there should be ways to do it without any consequences for other
transaction types' privacy. For example you could have a deterministic
method that depends on a random seed all parties in the transaction
previously share. That way the ordering is deterministic for all parties
involved in the transaction (which can use whatever channel they're using
to send the parts to also send this random seed) while at the same time the
order looks random (or at least not cannonical in a recognisable way) to
everyone else.

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

<p dir=3D"ltr"><br>
On Jun 15, 2015 11:43 PM, &quot;Rusty Russell&quot; &lt;<a href=3D"mailto:r=
usty@rustcorp.com.au">rusty@rustcorp.com.au</a>&gt; wrote:<br></p>
<p dir=3D"ltr">&gt; Though Peter Todd&#39;s more general best-effort langua=
ge might make more<br>
&gt; sense.=C2=A0 It&#39;s not like you can hide an OP_RETURN transaction t=
o make it<br>
&gt; look like something else, so that transaction not going to be<br>
&gt; distinguished by non-canonical ordering.</p>
<p dir=3D"ltr">What about commitments that don&#39;t use op_return (ie pay2=
contract commitments)?</p>
<p dir=3D"ltr">In any case, if the motivation is ordering in multi-party tr=
ansactions there should be ways to do it without any consequences for other=
 transaction types&#39; privacy. For example you could have a deterministic=
 method that depends on a random seed all parties in the transaction previo=
usly share. That way the ordering is deterministic for all parties involved=
 in the transaction (which can use whatever channel they&#39;re using to se=
nd the parts to also send this random seed) while at the same time the orde=
r looks random (or at least not cannonical in a recognisable way) to everyo=
ne else.<br>
</p>

--001a11c260e23a1d1205189d4484--