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:= "Jorge Tim=C3=B3n" <jtimon@jtimon.cc><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: "Rusty Russell" <<a href= =3D"mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>><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>> wr= ote:<br> > Jorge Tim=C3=B3n <jtimon@jtimon.cc> writes:<br> >> On Jun 15, 2015 11:43 PM, "Rusty Russell" <<a href=3D= "mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>> wrote:<br> >><br> >>> Though Peter Todd's more general best-effort language migh= t make more<br> >>> sense.=C2=A0 It's not like you can hide an OP_RETURN trans= action to make it<br> >>> look like something else, so that transaction not going to be<= br> >>> distinguished by non-canonical ordering.<br> >><br> >> What about commitments that don't use op_return (ie pay2contra= ct<br> >> commitments)?<br> ><br> > I have no idea what they are? :)<br> <br> Here'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'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> > Yes, my plan B would be an informational bip with simple code,<br> > suggesting a way to permute a transaction based on some secret.=C2=A0 = No<br> > point everyone reinventing the wheel, badly.<br> <br> Great. Well, then all I'm saying is that I like this as plan A.<br> </div> --089e0116000233d6dc05190217e7--