summaryrefslogtreecommitdiff
path: root/bb/7b87f4aa135969d317ab0e733cb53af8b47fcf
blob: ab6961cd96d1a9d85cb6a0a34836bc6d23e13efb (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gmaxwell@gmail.com>) id 1SnErZ-0004oi-3G
	for bitcoin-development@lists.sourceforge.net;
	Fri, 06 Jul 2012 20:10:49 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.160.47 as permitted sender)
	client-ip=209.85.160.47; envelope-from=gmaxwell@gmail.com;
	helo=mail-pb0-f47.google.com; 
Received: from mail-pb0-f47.google.com ([209.85.160.47])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1SnErY-0005rm-Gn
	for bitcoin-development@lists.sourceforge.net;
	Fri, 06 Jul 2012 20:10:49 +0000
Received: by pbbrq2 with SMTP id rq2so14295835pbb.34
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 06 Jul 2012 13:10:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.226.102 with SMTP id rr6mr39747255pbc.99.1341605442527;
	Fri, 06 Jul 2012 13:10:42 -0700 (PDT)
Received: by 10.68.59.6 with HTTP; Fri, 6 Jul 2012 13:10:42 -0700 (PDT)
In-Reply-To: <CABsx9T39Hj5XSwVxkAw+UxuEyKMnjpAtYtfoLD7KpMuUCiM=Jg@mail.gmail.com>
References: <CA+8xBpefOgtuECJqoAtbFfPnmkFEHTL=6Uqf=kb7NB=fnV863Q@mail.gmail.com>
	<CAMGNxUsZQMN+M4cR8nMhNmJAAnT2ZSPjrMHV0BetdiMmj453sA@mail.gmail.com>
	<CA+8xBpdbgkzwOvyUsJYEXNMTBwuvAbFsKx2xF1s0BMPiL9n1Qw@mail.gmail.com>
	<CACh7GpFb8Xxn9KmR34UNw6N=P96TJSgqec+eLdr5KneZAOj9Tw@mail.gmail.com>
	<CABsx9T39Hj5XSwVxkAw+UxuEyKMnjpAtYtfoLD7KpMuUCiM=Jg@mail.gmail.com>
Date: Fri, 6 Jul 2012 16:10:42 -0400
Message-ID: <CAAS2fgTCjmTD8qZoUnyNLhqoga8-E5osEx3qwqSfoWQewBP3Gg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.9 (/)
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
	0.7 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SnErY-0005rm-Gn
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
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: Fri, 06 Jul 2012 20:10:49 -0000

On Fri, Jul 6, 2012 at 4:02 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
>> But those issues are solvable through other, non-backwards incompatible
>> means. For example, mandate that a <transaction hash, output index> refers
>> to the first such pair that is not already spent. No?
>
> Yes, that is essentially what BIP 30 did.

It's important to note that bip 30 doesn't prevent duplication, it
just prevents the identified really evil outcome of the duplication.

There was discussion on doing the height _before_ that, but the
realization that the rewrites were a real vulnerability made it urgent
and rolling out the height will require time while the bip30 change
could be deployed more quickly.