Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jtimon@jtimon.cc>) id 1Z6ZfJ-0004Nm-QC
	for bitcoin-development@lists.sourceforge.net;
	Sun, 21 Jun 2015 07:27:41 +0000
Received: from mail-wi0-f176.google.com ([209.85.212.176])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z6ZfH-0003vL-Ie
	for bitcoin-development@lists.sourceforge.net;
	Sun, 21 Jun 2015 07:27:41 +0000
Received: by wiwl6 with SMTP id l6so11179239wiw.0
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 21 Jun 2015 00:27:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=Bg63In6zxqyHbiYZ/tQLY8fUPCQzaM0iNED0BaeKals=;
	b=R6RDtC7IjFgaHLKxfjp8yYgLW9YGku8NpJtVP4RPJ1MjLz66YhPPzu7xoFzbqKEYxG
	MDwfTb4vzU0AFwNxchJ1qWgg6wydIeQ4vvq6VnC8cseuPfgkM5YkfiaShqiebSLEKdyS
	pzESMwZQGh4VmxQb14Ci69+UtKa6y5mCqGAnq/EG4ks5818Y4+Ha7DTleE6xHTAop2Vq
	SwsFvUO4L+Y2wXENnl+GHDRG5M7oC3ezp113mYaz/dAR1nH97/hZAYZZEklZPicLZBBp
	NcF0LpZndrfvWAS9qPlrYG3Yab43OzuoU1bQMbHlUbSMdXI0q5IIOcO2mAkCF3cT6HcY
	fZEQ==
X-Gm-Message-State: ALoCoQk7Zwbgn09tQdyFlK51t55bdfcfAx7/gJ57mX8utUxXZk2Hy4VjTz36izTRG7sNWQuB+l70
MIME-Version: 1.0
X-Received: by 10.194.120.198 with SMTP id le6mr41094878wjb.133.1434871653448; 
	Sun, 21 Jun 2015 00:27:33 -0700 (PDT)
Received: by 10.194.139.235 with HTTP; Sun, 21 Jun 2015 00:27:33 -0700 (PDT)
Received: by 10.194.139.235 with HTTP; Sun, 21 Jun 2015 00:27:33 -0700 (PDT)
In-Reply-To: <CABm2gDpkwHvrsB8Dh-hsO6H9trcweEX9XGB5Jh5KLPsPY5Z1Sw@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>
	<87zj40cc1d.fsf@rustcorp.com.au>
	<CABm2gDpkwHvrsB8Dh-hsO6H9trcweEX9XGB5Jh5KLPsPY5Z1Sw@mail.gmail.com>
Date: Sun, 21 Jun 2015 09:27:33 +0200
Message-ID: <CABm2gDoq-nxqGYkYVh0YJQ8p5noLMKrEGuvJmRXU9FYs42ma2g@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0116000233d6dc05190217e7
X-Spam-Score: 0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.4 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z6ZfH-0003vL-Ie
Subject: [Bitcoin-development] Fwd: Re: [RFC] Canonical input and output
 ordering in transactions
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 21 Jun 2015 07:27:41 -0000

--089e0116000233d6dc05190217e7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------
From: "Jorge Tim=C3=B3n" <jtimon@jtimon.cc>
Date: Jun 17, 2015 6:59 PM
Subject: Re: [Bitcoin-development] [RFC] Canonical input and output
ordering in transactions
To: "Rusty Russell" <rusty@rustcorp.com.au>
Cc:

On Tue, Jun 16, 2015 at 10:06 AM, Rusty Russell <rusty@rustcorp.com.au>
wrote:
> 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? :)

Here's a short explanation and the code:

https://github.com/Blockstream/contracthashtool

Here's a longer explanation with a concrete use case (the contract is
the invoice):

https://www.youtube.com/watch?v=3DqwyALGlG33Q

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

Great. Well, then all I'm saying is that I like this as plan A.

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

<div class=3D"gmail_quote">---------- Forwarded message ----------<br>From:=
 &quot;Jorge Tim=C3=B3n&quot; &lt;jtimon@jtimon.cc&gt;<br>Date: Jun 17, 201=
5 6:59 PM<br>Subject: Re: [Bitcoin-development] [RFC] Canonical input and o=
utput ordering in transactions<br>To: &quot;Rusty Russell&quot; &lt;<a href=
=3D"mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>&gt;<br>Cc: <br>=
<br type=3D"attribution">On Tue, Jun 16, 2015 at 10:06 AM, Rusty Russell &l=
t;<a href=3D"mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>&gt; wr=
ote:<br>
&gt; Jorge Tim=C3=B3n &lt;jtimon@jtimon.cc&gt; writes:<br>
&gt;&gt; On Jun 15, 2015 11:43 PM, &quot;Rusty Russell&quot; &lt;<a href=3D=
"mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; Though Peter Todd&#39;s more general best-effort language migh=
t make more<br>
&gt;&gt;&gt; sense.=C2=A0 It&#39;s not like you can hide an OP_RETURN trans=
action to make it<br>
&gt;&gt;&gt; look like something else, so that transaction not going to be<=
br>
&gt;&gt;&gt; distinguished by non-canonical ordering.<br>
&gt;&gt;<br>
&gt;&gt; What about commitments that don&#39;t use op_return (ie pay2contra=
ct<br>
&gt;&gt; commitments)?<br>
&gt;<br>
&gt; I have no idea what they are? :)<br>
<br>
Here&#39;s a short explanation and the code:<br>
<br>
<a href=3D"https://github.com/Blockstream/contracthashtool" rel=3D"noreferr=
er" target=3D"_blank">https://github.com/Blockstream/contracthashtool</a><b=
r>
<br>
Here&#39;s a longer explanation with a concrete use case (the contract is<b=
r>
the invoice):<br>
<br>
<a href=3D"https://www.youtube.com/watch?v=3DqwyALGlG33Q" rel=3D"noreferrer=
" target=3D"_blank">https://www.youtube.com/watch?v=3DqwyALGlG33Q</a><br>
<br>
&gt; Yes, my plan B would be an informational bip with simple code,<br>
&gt; suggesting a way to permute a transaction based on some secret.=C2=A0 =
No<br>
&gt; point everyone reinventing the wheel, badly.<br>
<br>
Great. Well, then all I&#39;m saying is that I like this as plan A.<br>
</div>

--089e0116000233d6dc05190217e7--