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
|
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 <gmaxwell@gmail.com>) id 1UFrNg-0007Bg-Hr
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 19:30:32 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.53 as permitted sender)
client-ip=209.85.215.53; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f53.google.com;
Received: from mail-la0-f53.google.com ([209.85.215.53])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UFrNf-0006IZ-Kl
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 19:30:32 +0000
Received: by mail-la0-f53.google.com with SMTP id fr10so1592347lab.12
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Mar 2013 12:30:25 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.145.134 with SMTP id su6mr18753684lab.35.1363203024919;
Wed, 13 Mar 2013 12:30:24 -0700 (PDT)
Received: by 10.112.96.164 with HTTP; Wed, 13 Mar 2013 12:30:24 -0700 (PDT)
In-Reply-To: <CACh7GpG_4uLUUiwJyZO0FtV2_UHMN-HnJsZZXWpC2jQvzb-jMQ@mail.gmail.com>
References: <201303131256.30144.luke@dashjr.org>
<CACh7GpE09hqCPL6rtdC6EZzohM5QHb+0SdFoD8MzPSqf7=6hOA@mail.gmail.com>
<20130313175825.GA21242@vps7135.xlshosting.net>
<CACh7GpG_4uLUUiwJyZO0FtV2_UHMN-HnJsZZXWpC2jQvzb-jMQ@mail.gmail.com>
Date: Wed, 13 Mar 2013 12:30:24 -0700
Message-ID: <CAAS2fgRh9x7qJ=SvR_v8pYqgJbymW-z=bnQMYDPHYQVo7-xxdA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mark Friedenbach <mark@monetize.io>
Content-Type: text/plain; charset=UTF-8
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
(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
X-Headers-End: 1UFrNf-0006IZ-Kl
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 0.8.1 ideas
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: Wed, 13 Mar 2013 19:30:32 -0000
On Wed, Mar 13, 2013 at 11:27 AM, Mark Friedenbach <mark@monetize.io> wrote:
> This may be a semantic issue. I meant that it's not a hard-fork of the
> bitcoin protocol, which I'm taking to mean the way in which we all
> *expected* every version of the Satoshi client to behave: the rules which we
In our common language a hardfork is a rule difference that can cause
irreconcilable failure in consensus; it's not some political change or
some change in the user's understanding or something fuzzy like that.
Please don't creep the definitions... but arguments over definitions
are silly. If you really object to calling the causes consensus
failure thing something else okay, then suggest a name, but whatever
its called thats what we're talking about here.
Your proposal of having a hardfork but only on the mining nodes has
coordination problems. What happens if we don't know how to contact a
majority of the hashpower to get them to turn off their special
validation code? This is especially a concern because it's not
unlikely that in a few months there may be solo miners with tens of
TH/s... already we have a single party with nearly a majority, though
at the moment they happen to be mining on the largest couple pools.
Far better to have this special code just triggered on a deadline,
which can be widely advertised as "you must upgrade to 0.7.4 or >0.8.1
before this time" and then all switch at once... and then we
demonstrate the viability of a general mechanism that doesn't depend
on poor miner decentralization.
|
