[bitcoin-dev] Consensus census

[Jonathan Toomim <j@toom.im>]

[-- Attachment #1.1: Type: text/plain, Size: 4033 bytes --]

I traveled around in China for a couple weeks after Hong Kong to visit with miners and confer on the blocksize increase and block propagation issues. I performed an informal survey of a few of the blocksize increase proposals that I thought would be likely to have widespread support. The results of the version 1.0 census are below.

My brother is working on a website for a version 2.0 census. You can view the beta version of it and participate in it at https://bitcoin.consider.it. If you have any requests for changes to the format, please CC him at m@toom.im.

https://docs.google.com/spreadsheets/d/1Cg9Qo9Vl5PdJYD4EiHnIGMV3G48pWmcWI3NFoKKfIzU/edit#gid=0

Or a snapshot for those behind the GFW without a VPN:
http://toom.im/files/consensus_census.pdf

HTML follows:

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
F2Pool	22%	N/A	Acceptable	Acceptable	Preferred	Acceptable	Acceptable	Too fast
AntPool	23%	Too slow	Acceptable	Acceptable	Acceptable	N/A	N/A	Too fast
Bitfury	18%	N/A	Acceptable	Probably/maybe	Maybe	N/A	Probably too fast	Too fast
BTCC Pool	11%	N/A	Acceptable	Acceptable	Acceptable	Acceptable	Acceptable, I think	N/A
KnCMiner	7%	N/A	Probably?	Probably?	"We like 2-4-8"	Probably?	N/A	N/A
BW.com	7%	N/A	N/A	N/A	N/A	N/A	N/A	N/A
Slush	4%	N/A	N/A	N/A	N/A	N/A	N/A	N/A
21 Inc.	3%	N/A	N/A	N/A	N/A	N/A	N/A	N/A
Eligius	1%	N/A	N/A	N/A	N/A	N/A	N/A	N/A
BitClub	1%	N/A	N/A	N/A	N/A	N/A	N/A	N/A
GHash.io	1%	N/A	N/A	N/A	N/A	N/A	N/A	N/A
Misc	2%	N/A	N/A	N/A	N/A	N/A	N/A	N/A
Certainly in favor			74%	56%	63%	33%	22%
Possibly in favor			81%	81%	81%	40%	33%	0%
Total votes counted			81%	81%	81%	40%	51%	63%
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.
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.
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.
KnC: I only had short conversations with Sam Cole, but from what I can tell, they would be okay with just about anything reasonable.
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.
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, 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.


[-- Attachment #1.2: Type: text/html, Size: 34546 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]