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
|
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 1E6DB9C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2016 20:45:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f170.google.com (mail-qt0-f170.google.com
[209.85.216.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8812E0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2016 20:45:38 +0000 (UTC)
Received: by mail-qt0-f170.google.com with SMTP id l91so56961178qte.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Sep 2016 13:45:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to;
bh=fn+/X2bdXFmSl4+qkxHBMINNmZkJ+GQj7K44E68BkhA=;
b=Wome8vQVy5pLMbN9XOnxy24tPeJpOBYtRVta9V+5MXCU8HSeuIwFohZJQj0/sf0nXI
bkBtT846vzm6aY6MHedebr9ZffdxKgRz1spyjsIPoKPEDdZYHOTFs5dhwrE0XUji9sgB
0cyYmYqvwtlEywUGQ2wWtqMMqo0tN3V2x6dKyvkZ/L79neradRVk5JUGCkfuLY0NWrhw
emirkNGXv701QEVSmEfe63TMofS92DHO5Uos7S+fkbl8J/VUB+KQj4GmemHJswZBwR33
IqJMrxv6lqg59h/Om8pO6J/i+1lHH2PnAGmd/nCm8h04knkm9B/I994JLeETpI0/YmDh
puFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=fn+/X2bdXFmSl4+qkxHBMINNmZkJ+GQj7K44E68BkhA=;
b=miDgv8gg6l8MOs2l9QJKbH+5oBLKdy2PBJre5F0Qf4d3BmGs4zXUDM/XoKS1ml3FGl
7059UPLPTcLQlX3bSA4jKp9ONDktwtm+MiOCm1uCT4vcBFcl71Rr+1Ev/Fp7B+x/Iigb
zsIN9gchkTqXjGmivOjAybiQHyXyle1qiMpKiJDuslHtVEmHDBDeD0W9O5K37GNCmNsn
uIemXOh1e4Dnya1lxUlSsbHd0vbTrSpJcu8hU8rxcIZUmU3aAawisJ9JrUxHEruUp5IM
cCdFMqxuKo7tk2Tu3Aq7dwTcIjCTel0bNMx34XvmaclIoFdIRHN24xghYMVnqMKd8e5b
62hw==
X-Gm-Message-State: AE9vXwOehIaA2b8uFJx1DZyb8vMCj4J8YjY/D6YrFgk+1NiT1LwAm6GAup3IUcpVZNCdFYuPh0HjH8zYGuZSSQ==
X-Received: by 10.237.37.23 with SMTP id v23mr22519429qtc.54.1474145137750;
Sat, 17 Sep 2016 13:45:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.145.33 with HTTP; Sat, 17 Sep 2016 13:45:17 -0700 (PDT)
From: "Rune K. Svendsen" <runesvend@gmail.com>
Date: Sat, 17 Sep 2016 22:45:17 +0200
Message-ID: <CAH2=CKzsHROCXQHRS25i5O8XUPkbwFMDAFC_CO9MD6RuJajA4g@mail.gmail.com>
To: Bitcoin <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113a31624877e0053cba2948
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
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 20:46:38 +0000
Subject: [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 20:45:39 -0000
--001a113a31624877e0053cba2948
Content-Type: text/plain; charset=UTF-8
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
--001a113a31624877e0053cba2948
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<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_TXHASHVE=
RIFY" sequence from the beginning of all scriptSigs (if present), and =
abort if the 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 us=
ing this. But in the meantime it's very valuable to be able to not worr=
y about tx ID malleability.</div><div><br></div><div>Please let me know wha=
t 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>
--001a113a31624877e0053cba2948--
|
