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] Long-term mining incentives
I think proof-of-idle had a potentially serious problem when I last looked at it. The risk is that a largish miner can use everyone else's idle time to construct a very long chain; it's also easy enough for them to make it appear to be the work of a large number of distinct miners. Given that this would allow them to arbitrarily re-mine any block rewards and potentially censor any transactions then that just seems like a huge security hole? Cheers, Dave On 12 May 2015, at 17:10, Gavin Andresen gavinandre...@gmail.com wrote: Added back the list, I didn't mean to reply privately: Fair enough, I'll try to find time in the next month or three to write up four plausible future scenarios for how mining incentives might work: 1) Fee-supported with very large blocks containing lots of tiny-fee transactions 2) Proof-of-idle supported (I wish Tadge Dryja would publish his proof-of-idle idea) 3) Fees purely as transaction-spam-prevention measure, chain security via alternative consensus algorithm (in this scenario there is very little mining). 4) Fee supported with small blocks containing high-fee transactions moving coins to/from sidechains. Would that be helpful, or do you have some reason for thinking that we should pick just one and focus all of our efforts on making that one scenario happen? I always think it is better, when possible, not to bet on one horse. On Tue, May 12, 2015 at 10:39 AM, Thomas Voegtlin thom...@electrum.org mailto:thom...@electrum.org wrote: Le 12/05/2015 15:44, Gavin Andresen a écrit : Ok, here's my scenario: https://blog.bitcoinfoundation.org/a-scalability-roadmap/ https://blog.bitcoinfoundation.org/a-scalability-roadmap/ It might be wrong. I welcome other people to present their road maps. [answering to you only because you answered to me and not to the list; feel free to repost this to the list though] Yes, that's exactly the kind of roadmap I am asking for. But your blog post does not say anything about long term mining incentives, it only talks about scalability. My point is that we need the same kind of thing for miners incentives. -- -- Gavin Andresen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size
I proposed the same thing last year (there's a video of the presentation I was giving somewhere around). My intuition was that this would require slowly reducing the inter-block time, probably by step reductions at particular block heights. Having had almost a year to think about it some more there are a few subtleties: 1) I think it could discourage decentralisation if the nominal 2 week period per difficulty retarget is retained. If we reached 4032 blocks and a 5 minute block time then there would be 2x as many blocks at any given difficulty which increases the odds of a smaller pool finding a block and thus getting a reward. Block rewards would have to drop in proportion to the reduced interval to keep the total schedule of 21M coins on track though, but the reduction in variance is a win for smaller miners. 2) There are limits to the block time. The speed of light is an ultimately limiting factor here, but we would want to avoid excessive orphan rates. 3) There would be some amount of confusion about numbers of confirmations. I actually think that confirmation numbers are a really misleading idea anyway and it would be safer to think in terms of minutes of security. A zero conf transaction has zero minutes, while right now 1, 2, 3 and 6 would be ten minutes, twenty minutes, thirty minutes and sixty minutes respectively. If our block time were 5 minutes then 8 confirmations would be forty minutes of security; if the block time was 2.5 minutes then 8 confirmations would be twenty minutes of security. The minutes of security measure indicates the mean number of minutes of the entire network's hash rate would be required to undo a transaction. 4) Reducing the inter-block time reduces the variance in reaching that sixty minutes of security level. The variance around finding 6 blocks with a ten minute interval is much wider than the variance for finding 12 blocks with a 5 minute interval. On 11 May 2015, at 08:30, Thy Shizzle thyshiz...@outlook.com wrote: Yes This! So many people seem hung up on growing the block size! If gaining a higher tps throughput is the main aim, I think that this proposition to speed up block creation has merit! Yes it will lead to an increase in the block chain still due to 1mb ~1 minute instead of ~10 minute, but the change to the protocol is minor, you are only adding in a different difficulty rate starting from hight blah, no new features or anything are being added so there seems to me much less of a security risk! Also that impact if a hard fork should be minimal because there is nothing but absolute incentive for miners to mine at the new easier difficulty! I feel this deserves a great deal of consideration as opposed to blowing out the block through miners voting etc From: Sergio Lerner mailto:sergioler...@certimix.com Sent: 11/05/2015 5:05 PM To: bitcoin-development@lists.sourceforge.net mailto:bitcoin-development@lists.sourceforge.net Subject: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size In this e-mail I'll do my best to argue than if you accept that increasing the transactions/second is a good direction to go, then increasing the maximum block size is not the best way to do it. I argue that the right direction to go is to decrease the block rate to 1 minute, while keeping the block size limit to 1 Megabyte (or increasing it from a lower value such as 100 Kbyte and then have a step function). I'm backing up my claims with many hours of research simulating the Bitcoin network under different conditions [1]. I'll try to convince you by responding to each of the arguments I've heard against it. Arguments against reducing the block interval 1. It will encourage centralization, because participants of mining pools will loose more money because of excessive initial block template latency, which leads to higher stale shares When a new block is solved, that information needs to propagate throughout the Bitcoin network up to the mining pool operator nodes, then a new block header candidate is created, and this header must be propagated to all the mining pool users, ether by a push or a pull model. Generally the mining server pushes new work units to the individual miners. If done other way around, the server would need to handle a high load of continuous work requests that would be difficult to distinguish from a DDoS attack. So if the server pushes new block header candidates to clients, then the problem boils down to increasing bandwidth of the servers to achieve a tenfold increase in work distribution. Or distributing the servers geographically to achieve a lower latency. Propagating blocks does not require additional CPU resources, so mining pools administrators would need to increase moderately their investment in the server infrastructure to achieve lower latency and higher bandwidth, but I guess the investment would be
Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size
On 11 May 2015, at 12:10, insecurity@national.shitposting.agency wrote: On 2015-05-11 10:34, Peter Todd wrote: How do you see that blacklisting actually being done? Same way ghash.io was banned from the network when used Finney attacks against BetCoin Dice. As Andreas Antonopoulos says, if any of the miners do anything bad, we just ban them from mining. Any sort of attack like this only lasts 10 minutes as a result. Stop worrying so much. This doesn't work because a large-scale miner can trivially make themselves look like a very large number of much smaller scale miners. Their ability to minimize variance comes from the cumulative totals they control so 10 pools of 1% of the network cumulatively have the same variance as 1 pool with 10% of the network. It's also very easy for miners to relay blocks via different addresses and the cost is minimal. The biggest cost would be in DDoS prevention and a miner that actually split their pool into lots of small fragments would actually give themselves the ability to do quite a lot of DDoS mitigation anyway. If no-one is doing this right now it's simply because they've not had the right incentives to make it worthwhile; if the incentives make it worthwhile then this is pretty trivial to do. This is one area where anonymity on behalf of transaction validators and block makers essentially makes it pretty-much impossible to maintain any sort of sanctions against antisocial behaviour. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
On 7 May 2015, at 11:52, Jorge Timón jti...@jtimon.cc wrote: On Thu, May 7, 2015 at 11:25 AM, Mike Hearn m...@plan99.net wrote: I observed to Wladimir and Gavin in private that this timeline meant a change to the block size was unlikely to get into 0.11, leaving only 0.12, which would give everyone only a few months to upgrade in order to fork the chain by the end of the winter growth season. That seemed tight. Can you please elaborate on what terrible things will happen if we don't increase the block size by winter this year? I assume that you are expecting full blocks by then, have you used any statistical technique to come up with that date or is it just your guess? Because I love wild guesses and mine is that full 1 MB blocks will not happen until June 2017. I've been looking at this problem for quite a while (Gavin cited some of my work a few days ago) so thought I'd chime in with a few thoughts (some of which I've not published). I believe the major problem here is that this isn't just an engineering decision; the reaction of the miners will actually determine the success or failure of any course of action. In fact any decision forced upon them may backfire if they collectively take exception to it. It's worth bearing in mind that most of the hash rate is now under the control of relatively large companies, many of whom have investors who are expecting to see returns; it probably isn't sufficient to just expect them to do the right thing. We're seeing plenty of full 1M byte blocks already and have been for months. Typically whenever we have one of the large inter-block gaps then these are often followed by one (and sometimes several) completely full blocks (full by the definition of whatever the miner wanted to use as a size limit). The problem with this particular discussion is that there are quite a few knowns but an equally large number of unknowns. Let's look at them: Known: There has been a steady trend towards the mean block size getting larger. See https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address= https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address= Known: Now the trend was definitely increasing quite quickly last year but for the last few months has been slowing down, however we did see pretty much a 2x increase in mean block sizes in 2014. Known: For most of 2015 we've actually been seeing that rate slow quite dramatically, but the total numbers of transactions are still rising so we're seeing mean transaction sizes have been reducing, and that tallies with seeing more transactions per block: https://blockchain.info/charts/n-transactions-per-block?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address= https://blockchain.info/charts/n-transactions-per-block?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address= Unknown: Why are seeing more smaller transactions? Are we simply seeing more efficient use of blockchain resources or have some large consumers of block space going away? How much more block space compression might be possible in, say, the next 12 months? Known: If we reach the point where all blocks are 1M bytes then there's a major problem in terms of transaction confirmation. I published an analysis of the impact of different mean block sizes against confirmation times: http://hashingit.com/analysis/34-bitcoin-traffic-bulletin http://hashingit.com/analysis/34-bitcoin-traffic-bulletin. The current 35% to 45% mean block size doesn't have a huge impact on transaction confirmations (assuming equal fees for all) but once we're up at 80% then things start to get unpleasant. Instead of 50% of first confirmations taking about 7 minutes they instead take nearer to 19 minutes. Known: There are currently a reasonably large number of zero-fee transactions getting relayed and mined. If things start to slow down then there will be a huge incentive to delay them (or drop them altogether). Unknown: If block space starts to get more scarce then how will this affect the use of the blockchain? Do the zero-fee TXs move to some batched transfer solution via third party? Do people start to get smarter about how TXs are encoded? Do some TXs go away completely (there are a lot of long-chain transactions that may simply be noise creating an artificially inflated view of transaction volumes)? Known: There's a major problem looming for miners at the next block reward halving. Many are already in a bad place and without meaningful fees then sans a 2x increase in the USD:BTC ratio then many will simply have to leave the network, increasing centralisation risks. There seems to be a fairly pervasive assumption that the 300-ish MW of power that they currently use is going to pay for itself (ignoring capital and other operating
