How relevant is the Chinese Great Firewall in the blocksize debate?

How relevant is the Chinese Great Firewall in the blocksize debate?

Mike Hearn said the following:

The reason the true limit seems to be 700 kilobytes instead of the theoretical 1000 is that sometimes miners produce blocks smaller than allowed and even empty blocks, despite that there are lots of transactions waiting to confirm — this seems to be most frequently caused by interference from the Chinese “Great Firewall” censorship system.

Also, he mentioned on another occasion that the bandwidth through the GFW, is only about 50 KB/s, sometimes less. In the best scenario you can get 3 MB/s, according to Scaling Bitcoin Conference.

Mike put lots of accusations towards the Chinese regarding blockchain development, but how much of that is true and if there's some solution, what will be the solution?

http://bit.ly/2AmXvRB

Comments

Post a Comment

Popular posts from this blog

How to discover startup flags or command-line options for bitcoind?

How to discover startup flags or command-line options for bitcoind? I'd like to query the Bitcoin daemon (bitcoind) to find out what startup flags (command-line options) were sent to it on startup (or the current state if it has changed, e.g. -server=0/1 changing). For example, I may want to know if -addresstype, -disablewallet, -rescan, or -uacomment=<cmt> or some other flag has been set. Or for Namecoin, it would be very useful to know if -namehistory has been set. Is there an RPC or any other method to find out? Or, to ask the question a different way... src/bitcoind.cpp's bool AppInit(int argc, char* argv[]) method calls ParseParameters(argc, argv);, which is in src/util.cpp. In src/util.cpp we have: map<string, string> mapArgs; static map<string, vector<string> > _mapMultiArgs; const map<string, vector<string> >& mapMultiArgs = _mapMultiArgs; To store flags/options/args. I'd basically just like to get whatever is in tho...
Read more

New ccminer 2.3.1 from Tpruvot with Lyra2REv3 Support and More

Image
New ccminer 2.3.1 from Tpruvot with Lyra2REv3 Support and More It has been a quite a while since the last update of tpruvot’s ccminer fork ( source ), but there it is a new version 2.3.1 available now that comes with support for Lyra2REv3, sha256q, exosis and Blake2b standard algorithms. The official binary is 64-bit Windows only built with CUDA 10 for SM3+ devices, SM 7.5 architecture is also supported, but doesn’t seem to bring any advantage, for others variants you can build from the source code as the miner is opensource. Do note that CUDA 10 support requires an Nvidia video driver version 410.48 or newer. The most notable thing abut the new release is the support for Lyra2REv3 that will soon be used by the Vertcoin (VTC) after the upcoming hardfork expected to happen in less than two days. The fork should happen in around February 2nd as it is planned for block 1080000, so make sure you are ready with the required local wallet upgrade (if you are using one) as well as with a min...
Read more

Bitcoin HD Wallets with hardened derivation and watch-only addresses

Bitcoin HD Wallets with hardened derivation and watch-only addresses I'm learning about the details of how HD wallets work. After reading the BIP32 and BIP44 documents thoroughly and supplementing it with Mastering Bitcoin there's still on aspect that I can't figure out. Say I derive an extended private key with the BIP44 first account, first address path path: m/44'/0'/0'/0/0 and then I convert the extended private key into an extended public key. Based on what I've read so far proper way would be to take the extended public key and work with an entirely non-hardened path like: M/0/1 , M/0/2 ? Is this the correct way to do it ? My problem is that a public key of M/44'/0'/0'/0/1 will not be the same as M/0/1. I'm just trying to make sure I'm using the derivation paths correctly. Thanks a lot! http://bit.ly/2DpBKlI
Read more