Re: [Bitcoin-development] Block Size Increase Requirements
On Sun, May 31, 2015 at 10:59 AM, Jorge Timón jti...@jtimon.cc wrote: Whatever...let's use the current subsidies, the same argument applies, it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B. Miner B would still go out of business, bigger blocks still mean more mining and validation centralization Sorry, but that's ridiculous. If Miner B is leaving 18BTC per block on the table because they have bad connectivity, then they need to pay for better connectivity. If you are arguing I should be able to mine on a 56K modem connection from the middle of the Sahara then we're going to have to agree to disagree. So: what is your specific proposal for minimum requirements for connectivity to run a full node? The 20MB number comes from estimating costs to run a full node, and as my back-and-forth to Chang Wung shows, the costs are not excessive. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On May 31, 2015 5:08 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Sun, May 31, 2015 at 10:59 AM, Jorge Timón jti...@jtimon.cc wrote: Whatever...let's use the current subsidies, the same argument applies, it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B. Miner B would still go out of business, bigger blocks still mean more mining and validation centralization Sorry, but that's ridiculous. If Miner B is leaving 18BTC per block on the table because they have bad connectivity, then they need to pay for better connectivity. Well, I was assuming they just can't upgrade their connection (without moving thei operations to another place). Maybe that assumption is ridiculous as well. If you are arguing I should be able to mine on a 56K modem connection from the middle of the Sahara then we're going to have to agree to disagree. No, I'm not suggesting that. So: what is your specific proposal for minimum requirements for connectivity to run a full node? The 20MB number comes from estimating costs to run a full node, and as my back-and-forth to Chang Wung shows, the costs are not excessive. Well, you were I think assuming a new desktop connecting from somewhere in the US. I would be more confortable with an eee pc from a hotel in India, for example. But yeah, targeting some concrete minimum specs seems like the right approach for deciding how far to go when increasing centralization. But hitting the limit will be chaos seems to imply that completely removing the consensus maximum blocksize is the only logical solution. What happens when we hit the limit next time? When do we stop kicking the can down the road? When do we voluntarily get that chaos? Again, that's too far away in the future to worry about it is not a very conving answer to me. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [Bulk] Re: Fwd: Block Size Increase Requirements
On Sun, May 31, 2015 at 9:31 AM, gb kiw...@yahoo.com wrote: Aren't you calculating bandwidth for a singly-connected node? A highly connected miner could have 30-100 node connections so you probably need to increase your traffic estimates by that factor. I.e. For 100MB blocks, 30-100 Mbps and $60-$100 per day data costs. No, randomly connected gossip networks (which is what the Bitcoin p2p network is) don't work that way, bandwidth is (roughly) O(N) where N is the number of bytes relayed to everybody. (it is actually a small multiple of N, because of the overhead of 'inv' messages, and if we ever get really serious about scaling up we'll need to fix the protocol to reduce that overhead, but that won't be a problem for years). -- -- Gavin Andresen -- ___ 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
He also said that the equation for miners has many variables, as it should. There is no disadvantage if the network speed is the same between the miners. If there is a difference in network speed, the miner is incentivized to invest in their network infrastructure. 2015-05-31 23:55 GMT+01:00 Alex Mizrahi alex.mizr...@gmail.com: Yes, if you are on a slow network then you are at a (slight) disadvantage. So? Chun mentioned that his pool is on a slow network, and thus bigger blocks give it an disadvantage. (Orphan rate is proportional to block size.) You said that no, on contrary those who make big blocks have a disadvantage. And now you say that yes, this disadvantage exist. Did you just lie to Chun? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
2015-06-01 0:40 GMT+01:00 Pindar Wong pindar.w...@gmail.com: On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe ricardojdfil...@gmail.com wrote: He also said that the equation for miners has many variables, as it should. There is no disadvantage if the network speed is the same between the miners. Hi, Is that an assumption? no, let me rephrase: The disadvantage alex refers to only exists if miners do not have the same network speed. If there is a difference in network speed, the miner is incentivized to invest in their network infrastructure. Perhaps it's best not to assume that investing in Internet network infrastructure's a free or open market everywhere. Just like easy ASIC access, low price electricity, etc are not a free and open market. p. 2015-05-31 23:55 GMT+01:00 Alex Mizrahi alex.mizr...@gmail.com: Yes, if you are on a slow network then you are at a (slight) disadvantage. So? Chun mentioned that his pool is on a slow network, and thus bigger blocks give it an disadvantage. (Orphan rate is proportional to block size.) You said that no, on contrary those who make big blocks have a disadvantage. And now you say that yes, this disadvantage exist. Did you just lie to Chun? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
On Mon, Jun 1, 2015 at 7:58 AM, Ricardo Filipe ricardojdfil...@gmail.com wrote: 2015-06-01 0:40 GMT+01:00 Pindar Wong pindar.w...@gmail.com: On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe ricardojdfil...@gmail.com wrote: He also said that the equation for miners has many variables, as it should. There is no disadvantage if the network speed is the same between the miners. Hi, Is that an assumption? no, let me rephrase: The disadvantage alex refers to only exists if miners do not have the same network speed. If there is a difference in network speed, the miner is incentivized to invest in their network infrastructure. Perhaps it's best not to assume that investing in Internet network infrastructure's a free or open market everywhere. Just like easy ASIC access, low price electricity, etc are not a free and open market. -- point well made and taken. p. p. 2015-05-31 23:55 GMT+01:00 Alex Mizrahi alex.mizr...@gmail.com: Yes, if you are on a slow network then you are at a (slight) disadvantage. So? Chun mentioned that his pool is on a slow network, and thus bigger blocks give it an disadvantage. (Orphan rate is proportional to block size.) You said that no, on contrary those who make big blocks have a disadvantage. And now you say that yes, this disadvantage exist. Did you just lie to Chun? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
Yes, if you are on a slow network then you are at a (slight) disadvantage. So? Chun mentioned that his pool is on a slow network, and thus bigger blocks give it an disadvantage. (Orphan rate is proportional to block size.) You said that no, on contrary those who make big blocks have a disadvantage. And now you say that yes, this disadvantage exist. Did you just lie to Chun? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On Sun, May 31, 2015 at 3:05 AM, Peter Todd p...@petertodd.org wrote: Yeah, I'm pretty surprised myself that Gavin never accepted the compromises offered by others in this space for a slow growth solution What compromise? I haven't seen a specific proposal that could be turned into a pull request. Something important to note in Gavin Andresen's analysises of this issue is that he's using quite optimistic scenarios for how nodes are connected to each other. NO I AM NOT. I simulated a variety of connectivities; see the .cfg files at https://github.com/gavinandresen/bitcoin_miningsim The results I give in the are bigger blocks better blog post are for WORST CASE connectivity (one dominant big miner, multiple little miners, big miner connects to only 30% of little miners, but all the little miners connected directly to each other). For instance, assuming that connections between miners are direct is a very optimistic assumption Again, I did not simulate all miners directly connected to each other. I will note that miners are VERY HIGHLY connected today. It is in their best interest to be highly connected to each other. that depends on a permissive, unregulated, environment where miners co-operate with each other - obviously that's easily subject to change! Really? How is that easily subject to change? If it is easily subject to change, do bigger blocks have any effect? Why are 1MB blocks not subject to change? I talk about what if your government bans Bitcoin entirely here: http://gavinandresen.ninja/big-blocks-and-tor ... and the issues are essentially the same, independent of block size. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [Bulk] Re: Fwd: Block Size Increase Requirements
Aren't you calculating bandwidth for a singly-connected node? A highly connected miner could have 30-100 node connections so you probably need to increase your traffic estimates by that factor. I.e. For 100MB blocks, 30-100 Mbps and $60-$100 per day data costs. You should be able to handle 20MB blocks no problem; if I round up to 100MB per block that works out to 1.3Mbps. 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. That speed will handle 20MB blocks no problem. If each 20MB block is 100MB of data up/down the wire (I'm vastly over-estimating, after optimization it should be 40MB) then you'll be paying...uhhh: 0.1 GB / block-data-on-wire * 144 blocks/day * 30.5 days/month * 0.13 $ / GB = $57 Less than $2 per day in bandwidth. For a single cross-border TCP connection, it would be certainly far slower than 12.5 MB/s. That's OK, you'll 1.3Mbps or less -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
On Sat, May 30, 2015 at 9:31 PM, Chun Wang 1240...@gmail.com wrote: 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. That orphan rate increase will go to whoever is producing the 20MB blocks, NOT you. 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. Are you sure that is the best strategy? If a big block is slow to propagate, I suspect it will be better to punish the miner that created it by refusing to build on it until it has been fully validated. I'll try to find time to run a couple of simulations. 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? I can benchmark it. It should be pretty fast, and sipa has a couple of patches pending to make the UTXO cache much faster. It can be fast because the vast majority of the work of validating all those transactions can happen as they are received into the memory pool. For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars per month. You should be able to handle 20MB blocks no problem; if I round up to 100MB per block that works out to 1.3Mbps. 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. That speed will handle 20MB blocks no problem. If each 20MB block is 100MB of data up/down the wire (I'm vastly over-estimating, after optimization it should be 40MB) then you'll be paying...uhhh: 0.1 GB / block-data-on-wire * 144 blocks/day * 30.5 days/month * 0.13 $ / GB = $57 Less than $2 per day in bandwidth. For a single cross-border TCP connection, it would be certainly far slower than 12.5 MB/s. That's OK, you'll 1.3Mbps or less. I think we can accept 5MB block at most. Are you worried about paying too much, or do 20MB blocks feel like too much ? -- -- Gavin Andresen -- ___ 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
That orphan rate increase will go to whoever is producing the 20MB blocks, NOT you. This depends on how miners are connected. E.g. suppose there are three miners, A and B have fast connectivity between then, and C has a slow network. Suppose that A miners a block and B receives it in 1 second. C receives it in 6 seconds. This means that blocks mined by C during these ~5 seconds will be orphaned because B gets A's block first. -- ___ 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
On 31 May 2015, at 13:52, Gavin Andresen gavinandre...@gmail.com wrote: On Sat, May 30, 2015 at 9:31 PM, Chun Wang 1240...@gmail.com mailto:1240...@gmail.com wrote: 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. That orphan rate increase will go to whoever is producing the 20MB blocks, NOT you. There's an interesting incentives question if the mining fees ever become large enough to be interesting. Given two potential blocks on which to build then for the best interests of the system we'd want miners to select the block that confirmed the largest number of transactions since that puts less pressure on the network later. This is at odds with the incentives for our would-be block maker though because the incentive for mining would be to use whichever block left the largest potential fees available; that's generally going to be the smaller of the two. This, of course, only gets worse as the block reward reduces and fees become the dominant way for miners to be paid (and my hypothesis that eventually this could lead to miners trying to deliberately orphan earlier blocks to steal fees because the fixed block reward is no longer the dominant part of their income). When coupled with the block propagation delay problem increasing the risk of orphan races I'm pretty sure that this actually leads to miners having an incentive to continually mine smaller blocks, and that's aside from the question of whether smaller blocks will push up fees (which also benefits miners). Cheers, Dave -- ___ 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
Re: [Bitcoin-development] Block Size Increase Requirements
On Sun, May 31, 2015 at 10:46 AM, Jorge Timón jti...@jtimon.cc wrote: Here's a thought experiment: Subsidy is gone, all the block reward comes from fees. I wrote about long-term hypotheticals and why I think it is a big mistake to waste time worrying about them here: http://gavinandresen.ninja/when-the-block-reward-goes-away -- -- Gavin Andresen -- ___ 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
On Sun, May 31, 2015 at 9:45 AM, Alex Mizrahi alex.mizr...@gmail.com wrote: That orphan rate increase will go to whoever is producing the 20MB blocks, NOT you. This depends on how miners are connected. E.g. suppose there are three miners, A and B have fast connectivity between then, and C has a slow network. Suppose that A miners a block and B receives it in 1 second. C receives it in 6 seconds. This means that blocks mined by C during these ~5 seconds will be orphaned because B gets A's block first. Yes, if you are on a slow network then you are at a (slight) disadvantage. So? There are lots of equations that go into the is mining profitable equation: cost of power, Internet cost and connectivity, cost of capital, access to technology other miners don't have, inexpensive labor or rent, inexpensive cooling, ability to use waste heat... That's good. An equation with lots of variables has lots of different maximum solutions, and that means better decentralization -- there is less likely to be one perfect place or way to mine. -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
Whatever...let's use the current subsidies, the same argument applies, it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B. Miner B would still go out of business, bigger blocks still mean more mining and validation centralization. The question is how far I we willing to go with this scaling by sacrificing decentralization, but the answer can't be that's to far away in the future to worry about it, right now as far as we think we can using orphan rate as the only criterion. On May 31, 2015 4:49 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Sun, May 31, 2015 at 10:46 AM, Jorge Timón jti...@jtimon.cc wrote: Here's a thought experiment: Subsidy is gone, all the block reward comes from fees. I wrote about long-term hypotheticals and why I think it is a big mistake to waste time worrying about them here: http://gavinandresen.ninja/when-the-block-reward-goes-away -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
