Received-SPF: pass (sog-mx-3.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: Jorge =?utf-8?Q?Tim=C3=B3n?= <jtimon@jtimon.cc>
In-Reply-To: <CABm2gDpBn744G0AbWDYj5aXQ6XbRzfnLpS=3z6NoWosaseFAWQ@mail.gmail.com>
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>
	<CABm2gDpBn744G0AbWDYj5aXQ6XbRzfnLpS=3z6NoWosaseFAWQ@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1
	(x86_64-pc-linux-gnu)
Date: Tue, 16 Jun 2015 17:36:38 +0930
Message-ID: <87zj40cc1d.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering
	in transactions
Precedence: list

Jorge Tim=C3=B3n <jtimon@jtimon.cc> writes:
> 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)?

I have no idea what they are? :)

> 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 t=
he
> order looks random (or at least not cannonical in a recognisable way) to
> everyone else.

Yes, my plan B would be an informational bip with simple code,
suggesting a way to permute a transaction based on some secret.  No
point everyone reinventing the wheel, badly.

Cheers,
Rusty.