Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
Nice insight Peter, This further confirms the real problem, which doesn't have much to do with blocksize but rather the connectivity of nodes in countries with not-so-friendly internet policies and deceptive connectivity. On Thu, Jun 18, 2015 at 6:00 PM, Tom Harding t...@thinlink.com wrote: On 06/12/2015 06:51 PM, Pieter Wuille wrote: However, it does very clearly show the effects of larger blocks on centralization pressure of the system. On 6/14/2015 10:45 AM, Jonas Nick wrote: This means that your scenario is not the result of a cartel but the result of a long-term network partition. Pieter, to Jonas' point, in your scenario the big miners are all part of the majority partition, so centralization pressure (pressure to merge with a big miner) cannot be separated from pressure to be connected to the majority partition. I ran your simulation with a large (20%) miner in a 20% minority partition, and 16 small (5%) miners in a majority 80% partition, well connected. The starting point was your recent update, which had a more realistic slow link speed of 100 Mbit/s (making all of the effects smaller). To summarize the results across both your run and mine: ** Making small blocks when others are making big ones - BAD ** As above, and fees are enormous - VERY BAD ** Being separated by a slow link from majority hash power - BAD ** Being a small miner with blocksize=20MB - *NOT BAD* Configuration: * Miner group 0: 20.00% hashrate, blocksize 2000.00 * Miner group 1: 80.00% hashrate, blocksize 100.00 * Expected average block size: 480.00 * Average fee per block: 0.25 * Fee per byte: 0.000521 Result: * Miner group 0: 20.404704% income (factor 1.020235 with hashrate) * Miner group 1: 79.595296% income (factor 0.994941 with hashrate) Configuration: * Miner group 0: 20.00% hashrate, blocksize 2000.00 * Miner group 1: 80.00% hashrate, blocksize 2000.00 * Expected average block size: 2000.00 * Average fee per block: 0.25 * Fee per byte: 0.000125 Result: * Miner group 0: 19.864232% income (factor 0.993212 with hashrate) * Miner group 1: 80.135768% income (factor 1.001697 with hashrate) Configuration: * Miner group 0: 20.00% hashrate, blocksize 2000.00 * Miner group 1: 80.00% hashrate, blocksize 100.00 * Expected average block size: 480.00 * Average fee per block: 25.00 * Fee per byte: 0.052083 Result: * Miner group 0: 51.316895% income (factor 2.565845 with hashrate) * Miner group 1: 48.683105% income (factor 0.608539 with hashrate) Configuration: * Miner group 0: 20.00% hashrate, blocksize 2000.00 * Miner group 1: 80.00% hashrate, blocksize 2000.00 * Expected average block size: 2000.00 * Average fee per block: 25.00 * Fee per byte: 0.012500 Result: * Miner group 0: 19.865943% income (factor 0.993297 with hashrate) * Miner group 1: 80.134057% income (factor 1.001676 with hashrate) -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- *Yifu Guo* *Life is an everlasting self-improvement.* -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
Nielsen's Law of Internet Bandwidth is simply not true, but if you look at data points like http://www.netindex.com/upload/ which will show we are at least on the right track, but this is flawed still. The fact of the matter is these speed tests are done from local origin to local destination within the city, let alone the country ( see note about how these test are only conducted 300 miles within the server). and our current internet infrastructure is set up with CDNs for the web and media consumption. these data points can not and should not be used to model the connectivity of a peer to peer network. Uplink bandwidth is scarce is China and expensive, avg about $37 per 1mbps after 5, but this is not the real problem. the true issue lies in the ISP transparent proxy they run. this is not a problem isolated in just China, Thailand and various other countries in Asia like Lebanon. I have also heard in various IRCs that southern France also face this similar issue due to poor routing configurations they have that prevents connections to certain parts of the world, unsure if this is a mistake or a geopolitical by-product. As for your question earlier Gavin, from Dallas TX to a VPS in Shanghai on 上海电信/Shanghai telecom, which is capped at 5mbps the data results match my concerns, I've gotten low as 83 Kbits/sec and as high as 9.24 Mbits/sec. and other ranges in between, none are consistent. ping avg is about 250ms. The temporary solution I recommend again from earlier is MPTCP: http://www.multipath-tcp.org/ which allows you to multiple interfaces/networks for a single TCP connection, this is mainly developed for mobile3g/wifi transition but I found uses to improve bandwidth and connection stability on the go by combining a local wifi/ethernet connection with my 3g phone tether. this allows you to set up a middlebox somewhere, put shadowsocks server on it, and on your local machine you can route all TCP traffic over the shadow socks client and MPTCP will automatically pick the best path for upload and download. On Mon, Jun 1, 2015 at 9:59 AM, Gavin Andresen gavinandre...@gmail.com wrote: On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang 1240...@gmail.com wrote: I cannot believe why Gavin (who seems to have difficulty to spell my name correctly.) insists on his 20MB proposal regardless the community. BIP66 has been introduced for a long time and no one knows when the 95% goal can be met. This change to the block max size must take one year or more to be adopted. We should increase the limit and increase it now. 20MB is simply too big and too risky, sometimes we need compromise and push things forward. I agree with any solution lower than 10MB in its first two years. Thanks, that's useful! What do other people think? Would starting at a max of 8 or 4 get consensus? Scaling up a little less than Nielsen's Law of Internet Bandwidth predicts for the next 20 years? (I think predictability is REALLY important). I chose 20 because all of my testing shows it to be safe, and all of my back-of-the-envelope calculations indicate the costs are reasonable. If consensus is 8 because more than order-of-magnitude increases are scary -- ok. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- *Yifu Guo* *Life is an everlasting self-improvement.* -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
I will abstain on this wrangle of when, Instead I'd like to address some of the network topology health issues that's been brought up in this debate. Due to how blocks are being broadcast by miners at the moment, it is not difficult to find the origin node of these blocks. These more influential origin nodes are a minority, about 100 out of ~6000, 2%. These data points are important to certain attack vectors. It is highly recommended that pools adopt broadcast logic that rotates broadcasting nodes and increase their node count.. Eloipool has this implanted for those seeking to adopt/see it in action in the wild. China is a particular worse-case due to the sporadic nature of their internet infrastructure, especially connecting from/to outside of gfw, on a average node-walk I can get up to a 10% difference while I know for a fact some of the nodes shown to be down are up. In F2Pool's case, I see 6 replay nodes, I don't know if that's enough or that's all the nodes F2Pool runs, but it may be beneficial to set up multi-homing with shadowsocks over mptcp to increase the stability. also see if you can get a CERNET connection to be part of your rotations since their backbone is quite good. comments, question and grievances welcome. On Sat, May 30, 2015 at 9:31 PM, Chun Wang 1240...@gmail.com wrote: On Sat, May 30, 2015 at 9:57 PM, Gavin Andresen gavinandre...@gmail.com wrote: Bad miners could attack us and the network with artificial big blocks. How? I ran some simulations, and I could not find a network topology where a big miner producing big blocks could cause a loss of profit to another miner (big or small) producing smaller blocks: http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners (the 0.3% advantage I DID find was for the situation where EVERYBODY was producing big blocks). If someone propagate a 20MB block, it will take at best 6 seconds for us to receive to verify it at current configuration, result of one percent orphan rate increase. Or, we can mine the next block only on the previous block's header, in this case, the network would see many more transaction-less blocks. Our orphan rate is about 0.5% over the past few months. If the network floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB block could contain an average of 5 transactions, hundred of thousands of sigops, Do you have an estimate how long it takes on the submitblock rpccall? For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars per month. We also use Aliyun and Linode cloud services for block propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for 100Mbps connectivity at Aliyun. For a single cross-border TCP connection, it would be certainly far slower than 12.5 MB/s. I think we can accept 5MB block at most. (sorry forgot to cc to the mailing list) -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- *Yifu Guo* *Life is an everlasting self-improvement.* -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
