1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
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--
|
