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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <support@pi.uk.com>) id 1S39gT-0005fN-0p
for bitcoin-development@lists.sourceforge.net;
Thu, 01 Mar 2012 17:20:53 +0000
Received: from mail-qw0-f47.google.com ([209.85.216.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1S39gN-0000Pi-Gm
for bitcoin-development@lists.sourceforge.net;
Thu, 01 Mar 2012 17:20:52 +0000
Received: by qadz30 with SMTP id z30so3275244qad.13
for <bitcoin-development@lists.sourceforge.net>;
Thu, 01 Mar 2012 09:20:42 -0800 (PST)
Received-SPF: pass (google.com: domain of support@pi.uk.com designates
10.224.111.142 as permitted sender) client-ip=10.224.111.142;
Authentication-Results: mr.google.com;
spf=pass (google.com: domain of support@pi.uk.com
designates 10.224.111.142 as permitted sender)
smtp.mail=support@pi.uk.com
Received: from mr.google.com ([10.224.111.142])
by 10.224.111.142 with SMTP id s14mr5577635qap.78.1330622442046
(num_hops = 1); Thu, 01 Mar 2012 09:20:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.111.142 with SMTP id s14mr4655490qap.78.1330622441881;
Thu, 01 Mar 2012 09:20:41 -0800 (PST)
Received: by 10.229.27.137 with HTTP; Thu, 1 Mar 2012 09:20:41 -0800 (PST)
X-Originating-IP: [81.187.238.52]
In-Reply-To: <CAAS2fgS2NMcdpyomSE76O8EuHV8Zw7NuvSjBuk8S+BSKX5ry=A@mail.gmail.com>
References: <CAPg+sBhb+gYMwp1OJuCHYt5=BU63=YBWOFaLLthHBkN_U-scaA@mail.gmail.com>
<CAPBPUnqgV_hHYwFoB_1qXMvEaE1pM0vm8=V=AKe2n-rPFzz+mQ@mail.gmail.com>
<CABsx9T1YbFLcuCLbZZvSJGPy9k0PRgWttOp-KPUW+99XSYTkQQ@mail.gmail.com>
<CAPBPUnp61tCr5yVa36OGoqmO83hOJitnWJDyW3SihXyxy_FbYg@mail.gmail.com>
<20120229232029.GA6073@vps7135.xlshosting.net>
<20120229234558.GA6573@vps7135.xlshosting.net>
<CAPBPUno7EaUeQHEb6jfR77k==p5_Q5Es8dGQiwmQW+DPSttDuA@mail.gmail.com>
<CAPBPUnpj=u53Nvvvu54e2X462gPshLQ5rUcPosxvoNAXp6uN8w@mail.gmail.com>
<CAAS2fgS2NMcdpyomSE76O8EuHV8Zw7NuvSjBuk8S+BSKX5ry=A@mail.gmail.com>
Date: Thu, 1 Mar 2012 17:20:41 +0000
Message-ID: <CAPBPUnr6aDJ-Bs-Sebeij=S_nNdGj+uFcsFcCXFT8v0JTyJyKQ@mail.gmail.com>
From: Ben Reeves <support@pi.uk.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQngVy4ZOK/Puujk/orikie2KmfGTteplUoYDXMCbQgxPUefyxtonhUP9Vyf81iMJTgImbQP
X-Spam-Score: -1.4 (-)
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.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1S39gN-0000Pi-Gm
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: Thu, 01 Mar 2012 17:20:53 -0000
>I am not following you here, can you explain what you're thinking?
If I mine a duplicate coinbase of an old block (whether spent or not)
if that block is then invalidated DisconnectBlock() will erase both
the coinbase of the new block and of the old block. This leaves the
blockchain is in an inconsistent state because with the coinbase
missing the old block will no longer pass CheckBlock().
When affected clients are restarted LoadBlockIndex() will try and
verify all blocks in the main chain, failing at the block with the
missing coinbase.
1) If an attacker was to do this with an early block it would force
all affected clients to redownload the majority of the blockchain.
2) If the attacker was able to do this on a block after the March 1st
deadline (future block A). If they mined a fake copy of block A (block
B) with the same coinbase but a different hash clients who received
block B before block A will refuse to accept block A because of the
unspent duplicate coinbase in block B. The attacker can then fork the
chain at this point despite the real chain being longer.
I am just think out load here so I could be wrong, but maybe it would
be better to go for the full block height fix now?
On Thu, Mar 1, 2012 at 2:27 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves <support@pi.uk.com> wrote:
>> One more thing to add. The implementation in the reference patch fixes
>> the blockchain forking issue however by still allowing spent coinbases
>> to be disconnected patched clients are still vulnerable to blockchain
>> corruption. While not an immediate issue it would mean
>> LoadBlockIndex() would error on restart and could cause problems for
>> new clients during the initial blockchain download.
>
> I am not following you here, can you explain what you're thinking?
>
>> Is there a reason not to disallow duplicate coinbases entirely?
>
> Because this would make it impossible for nodes to prune the vaules.
> They'd all forever have to keep a set of all the coinbase hashes in
> order to perform the test. The height-in-coinbase BIP will make
> duplicates effectively impossible to create, which is a much more
> clean behavior.
|
