From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <87k2vhfnx9.fsf@rustcorp.com.au> <87r3pdembs.fsf@rustcorp.com.au> <87eglcelf3.fsf@rustcorp.com.au> <87zj40cc1d.fsf@rustcorp.com.au> Date: Sun, 21 Jun 2015 09:27:33 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" Date: Jun 17, 2015 6:59 PM Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions To: "Rusty Russell" Cc: On Tue, Jun 16, 2015 at 10:06 AM, Rusty Russell wrote: > Jorge Tim=C3=B3n writes: >> On Jun 15, 2015 11:43 PM, "Rusty Russell" 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
---------- Forwarded message ----------
From:= "Jorge Tim=C3=B3n" <jtimon@jtimon.cc>
Date: Jun 17, 201= 5 6:59 PM
Subject: Re: [Bitcoin-development] [RFC] Canonical input and o= utput ordering in transactions
To: "Rusty Russell" <rusty@rustcorp.com.au>
Cc:
=
On Tue, Jun 16, 2015 at 10:06 AM, Rusty Russell &l= t;rusty@rustcorp.com.au> wr= ote:
> 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 migh= t make more
>>> sense.=C2=A0 It's not like you can hide an OP_RETURN trans= action to make it
>>> look like something else, so that transaction not going to be<= br> >>> distinguished by non-canonical ordering.
>>
>> What about commitments that don't use op_return (ie pay2contra= ct
>> 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.=C2=A0 = No
> point everyone reinventing the wheel, badly.

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