summaryrefslogtreecommitdiff
path: root/27/7befe0cb77ea4396e0a877f0d5ad39c800a90b
blob: ec66d7751359556cb79fc70968658ca3ea25e04e (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
80
81
82
83
84
85
86
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1SnEjP-0001ZK-3o
	for bitcoin-development@lists.sourceforge.net;
	Fri, 06 Jul 2012 20:02:23 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.175 as permitted sender)
	client-ip=209.85.215.175; envelope-from=gavinandresen@gmail.com;
	helo=mail-ey0-f175.google.com; 
Received: from mail-ey0-f175.google.com ([209.85.215.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1SnEjO-0005rU-E4
	for bitcoin-development@lists.sourceforge.net;
	Fri, 06 Jul 2012 20:02:23 +0000
Received: by eaal1 with SMTP id l1so3655207eaa.34
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 06 Jul 2012 13:02:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.14.27.202 with SMTP id e50mr7500749eea.186.1341604936189; Fri,
	06 Jul 2012 13:02:16 -0700 (PDT)
Received: by 10.14.209.73 with HTTP; Fri, 6 Jul 2012 13:02:16 -0700 (PDT)
In-Reply-To: <CACh7GpFb8Xxn9KmR34UNw6N=P96TJSgqec+eLdr5KneZAOj9Tw@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>
Date: Fri, 6 Jul 2012 16:02:16 -0400
Message-ID: <CABsx9T39Hj5XSwVxkAw+UxuEyKMnjpAtYtfoLD7KpMuUCiM=Jg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mark Friedenbach <mark@monetize.io>
Content-Type: text/plain; charset=ISO-8859-1
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
	(gavinandresen[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: 1SnEjO-0005rU-E4
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:02:23 -0000

> 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.

We want to do this also, partly for "belt and suspenders" security but
mostly for two reasons:

1. To test using block/transaction version numbers to smoothly roll
out changes. The next change we need to make might be prompted by some
crisis; better to learn any lessons now, when we have the luxury of
time to fix problems that might crop up.

2. We think we'll all appreciate the change in a year or three, when
the whole network has upgraded and we can start writing code that
assumes all new blocks past a certain checkpoint contain their height;
that should make it easier to do things like figure out whether or not
an orphan chain can possibly be part of the main chain.

-- 
--
Gavin Andresen