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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1S2Qgx-0001hQ-TD
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Feb 2012 17:18:23 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.175 as permitted sender)
client-ip=209.85.212.175; envelope-from=pieter.wuille@gmail.com;
helo=mail-wi0-f175.google.com;
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1S2Qgs-0007Q2-Dx
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Feb 2012 17:18:23 +0000
Received: by wibhq12 with SMTP id hq12so1443633wib.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 28 Feb 2012 09:18:12 -0800 (PST)
Received-SPF: pass (google.com: domain of pieter.wuille@gmail.com designates
10.180.85.35 as permitted sender) client-ip=10.180.85.35;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
pieter.wuille@gmail.com designates 10.180.85.35 as permitted
sender) smtp.mail=pieter.wuille@gmail.com;
dkim=pass header.i=pieter.wuille@gmail.com
Received: from mr.google.com ([10.180.85.35])
by 10.180.85.35 with SMTP id e3mr703020wiz.6.1330449492382 (num_hops =
1); Tue, 28 Feb 2012 09:18:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.85.35 with SMTP id e3mr577749wiz.6.1330449492330; Tue, 28
Feb 2012 09:18:12 -0800 (PST)
Received: by 10.223.88.146 with HTTP; Tue, 28 Feb 2012 09:18:12 -0800 (PST)
In-Reply-To: <4F4D0AEC.8060400@netmind.hu>
References: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
<4F4D0AEC.8060400@netmind.hu>
Date: Tue, 28 Feb 2012 18:18:12 +0100
Message-ID: <CAPg+sBj==4kaeoQJ8YDHSCSr9H4Frbu6zDz8qDAwwLAF4mefJg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: =?ISO-8859-1?Q?Brautigam_R=F3bert?= <robert.brautigam@netmind.hu>
Content-Type: text/plain; charset=ISO-8859-1
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
(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: 1S2Qgs-0007Q2-Dx
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability
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: Tue, 28 Feb 2012 17:18:24 -0000
On Tue, Feb 28, 2012 at 18:12, Brautigam R=F3bert
<robert.brautigam@netmind.hu> wrote:
>> A simple way to fix this, is adding an extra protocol rule[1]:
>>
>> =A0 =A0Do not allow blocks to contain a transaction whose hash is equal =
to
>> that of a former transaction which has not yet been completely spent.
>
> I don't know whether I understand this correctly, but there should be no
> duplicate transaction hashes at all. So the rule should be: Do not allow
> blocks to contain transaction hashes which are already present in that
> branch.
As explained in the BIP, that would prevent pruning, as it would
require each full node to keep a database with all transaction hashes
ever.
> If by a freak accident a transaction has the same hash as another
> transaction in the chain, shouldn't the transaction be "tweaked" in some
> way to avoid collision (generate a new target address for it or
> something)? In any case this seams very-very unlikely to happen, or am I
> missing something?
It won't happen by accident. Duplicate coinbase transactions are
possible however (by badly written software, or malicious intent).
Transactions that spend duplcate coinbases can be made to have the
same hash as well.
--=20
Pieter
|
