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
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
|
Return-Path: <runesvend@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0FBE29C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2016 21:14:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com
[209.85.220.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 55DC3124
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2016 21:14:51 +0000 (UTC)
Received: by mail-qk0-f169.google.com with SMTP id w204so116462165qka.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2016 14:14:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=uSJJnPpt7v13vkArB3LZCo90GdDPunjAloC1uCWz6FA=;
b=P198K8W/Ix/ZFrrti10ZG3lPjI426FTvyupqCHUmsntvr7MRHiADL3OKLtGWDLZM1T
V4dySqYAN5obrET7mVbVOOriFTEAnN80t9hT+02L4WTtp5Ql1PA3fC1wNUcwxi6d+JQ/
5OMfxU0UGugoXgShKOv0erwneOR0W5ZmlUh/0xFKOydQZH4jTa21Y16LITNoEcuzcV+V
6jA2hK4pU6AACTrcEbu8fstV0048v0Vv7H/7Dkerquj6IHklqlpg2YijgyLJsq1ELlhp
dCT2Poa/4WTKn7cSxKw2XCb0GYt3hIwjsNhU7DhmrXeIJpAxqde/p2tCn7gfCM40vMtZ
Asyg==
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:from:date
:message-id:subject:to:cc;
bh=uSJJnPpt7v13vkArB3LZCo90GdDPunjAloC1uCWz6FA=;
b=foh6164zbhmkp95LZas9uWZNEmozGoToa9MLjCzedPAZ3+439cEn8hmnpdiX51trAk
8JmI3KCb8OuzEEhY5d5pZFad1V5fNCf9qZ6c5hTrLyl+6Svt0Q+jKE3Km/bO8GpASSPZ
3WlRi28y/CYO+DGLL+3ISiZm276cb7z94kIwAkNZD3ZHBvqYJ5Kv1t8IQwaG2KxA4Jjr
Qn6vDj2KHOPW6w5c8dN1kQnRiQf3oaYOVTvR7fNroCMnKU7Of8T5O9i3Z8H1H7u7K5T5
9kI+5UBfYgmMoaTgKcuNl0/PvK2QEwa+QVFCYAY1EhDbltnh9a0IjWpgXWIioJpvZvD2
lq4w==
X-Gm-Message-State: AE9vXwOE8dv5bg3gswrLrYVeHwbWaAGdmC9TLoJNU4PTkOgGOHh2k5Sf3MGKtPq55afcXEGv/fFb2qWYgPEjIQ==
X-Received: by 10.55.48.9 with SMTP id w9mr21610090qkw.147.1474146890622; Sat,
17 Sep 2016 14:14:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.145.33 with HTTP; Sat, 17 Sep 2016 14:14:30 -0700 (PDT)
In-Reply-To: <715F2390-221E-4646-A7F6-3FB937A08764@mattcorallo.com>
References: <CAH2=CKzsHROCXQHRS25i5O8XUPkbwFMDAFC_CO9MD6RuJajA4g@mail.gmail.com>
<715F2390-221E-4646-A7F6-3FB937A08764@mattcorallo.com>
From: "Rune K. Svendsen" <runesvend@gmail.com>
Date: Sat, 17 Sep 2016 23:14:30 +0200
Message-ID: <CAH2=CKzcNu-jWPr3AKhpTN_cyGVO67oPCMQx2hUrp=Ax_+wvCw@mail.gmail.com>
To: Bitcoin <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11471b10c32af9053cba91fe
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 17 Sep 2016 21:46:18 +0000
Subject: Re: [bitcoin-dev] Simple tx ID malleability fix,
opcode proposal: OP_TXHASHVERIFY
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Sep 2016 21:14:52 -0000
--001a11471b10c32af9053cba91fe
Content-Type: text/plain; charset=UTF-8
I hadn't thought of that... There is a solution, I think, but it makes the
operation less simple.
If a transaction contains at least two OP_TXHASHVERIFY-protected inputs,
signed without ANYONECANPAY, their signatures would cover the other
input's OP_TXHASHVERIFY hash, right?
/Rune
On Sat, Sep 17, 2016 at 10:56 PM, Matt Corallo <lf-lists@mattcorallo.com>
wrote:
> (removing the list)
>
> Because the tx hash in your construction is not signed, someone wishing to
> maleate a transaction may do so by also updating the hash in the scriptSig.
>
> Matt
>
> On September 17, 2016 4:45:17 PM EDT, "Rune K. Svendsen via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I would really like to be able to create transactions that are immune to
>> transaction ID malleability now, so I have been thinking of the simplest
>> solution possible, in order to get a BIP through without too much trouble.
>>
>> An opcode we could call OP_TXHASHVERIFY could be introduced. It would be
>> defined to work only if added to a scriptSig as the very first operation,
>> and would abort if the hash of the transaction **with all OP_TXHASHVERIFY
>> operations (including stack push) removed** does not match what has been
>> pushed on the stack.
>>
>> So, in order to produce a transaction with one or more inputs protected
>> against tx ID malleability, one would:
>>
>> 1. Calculate tx ID of the tx: TX_HASH
>> 2. For each input you wish to protect, add "0x32 $TX_HASH
>> OP_TXHASHVERIFY" to the beginning of the scriptSig
>>
>> When evaluating OP_TXHASHVERIFY, we make a copy of the tx in question,
>> and remove the "0x32 <32 bytes> OP_TXHASHVERIFY" sequence from the
>> beginning of all scriptSigs (if present), and abort if the tx copy hash
>> does not match the top stack item.
>>
>> This is a very simple solution that only adds 34 bytes per input, and
>> when something better becomes available (eg. Segwit), we will stop using
>> this. But in the meantime it's very valuable to be able to not worry about
>> tx ID malleability.
>>
>> Please let me know what you think.
>>
>>
>>
>> /Rune
>>
>> ------------------------------
>>
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
--001a11471b10c32af9053cba91fe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I hadn't thought of that... There is a solution, I thi=
nk, but it makes the operation less simple.<div><br></div><div>If a transac=
tion contains at least two OP_TXHASHVERIFY-protected=C2=A0inputs, signed wi=
thout ANYONECANPAY, their signatures would cover the other input's=C2=
=A0OP_TXHASHVERIFY hash, right?</div><div><div><br></div><div><br></div><di=
v>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /Rune</div><div><br></div></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Sep 17, =
2016 at 10:56 PM, Matt Corallo <span dir=3D"ltr"><<a href=3D"mailto:lf-l=
ists@mattcorallo.com" target=3D"_blank">lf-lists@mattcorallo.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div>(removing the list)<br>
<br>
Because the tx hash in your construction is not signed, someone wishing to =
maleate a transaction may do so by also updating the hash in the scriptSig.=
<br>
<br>
Matt<br><br><div class=3D"gmail_quote"><div><div class=3D"h5">On September =
17, 2016 4:45:17 PM EDT, "Rune K. Svendsen via bitcoin-dev" <<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.<wbr>linuxfoundation.org</a>> wrote:</div></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div><div class=3D"h5">
<div dir=3D"ltr">I would really like to be able to create transactions that=
are immune to transaction ID malleability now, so I have been thinking of =
the simplest solution possible, in order to get a BIP through without too m=
uch trouble.<div><br></div><div>An opcode we could call OP_TXHASHVERIFY cou=
ld be introduced. It would be defined to work only if added to a scriptSig =
as the very first operation, and would abort if the hash of the transaction=
**with all OP_TXHASHVERIFY operations (including stack push) removed** doe=
s not match what has been pushed on the stack.</div><div><br></div><div>So,=
in order to produce a transaction with one or more inputs protected agains=
t tx ID malleability, one would:</div><div><br></div><div>1. Calculate tx I=
D of the tx: TX_HASH</div><div>2. For each input you wish to protect, add &=
quot;0x32 $TX_HASH OP_TXHASHVERIFY" to the beginning of the scriptSig<=
/div><div><br></div><div>When evaluating OP_TXHASHVERIFY, we make a copy of=
the tx in
question, and remove the "0x32 <32 bytes> OP_TXHASHVERIFY" =
sequence from the beginning of all scriptSigs (if present), and abort if th=
e tx copy hash does not match the top stack item.</div><div><br></div><div>=
This is a very simple solution that only adds 34 bytes per input, and when =
something better becomes available (eg. Segwit), we will stop using this. B=
ut in the meantime it's very valuable to be able to not worry about tx =
ID malleability.</div><div><br></div><div>Please let me know what you think=
.</div><div><br></div><div><br></div><div><br></div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 /Rune</div></div>
<p style=3D"margin-top:2.5em;margin-bottom:1em;border-bottom:1px solid #000=
"></p></div></div><pre><hr><br>bitcoin-dev mailing list<br><a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
s.<wbr>linuxfoundation.org</a><br><a href=3D"https://lists.linuxfoundation.=
org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoun=
dation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br></pre></blockquote=
></div></div></blockquote></div><br></div></div>
--001a11471b10c32af9053cba91fe--
|
