Consensus census

	A	B	C	D	E	F	G	H	I
1	Miner	Hashrate	BIP103	2 MB now (BIP102)	2 MB now, 4 MB in 2 yr	2-4-8 (Adam Back)	3 MB now	3 MB now, 10 MB in 3 yr	BIP101
2	F2Pool	22%	N/A	Acceptable	Acceptable	Preferred	Acceptable	Acceptable	Too much, too fast
3	AntPool	23%	Too slow	Acceptable	Acceptable	Acceptable	Acceptable	Acceptable	Too much, too fast
4	Bitfury	18%	Too slow	Acceptable	Mostly acceptable	Mostly acceptable	Too much	Too much, too fast	Too much, too fast
5	BTCC Pool	11%	N/A	Preferred	Acceptable	Acceptable	Acceptable	Acceptable, I think	N/A
6	KnCMiner	7%	N/A	Probably?	Probably?	"We like 2-4-8"	Probably?	N/A	Probably?
7	BW.com	7%	N/A	Acceptable	Acceptable	Acceptable	Acceptable	Acceptable	N/A
8	Slush Pool	4%	Acceptable	Acceptable	Acceptable	Acceptable	Acceptable	Acceptable	Acceptable
9	21 Inc.	3%	N/A	N/A	N/A	N/A	N/A	N/A	N/A
10	Eligius	1%	N/A	N/A	N/A	N/A	N/A	N/A	N/A
11	BitClub	1%	N/A	N/A	N/A	N/A	N/A	N/A	N/A
12	GHash.io	1%	N/A	N/A	N/A	N/A	N/A	N/A	N/A
13	Misc	2%	N/A	N/A	N/A	N/A	N/A	N/A	N/A
14	Certainly in favor		4%	85%	85%	92%	67%	56%	4%
15	Possibly in favor		5%	92%	92%	92%	74%	67%	11%
16	Total votes counted		46%	93%	93%	93%	93%	86%	75%
17	Proportion of support:		11%	99%	99%	99%	80%	78%	15%
18
19							Last update:	2/5/2016 5:18:22	PST
20	F2Pool: Blocksize increase could be phased in at block 400,000. No floating-point math. No timestamp-based forking (block height is okay). Conversation was with Wang Chun via IRC.
21
22
23
24	AntPool/Bitmain: We should get miners and devs together for few rounds of voting to decide which plan to implement. (My brother is working on a tool which may be useful for this. More info soon.) The blocksize increase should be merged into Bitcoin Core, and should not be implemented in an alternate client like BitcoinXT. A timeline of about 3 months for the fork was discussed, though I don't know if that was acceptable or preferable to Bitmain. Conversation was mostly with Micree Zhan and Kevin Pan at the Bitmain HQ. Jihan Wu was absent.
25
26
27
28
29	Bitfury: We should fix performance issues in bitcoind before 4 MB, and we MUST fix performance issues before 8 MB. A plan that includes 8 MB blocks in the future and assumes the performance fixes will be implemented might be acceptable to us, but we'll have to evaluate it more before coming to a conclusion. 2-4-8 "is like parachute basejumping - if you jump, and was unable to fix parachute during the 90sec drop - you will be 100% dead. plan A) [multiple hard forks] more safe." Conversation was with Alex Petrov at the conference and via email. Verbatim comments from Alex for each of the proposals are on the right.						Bip103 unbalanced. (Slow/bad)
30							Bip102 - ok.
31							2/4mb - moderated ok. require changes in bitcoind.
32							2-4-8 - moderated ok. Require changes asap.
33							3mb - now. Bitcoin net not ready yet.
34							3now/10later - too fast step from 3 to 10.
35							Bip101 - too fast/ non balanced.
36
37	KnC: I only had short conversations with Sam Cole, but from what I can tell, they would be okay with just about anything reasonable.
38
39
40	BTCC: It would be much better to have the support of Core, but if Core doesn't include a blocksize increase soon in the master branch, we may be willing to start running a fork. Conversation was with Samson Mow and a few others at BTCC HQ.
41
42
43
44	BW: Our feeling at BW is to ensure the interests of miners, and to support simple, safe, and incremental expansion of block progress. For example the 2-4-8 increase is something we need right now; there are some excellent but overcomplicated solutions that will require a lot of time to implement, and we must plan for our future. BIP102, 2mb now, 4 mb in 2 years, 2-4-8 (Adam Back), 2mb now, 3mb now, 10mb in 3 years, these solutions that inherently guarantee blockchain stability and small expansion are all feasible.
45
46
47
48
49
50	BitClub: The representative who claimed to be from BitClub, James Hilliard (a.k.a. Lightsword), does not appear to be trustworthy. I have removed his contribution.
51
52
53
54	Slush Pool: We accept any reasonable solution with solid implementation. Our philosophy is to offer multiple backends and let our users to vote with their mining power, instead of decide for them. However we encourage Bitcoin Core developers to improve its performance as well as improve P2P protocol to avoid retransmits of every transactions twice. This must happen before any significant increase of blocksize limit.
55
56
57
58
59
60	The conversations I had with all of these entities were of an informal, non-binding nature. Positions are subject to change. BIP100 was not included in my talks because (a) coinbase voting already covers it pretty well, and (b) it is more complicated than the other proposals and currently does not seem likely to be implemented. I generally did not bring up SegWit during the conversations I had with miners, and neither did the miners (except BitClub), so it is also absent. (I thought that it was too early for miners to have an informed opinion of SegWit's relative merits.) I have not had any contact with BW.com or any of the smaller entities. Questions can be directed to j@toom.im.
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