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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 022E8EBE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Feb 2016 20:37:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 7D228188
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Feb 2016 20:37:20 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 1BC6B38A2C8B;
Sat, 6 Feb 2016 20:36:27 +0000 (UTC)
X-Hashcash: 1:25:160206:gavinandresen@gmail.com::8FujWeBXj2YAiIe3:cB9=f
X-Hashcash: 1:25:160206:jtimon@jtimon.cc::slnYdA2pju2Cgff8:/eQB
X-Hashcash: 1:25:160206:bitcoin-dev@lists.linuxfoundation.org::eQZLAIJ5YxQzWJDj:Ym/C
From: Luke Dashjr <luke@dashjr.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Date: Sat, 6 Feb 2016 20:36:23 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; )
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
<CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com>
<CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
In-Reply-To: <CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201602062036.25979.luke@dashjr.org>
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_SBL,
RP_MATCHES_RCVD autolearn=no 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>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
megabytes
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, 06 Feb 2016 20:37:21 -0000
On Saturday, February 06, 2016 3:37:30 PM Gavin Andresen wrote:
> I suspect there ARE a significant percentage of un-maintained full nodes--
Do you have evidence these are intentionally unmaintained, and not users who
have simply not had time to review and decide on upgrading?
> There is broad agreement that a capacity increase is needed NOW.
If so, it is only based on misinformation. I am concerned you are implying
this conclusion is true. When I spoke with you maybe a year ago with my
concerns that block size might grow too fast, you suggested that the miners
could be trusted to not increase the block size until necessary (which is not
likely to be any time soon, despite the massive misinformation campaigns out
there).
> On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev
> > > > Miners express their support for this BIP by ...
> > >
> > > But miners don't get to decide hardforks. How does the economy
> > > express their support for it? What happens if miners trigger it
> > > without consent from the economy?
>
> "The economy" does support this.
I have seen evidence which suggests the contrary. For example:
https://twitter.com/barrysilbert/status/694911989701861376
Where is yours?
> > If you are intent on using the version bits to trigger the
> > hardfork, I suggest rephrasing this such that miners should
> > only enable the bit when they have independently confirmed
> > economic support (this means implementations need a config
> > option that defaults to off).
>
> Happy to add words about economic majority.
>
> Classic will not implement a command-line option (the act of running
> Classic is "I opt in"), but happy to add one for a pull request to Core,
> assuming Core would not see such a pull request as having any hostile
> intent.
But this isn't about the miner opting in, it is about the miner *observing
economic support* for the change. I have successfully downloaded Bitcoin
Classic's beta binaries without ANY warning that by running it, I am
expressing that I believe the economy has approved of a hardfork.
> > > SPV (simple payment validation) wallets are compatible with this
> > > change.
> >
> > Would prefer if this is corrected to "Light clients" or something.
> > Actual SPV wallets do not exist at this time, and would not be
> > compatible with a hardfork.
>
> Is there an explanation of SPV versus "Light Client" written somewhere more
> permanent than a reddit comment or forum post that I can point to?
Not that I am aware of. (But both reddit comments and forum posts have
outlived many other posts, such as blogs, so I'm not sure why to exclude them
specifically...)
In any case, since SPV nodes don't exist, there is probably no real need to
address them. Everyone will know what "light client" means.
> > I would also prefer to see any hardfork:
> > 2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
> > insecure.
>
> I haven't been paying attention to all of the
> "soft-hardfork/hard-softfork/etc" terminology so have no idea what you
> mean. Is THAT written up somewhere?
Working on a BIP draft for it, but it's not ready for publication yet. The
basic idea is to turn the merkle root in the block header into simply a hash
of a second block header, which is constructed to parse as a valid empty
generation transaction under the old rules. Thus, old nodes see the forked
blockchain as valid with continually growing work on it, but as if the blocks
were all empty. This protects them from attackers mining a short blockchain
they perceive as valid.
Luke
|
