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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1WCpvi-0002ug-P9
for bitcoin-development@lists.sourceforge.net;
Mon, 10 Feb 2014 12:25:42 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.50 as permitted sender)
client-ip=209.85.215.50; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f50.google.com;
Received: from mail-la0-f50.google.com ([209.85.215.50])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WCpvh-0007s0-MC
for bitcoin-development@lists.sourceforge.net;
Mon, 10 Feb 2014 12:25:42 +0000
Received: by mail-la0-f50.google.com with SMTP id ec20so4621429lab.23
for <bitcoin-development@lists.sourceforge.net>;
Mon, 10 Feb 2014 04:25:35 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.229.225 with SMTP id st1mr22014393lac.2.1392035135087;
Mon, 10 Feb 2014 04:25:35 -0800 (PST)
Received: by 10.112.198.34 with HTTP; Mon, 10 Feb 2014 04:25:34 -0800 (PST)
In-Reply-To: <CANAnSg1LgpHGf-vTV0to1Z7sogf1ic6WTbogEsrQy1wh4C5zfw@mail.gmail.com>
References: <CANAnSg1LgpHGf-vTV0to1Z7sogf1ic6WTbogEsrQy1wh4C5zfw@mail.gmail.com>
Date: Mon, 10 Feb 2014 04:25:34 -0800
Message-ID: <CAAS2fgTx8UzQiocyNMfMNkt2uUZRTmhagb2BY9TPuAupVjVa2g@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Drak <drak@zikula.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
(gmaxwell[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: 1WCpvh-0007s0-MC
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] MtGox blames bitcoin
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:25:42 -0000
On Mon, Feb 10, 2014 at 3:28 AM, Drak <drak@zikula.org> wrote:
> What is the official response from the Bitcoin Core developers about MtGo=
x's
> assertion that their problems are due to a fault of bitcoin, as opposed t=
o a
> fault of their own?
>
> The technical analysis preluding this mess, was that MtGox was at fault f=
or
> their faulty wallet implementation.
In the real world fault seldom falls in a single place. Bitcoin is at
fault=E2=80=94 in many places=E2=80=94 for making it harder for implementer=
s to get
things right. MtGox is at fault for not implementing in a way that
copes with behaviors in the Bitcoin protocol which have been known
since at least 2011.
(https://en.bitcoin.it/wiki/Transaction_Malleability).
Not that Bitcoin-QT handles Malleability fantastically=E2=80=94 but because=
it
tracks inputs it will still detect the mutant transactions.
An interesting point which I haven't pointed out elsewhere is that for
the question of basic funds safety in re-issuing a transaction
mallablity is basically irrelevant.
Say you pay someone and it doesn't go through (or it does and you
don't see it because its been mutated and your software can't detect
that), and they ask you to reissue.... if you reissue without
double-spending any of the original inputs you are at risk of getting
robbed. This is true with or without malleability. Without the
double-spend of at least one input the original transaction could just
go through in addition to your reissue.
Say that you do make sure to double spend at least one input=E2=80=94 then
the result is funds safe safe, regardless of if a mutation happened.
Say you want to support _canceling_ a payment (send me the goat
instead!) rather than reissue you still must double-spend the
attempted payment to cancel it, since it still might go through if you
don't. And the double spend works to protect this case regardless of
if the transaction was mutated.
For support and accounting purposes you absolutely do need tools to
identify mutated transactions, so long as mutation exists... so we
ought to provide some better tools there. But I can't think a case
where mutation handling is necessary or sufficient for cancellation
security, but=E2=80=94 rather=E2=80=94 input tracking appears to be both ne=
cessary and
sufficient in all cancellation cases.
This helps explain why Bitcoin-QT=E2=80=94 whos mutation handling kinda
stinks=E2=80=94 doesn't ever end up in a really bad situation with mutants:=
it
tracks inputs pretty well.
In any case, I've always been happy to help out Mtgox with technical
issues. Having some specs for a stable transaction ID would probably
be helpful to many applications, even if it isn't the critical key you
need for cancellation security. Removing mallability entirely has
been a soft long term goal, and there were recently (as in today) some
posts about it=E2=80=94 look at the list archives... though it won't happen
fast since all signers/wallets will need to be updated.
|
