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
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1U5I7F-00079M-4B
for bitcoin-development@lists.sourceforge.net;
Tue, 12 Feb 2013 15:49:53 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.174 as permitted sender)
client-ip=209.85.217.174; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f174.google.com;
Received: from mail-lb0-f174.google.com ([209.85.217.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1U5I7C-0008D1-LZ
for bitcoin-development@lists.sourceforge.net;
Tue, 12 Feb 2013 15:49:53 +0000
Received: by mail-lb0-f174.google.com with SMTP id l12so227515lbo.19
for <bitcoin-development@lists.sourceforge.net>;
Tue, 12 Feb 2013 07:49:44 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.134.164 with SMTP id pl4mr7672879lab.54.1360684183998;
Tue, 12 Feb 2013 07:49:43 -0800 (PST)
Received: by 10.112.96.164 with HTTP; Tue, 12 Feb 2013 07:49:43 -0800 (PST)
In-Reply-To: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com>
References: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com>
Date: Tue, 12 Feb 2013 07:49:43 -0800
Message-ID: <CAAS2fgTwjXCGFS-N8a8Ro80ahxXT01dCfqWYOqmwCkdRramaMg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Raph Frank <raphfrk@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: 1U5I7C-0008D1-LZ
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Incorporating block validation rule
modifications into the block chain
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: Tue, 12 Feb 2013 15:49:53 -0000
On Tue, Feb 12, 2013 at 5:49 AM, Raph Frank <raphfrk@gmail.com> wrote:
> Has this been considered?
>
> If made sufficiently general, older clients could support any
> extension of the rules.
>
> Various "hard" parameters within the protocol are defined in main.h of
> the official client.
>
> In BIP-34, there is a suggested way to make changes, based on consensus.
> https://en.bitcoin.it/wiki/BIP_0034
You misunderstand what BIP_0034 is doing=E2=80=94 it's not gauging consensu=
s,
it's making sure that the change is safe to enforce. This is a subtle
but important difference. The mechanism happens to be the same, but
we're not asking for anyone's approval there=E2=80=94 the change is needed =
to
make Bitcoin as secure as people previously believed it to be, there
have been no serious alternatives tendered. As far as I can tell the
proposal has always had universal agreement from anyone who's thought
about it. The only open question was if it was safe to deploy, and
thats what that process solves.
Bitcoin is not a democracy=E2=80=94 it quite intentionally uses the consens=
us
mechanism _only_ the one thing that nodes can not autonomously and
interdependently validate (the ordering of transactions). This
protects the users of Bitcoin by making most of the system largely
nonvolatile "constitutional" rules instead of being controlled by
popular whim where 'two wolves may vote to have the one sheep for
dinner'. If it were possible to run the whole thing autonomously it
would be, but alas...
Even if you accept the premise that voting is a just way of making
decisions (it isn't; it's just often the least unjust when something
must be done), mining is not a particularly just way of voting:
'Hashpower isn't people', and currently the authority to control the
majority of the hashpower is vested in a only a half dozen people.
Moreover, the incentives to abuse hashpower are sharply curtailed by
its limited authority (all one can do with it is reorder
transactions... which is powerful but still finite) and allowing
arbitrary rule changes would vastly increase that power.
There are some more subtle issues=E2=80=94 if the acceptance of chain B
depends on if you've seen orthogonal chains A or A' first then there
can be a carefully timed announcement of A and A' which forever
prevents global convergence (thanks to a finite speed of light an
attacker can make sure some nodes see A first, some A'). If a rule
change can be reorged out, then it's not really a rule=E2=80=94 any actual
rule prohibits otherwise valid blocks that violate it (and without
this distinction you might as well implement the 'rule' as miner
preferences). Additionally there is the very hard software engineering
QA problem for a sufficiently complex rule language=E2=80=94 script isn't
turing complete and look at all the issues it has had.
In summary=E2=80=94 this sort of thing, which has come up before, is
technically interesting and fun to think about but it would make for
substantial engineering challenges and would not be obviously
compatible with the economic motivations which make Bitcoin secure nor
would it be morally compatible with the social contract embedded in
the system today.
|
