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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pw@vps7135.xlshosting.net>) id 1S371k-00085U-Jk
for bitcoin-development@lists.sourceforge.net;
Thu, 01 Mar 2012 14:30:40 +0000
X-ACL-Warn:
Received: from vps7135.xlshosting.net ([178.18.90.41])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1S371g-0004VZ-Ff for bitcoin-development@lists.sourceforge.net;
Thu, 01 Mar 2012 14:30:40 +0000
Received: by vps7135.xlshosting.net (Postfix, from userid 1000)
id 5F6F660EAC; Thu, 1 Mar 2012 15:30:30 +0100 (CET)
Date: Thu, 1 Mar 2012 15:30:30 +0100
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Ben Reeves <support@pi.uk.com>
Message-ID: <20120301143029.GA18168@vps7135.xlshosting.net>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPBPUnpj=u53Nvvvu54e2X462gPshLQ5rUcPosxvoNAXp6uN8w@mail.gmail.com>
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
X-Headers-End: 1S371g-0004VZ-Ff
Cc: Bitcoin Dev <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: Thu, 01 Mar 2012 14:30:40 -0000
On Thu, Mar 01, 2012 at 01:09:02PM +0000, Ben Reeves 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 don't understand this.
> Is there a reason not to disallow duplicate coinbases entirely?
Just disallowing duplicate coinbases is possible, but it requires keeping a
set of all coinbases transaction around until infinity. That's not really a problem,
but it can be avoided. One very reasonable proposed solution is adding the block
height to the coinbase. However, as coinbases are used for all kinds of things
already, this is harder to roll out network-wide. Hence, first this "emergency"
solution that already prevents (afaik) all practical attacks, and in a later step
forcing unique coinbases, so that transactions can be assumed to be unique
identifiable by their hash again.
--
Pieter
|
