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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1YyTeh-0003C9-OC
for bitcoin-development@lists.sourceforge.net;
Fri, 29 May 2015 23:25:35 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bluematt.me
designates 192.241.179.72 as permitted sender)
client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me;
helo=mail.bluematt.me;
Received: from mail.bluematt.me ([192.241.179.72])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YyTeg-0004uB-He
for bitcoin-development@lists.sourceforge.net;
Fri, 29 May 2015 23:25:35 +0000
Received: from [172.17.0.1] (gw.vpn.bluematt.me [162.243.132.6])
by mail.bluematt.me (Postfix) with ESMTPSA id 6F68154DA8;
Fri, 29 May 2015 23:25:28 +0000 (UTC)
Message-ID: <5568F567.3050608@bluematt.me>
Date: Fri, 29 May 2015 23:25:27 +0000
From: Matt Corallo <bitcoin-list@bluematt.me>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Gavin Andresen <gavinandresen@gmail.com>
References: <554BE0E1.5030001@bluematt.me>
<CABsx9T2ysKj5HVbN_7_o33fMehs4KH6E_R583Mt_VPC4gDA0LQ@mail.gmail.com>
In-Reply-To: <CABsx9T2ysKj5HVbN_7_o33fMehs4KH6E_R583Mt_VPC4gDA0LQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.5 (-)
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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1YyTeg-0004uB-He
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
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, 29 May 2015 23:25:35 -0000
On 05/29/15 22:36, Gavin Andresen wrote:
> Matt brought this up on Twitter, I have no idea why I didn't respond
> weeks ago (busy writing blog posts, probably):
>
> On Thu, May 7, 2015 at 6:02 PM, Matt Corallo <bitcoin-list@bluematt.me
> <mailto:bitcoin-list@bluematt.me>> wrote:
>
>
>
> * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.
>
>
> If block propagation isn't fixed, then mines have a strong incentive to
> create smaller blocks.
>
> So the max block size is irrelevant, it won't get hit.
Sadly, this is very far from the whole story. The issue of miners
optimizing for returns has been discussed several times during this
discussion, and, sadly, miners who are geographically colocated who are
optimizing for returns with a free-floating blocksize will optimize away
50% of the network!
>
> In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the
> system.
>
>
> See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for
> analysis of "but that means bigger miners can get an advantage" argument.
>
> Executive summary: if little miners are stupid and produce huge blocks,
> then yes, big miners have an advantage.
I'll talk about transaction fees in a second, but there are several
problems with this already. As pointed out in the original mail, gfw has
already been known to interfere with Bitcoin P2P traffic. So now by
"little" miners, you mean any miner who is not located in mainland
China? Whats worse, the disadvantage is symmetric - little miners are at
a disadvantage when *anyone* mines a bigger block, and miners dont even
have to be "evil" for this to happen - just optimize for profits.
> But they're not, so they won't.
I dont know what you're referring to with this. Are you claiming little
miners today optimize for relay times and have good visibility into the
Bitcoin network and calculate an optimal block size based on this (or
would with a 20MB block size)?
> Until the block reward goes away, and assuming transaction fees become
> an important source of revenue for miners.
> I think it is too early to worry about that; see:
>
> http://gavinandresen.ninja/when-the-block-reward-goes-away
You dont make any points here with which I can argue, but let me respond
with the reason /I/ think it is a problem worth thinking a little bit
about...If we increase the blocksize sufficiently such that transaction
fees are not the way in which miners make their money, then either
miners are not being funded (ie hashpower has to drop to very little),
or the only people mining/funding miners are large orgs who are
"running" Bitcoin (ie the web wallets, payment processors, big
merchants, and exchanges of the world). Sadly, this is no longer a
decentralized Bitcoin and is, in fact, pretty much how the banking world
works today.
I'm not sure who, if anyone, claims Bitcoin is novel or interesting for
any reason other than its decentralization properties, and, in a world
which you are apparently proposing, the "natural" course of things is to
very strongly centralize.
> * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace.
>
>
> Ok. What does this have to do with the max block size?
>
> Are you arguing that work won't happen if the max block size increases?
Yes, I am arguing that by increasing the blocksize the incentives to
actually make Bitcoin scale go away. Even if amazing technologies get
built, no one will have any reason to use them.
> * I'd like to see some better conclusions to the discussion around
>
> long-term incentives within the system.
>
>
> Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away
> for what I think about that.
|
