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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1WCpyj-0007g5-6f
for bitcoin-development@lists.sourceforge.net;
Mon, 10 Feb 2014 12:28:49 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.172 as permitted sender)
client-ip=209.85.213.172; envelope-from=pieter.wuille@gmail.com;
helo=mail-ig0-f172.google.com;
Received: from mail-ig0-f172.google.com ([209.85.213.172])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WCpyi-0004de-8u
for bitcoin-development@lists.sourceforge.net;
Mon, 10 Feb 2014 12:28:49 +0000
Received: by mail-ig0-f172.google.com with SMTP id k19so6407307igc.5
for <bitcoin-development@lists.sourceforge.net>;
Mon, 10 Feb 2014 04:28:43 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.43.74.198 with SMTP id yx6mr4867125icb.40.1392035322936;
Mon, 10 Feb 2014 04:28:42 -0800 (PST)
Received: by 10.50.100.10 with HTTP; Mon, 10 Feb 2014 04:28:42 -0800 (PST)
Date: Mon, 10 Feb 2014 13:28:42 +0100
Message-ID: <CAPg+sBi-phaw3hDgguk-LYrPsKX4M5snTJBv_NsQML1M=XgZEw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WCpyi-0004de-8u
Subject: [Bitcoin-development] Malleability and MtGox's announcement
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: Mon, 10 Feb 2014 12:28:49 -0000
Hi all,
I was a bit surprised to see MtGox's announcement. The malleability of
transactions was known for years already (see for example the wiki
article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it,
or mails on this list from 2012 and 2013). I don't consider it a very
big problem, but it does make it harder for infrastructure to interact
with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to
avoid it altogether to make life easier for everyone.
But we can't just change all infrastructure that exists today. We're
slowly working towards making malleability harder (and hopefully
impossible someday), but this will take a long time. For example, 0.8
not supporting non-DER encoded signatures was a step in that direction
(and ironically, the trigger that caused MtGox's initial problems
here). In any case, this will take years, and nobody should wait for
this.
There seem to be two more direct problems here.
* Wallets which deal badly with modified txids.
* Services that use the transaction id to detect unconfirming transactions.
The first is something that needs to be done correctly in software -
it just needs to be aware of malleability.
The second is something I was unaware of and would have advised
against. If you plan on reissuing a transaction because on old version
doesn't confirm, make sure to make it a double spend of the first one
- so that not both can confirm.
I certainly don't like press making this sound like a problem in the
Bitcoin protocol or clients. I think this is an issue that needs to be
solved at the layer above - the infrastructure building on the Bitcoin
system. Despite that, I do think that we (as a community, not just
developers) can benefit from defining a standard way to identify
transactions unambiguously. This is something Mark Karpeles suggested
a few days ago, and my proposal is this:
We define the normalized transaction id as SHA256^2(normalized_tx +
0x01000000), where normalized_tx is the transaction with all input
scripts replaced by empty scripts. This is exactly what would be
signed inside transaction signatures using SIGHASH_ALL (except not
substituting the previous scriptPubKey to be signed, and not dealing
with the input being signed specially). An implementation is here:
https://github.com/sipa/bitcoin/commits/normtxid.
Note that this is not a solution for all problems related to
malleability, but maybe it can make people more aware of it, in
tangible way.
--
Pieter
|
