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
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 18F348FC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 Nov 2015 09:31:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C8D7109
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 Nov 2015 09:31:20 +0000 (UTC)
Received: from mail-io0-f180.google.com ([209.85.223.180]) by
mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id
0MVc7t-1Ztp3w0S0F-00ZAYJ for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 Nov 2015 10:31:19 +0100
Received: by iofh3 with SMTP id h3so119821383iof.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 Nov 2015 01:31:18 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.107.157.85 with SMTP id g82mr23067296ioe.144.1447493478345;
Sat, 14 Nov 2015 01:31:18 -0800 (PST)
Received: by 10.36.49.200 with HTTP; Sat, 14 Nov 2015 01:31:18 -0800 (PST)
In-Reply-To: <1447459320911.325f57c8@Nodemailer>
References: <201511132228.47815.luke@dashjr.org>
<1447459320911.325f57c8@Nodemailer>
Date: Sat, 14 Nov 2015 10:31:18 +0100
X-Gmail-Original-Message-ID: <CALqxMTFE9W0nxGHvcJN_Wz88b00o-K29GRTbHJv+VSpYAJKUNQ@mail.gmail.com>
Message-ID: <CALqxMTFE9W0nxGHvcJN_Wz88b00o-K29GRTbHJv+VSpYAJKUNQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: digitsu@gmail.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:89Lax6em2z/db+AsS8YGOGGOgr4FGcp4B/VTERHdiiQfaGV4FgW
yaApLW4hrikWJC0ndv1edFagprpBm5wDvz8v5yXNpfP4AYfAf0cO9xcta9oQR227+7B6j/D
JlicPImDnsMwT22v9rgZIzb2c/BbAQBei3lPUsPLb4ywk0DA6EDgWoNsLm61WNl/Nmy++g9
FUHnVSYq+QqiUo5iR1vVg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:xsJozWVIOWE=:TvkjTpQ9PHhUbXK7dU6x9X
fJa/O2/dB8caE1lX3wW6szAn+NrM4Ladj5ue+vyirTyka6Nd7D+9bg38vFF2VzkoqG+OlNKPh
TdZDoQzlQixm8nv+yS81QhRyXAkBs2/VA8BCq8J8XdoVEHtbQuIYyV/9QlpWhFb+1v6B1EamQ
tP4XjP4ydBl2awRca65Ll8JpqLLIrcvQ4hsrQHMGEY55XK5wEcEgCPMdjmSm+AtT9FlsdR5yt
d62Kq/OWHyE0oShrGVB2Xk3Ae0i0Mkcvf3buyD/Lm+UBOhRIaIxzpP/7DeBuRWojwkqEsXaNV
Ro/X7VRKnjbv8s94jDJJDl3ut/4wTGPdcnA/gN6mZoy+HiLQyd8RnkxoJUMXFSVcoFF0JDYT+
i1Cp3Aa7JRg4VCWEllivV1Q77ecysnN/1qhBCxsS88ubn/yBEbx0X3p7AXZwhQH7BZl0rS6yK
ZSX7VmaJhUDQ4QPsa+Rf7rYtISaR1pBM8hdDIALJsnB1hzqcaEkBKYT1vJUMS/29WBwjehBzt
60kLSMIqcTH/wgATtLyPgLD59vQO0dsqBrZ5GSih2eZgFaImq6h4EPvFVy+T7j2aAqPGUjYTm
39dIrDq8E/nGnQzHMchbszKrRnJU4VcYN40BOCo0Ro0g+jrQi9SQPhdqXsi2VQ2ZdQpnmN/pO
plSb1gsYykat4FUQWnCI2xQ9uY/jPOraZCnijYOl6rE1d06pbPb91fAf1onuSAlH0YHPpm/o/
m3KxHwOe0reGuGuG
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
John Sacco <johnsock@gmail.com>
Subject: Re: [bitcoin-dev] BIP - Block size doubles at each reward halving
with max block size of 32M
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Nov 2015 09:31:21 -0000
There is a difference between miners signalling intent (as they have
been for various BIPs, which is mostly informational only - they are
mostly not running the code, and in some cases it is not implemented,
so they cant be) there is a difference between that and a 95% miner
majority consensus rule. Former can be useful information as you
said, latter implies as Luke described something that is not really
accurate, it is not strictly only a miner upgrade needed for basic
safety as with soft-forks. If you look at BIP 103 for example it is
flag day based, and I think this is a more accurate approach. Also
with miner votes they can be misleading - vote for one thing, but run
something else; what they are running is not generally
detectable/enforceable - see for example what happened with the BIP66
accidental fork due to "SPV mining" (ie validationless mining).
A hard-fork is for everyone to upgrade and talk with each other to see
that the vast majority is on the same plan which includes users,
ecosystem companies & miners.
Adam
On 14 November 2015 at 01:02, digitsu412 via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Well I'd like to think that with an economy all parts of it interact with
> each other in ways more complex than simplistic imperative logic.
>
> I agree that the economic majority is essentially what matters in a hard
> fork but everyone (miners,devs,public thought leaders,businesses) is part=
of
> that economy. Additionally what miners signal as their intention affects =
the
> decision of that economic majority (and vice versa). You can see the
> effects of this in traditional political processes in how preliminary vot=
e
> polling results affect (reinforce) the final vote.
> We also can see the results of this in (dare I mention) the whole XT affa=
ir
> which had the signed intent of many of the economy (payment processors an=
d
> wallets and one miner pool) and the rest of the miners did not go along w=
ith
> it. This experiment either means that the rest of the miners couldn't be
> bothered to signal at all (because they didn't know how) or they were
> affected by the influence of core devs or the opinions of others on the
> matter and rejected the economic majority. (Which would imply core devs
> have some power by way of indirect influence) I would be inclined to beli=
eve
> the latter was more likely.
>
> The conclusion which this would seem to imply is that at the very least,
> miners matter (to what exact extent is debatable). And although there is=
no
> direct control of any party over the other in the strict sense, the publi=
c
> vocal opinions of any part of the Bitcoin economy does have an effect in =
its
> ability to sway the opinions of the other parts.
>
> Digitsu
>
> =E2=80=94 Regards,
>
>
> On Sat, Nov 14, 2015 at 7:29 AM, Luke Dashjr <luke@dashjr.org> wrote:
>>
>> On Friday, November 13, 2015 4:01:09 PM digitsu@gmail.com wrote:
>> > Forgive the frankness but I don't see why signaling your intent to
>> > support
>> > an upgrade to one side of a hard fork can be seen as a bad thing. If f=
or
>> > nothing else doesn't this make for a smoother flag day? (Because once
>> > you
>> > signal your intention, it makes it hard to back out on the commitment.=
)
>>
>> It isn't a commitment in any sense, nor does it make it smoother, becaus=
e
>> for
>> a hardfork to be successful, it is the *economy* that must switch
>> entirely.
>> The miners are unimportant.
>>
>> > If miners don't have any choice in hard forks, who does? Just the core
>> > devs?
>>
>> Devs have even less of a choice in the matter. What is relevant is the
>> economy: who do people want to spend their bitcoins with? There is no
>> programmatic way to determine this, especially not in advance, so the be=
st
>> we
>> can do is a flag day that gets called off if there isn't clear consensus=
.
>>
>> Luke
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
