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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <1240902@gmail.com>) id 1YyTuy-0001R7-CF
for bitcoin-development@lists.sourceforge.net;
Fri, 29 May 2015 23:42:24 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.169 as permitted sender)
client-ip=209.85.212.169; envelope-from=1240902@gmail.com;
helo=mail-wi0-f169.google.com;
Received: from mail-wi0-f169.google.com ([209.85.212.169])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YyTuw-0005Io-Uy
for bitcoin-development@lists.sourceforge.net;
Fri, 29 May 2015 23:42:24 +0000
Received: by wifw1 with SMTP id w1so41646813wif.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 29 May 2015 16:42:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.205.5 with SMTP id lc5mr20271354wjc.74.1432942936961;
Fri, 29 May 2015 16:42:16 -0700 (PDT)
Received: by 10.180.208.69 with HTTP; Fri, 29 May 2015 16:42:16 -0700 (PDT)
In-Reply-To: <554BE0E1.5030001@bluematt.me>
References: <554BE0E1.5030001@bluematt.me>
Date: Sat, 30 May 2015 07:42:16 +0800
Message-ID: <CAFzgq-xByQ1E_33_m3UpXQFUkGc78HKnA=7XXMshANDuTkNsvA@mail.gmail.com>
From: Chun Wang <1240902@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.4 (-)
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
(1240902[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (1240902[at]gmail.com)
-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: 1YyTuw-0005Io-Uy
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:42:24 -0000
Hello. I am from F2Pool. We are currently mining the biggest blocks on
the network. So far top 100 biggest bitcoin blocks are all from us. We
do support bigger blocks and sooner rather than later. But we cannot
handle 20 MB blocks right now. I know most blocks would not be 20 MB
over night. But only if a small fraction of blocks more than 10 MB, it
could dramatically increase of our orphan rate, result of higher fee
to miners. Bad miners could attack us and the network with artificial
big blocks. As yhou know, other Chinese pools, AntPool, BW, they
produces ASIC chips and mining mostly with their own machines. They do
not care about a few percent of orphan increase as much as we do. They
would continue their zero fee policy. We would be the biggest loser.
As the exchanges had taught us, zero fee is not health to the network.
Also we have to redevelop our block broadcast logic. Server bandwidth
is a lot more expensive in China. And the Internet is slow. Currently
China has more than 50% of mining power, if block size increases, I
bet European and American pools could suffer more than us. We think
the max block size should be increased, but must be increased
smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
and so on. Thanks.
On Fri, May 8, 2015 at 6:02 AM, Matt Corallo <bitcoin-list@bluematt.me> wrote:
> OK, so lets do that. I've seen a lot of "I'm not entirely comfortable
> with committing to this right now, but think we should eventually", but
> not much "I'd be comfortable with committing to this when I see X". In
> the interest of ignoring debate and pushing people towards a consensus
> at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the
> second.
>
> Personally, there are several things that worry me significantly about
> committing to a blocksize increase, which I'd like to see resolved
> before I'd consider supporting a blocksize increase commitment.
>
> * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today. I'd expect to see these not only implemented but
> being used in production (though I dont particularly care about them
> being all that stable). I'd want to see measurements of how they perform
> both in production and in the face of high packet loss (eg across the
> GFW or in the case of small/moderate DoS). 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.
>
> * 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. I know StrawPay is working on development,
> though its not obvious to me how far they are from their website, but I
> dont know of any commitments by large players (either SPV wallets,
> centralized wallet services, payment processors, or any others) to
> support such a system (to be fair, its probably too early for such
> players to commit to anything, since anything doesnt exist in public).
>
> * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system. If we're just building Bitcoin
> to work in five years, great, but if we want it all to keep working as
> subsidy drops significantly, I'd like a better answer than "we'll deal
> with it when we get there" or "it will happen, all the predictions based
> on people's behavior today say so" (which are hopefully invalid thanks
> to the previous point). Ideally, I'd love to see some real free pressure
> already on the network starting to develop when we commit to hardforking
> in a year. Not just full blocks with some fees because wallets are
> including far greater fees than they really need to, but software which
> properly handles fees across the ecosystem, smart fee increases when
> transactions arent confirming (eg replace-by-fee, which could be limited
> to increase-in-fees-only for those worried about double-spends).
>
> I probably forgot one or two and certainly dont want to back myself into
> a corner on committing to something here, but those are a few things I
> see today as big blockers on larger blocks.
>
> Luckily, people have been making progress on building the software
> needed in all of the above for a while now, but I think they're all
> very, very immature today.
>
> On 05/07/15 19:13, Jeff Garzik wrote:> On Thu, May 7, 2015 at 3:03 PM,
> Matt Corallo <bitcoin-list@bluematt.me
>> <mailto:bitcoin-list@bluematt.me>> wrote:
> -snip-
>>> If, instead, there had been an intro on the list as "I think we should
>>> do the blocksize increase soon, what do people think?", the response
>>> could likely have focused much more around creating a specific list of
>>> things we should do before we (the technical community) think we are
>>> prepared for a blocksize increase.
>>
>> Agreed, but that is water under the bridge at this point. You - rightly
>> - opened the topic here and now we're discussing it.
>>
>> Mike and Gavin are due the benefit of doubt because making a change to a
>> leaderless automaton powered by leaderless open source software is
>> breaking new ground. I don't focus so much on how we got to this point,
>> but rather, where we go from here.
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
