[bitcoin-dev] Consensus census

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 at 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 at toom.im. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151227/824ec2c9/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151227/824ec2c9/attachment-0001.sig>