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] 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] 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] 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
Re: [Bitcoin-development] Block Size Increase Requirements
On 05/29/15 23:48, Gavin Andresen wrote: On Fri, May 29, 2015 at 7:25 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: Sadly, this is very far from the whole story. The issue of miners optimizing for returns has been discussed several times during this discussion, and, sadly, miners who are geographically colocated who are optimizing for returns with a free-floating blocksize will optimize away 50% of the network! I must have missed that analysis-- link please? Or summary of HOW they will optimize away 50% of the network? Or are you assuming that 50% of the network is colocated... (which is a potential problem independent of blocksize) If, for example, the majority of miners are in China (they are), and there is really poor connectivity in and out of China (there is) and a miner naively optimizes for profit, they will create blocks which are large and take a while to relay out of China. By simple trial-and-error an individual large miner might notice that when they create larger blocks which fork off miners in other parts of the world, they get more income. Obviously forking off 50% of the network would be a rather extreme situation and assumes all kinds of simplified models, but it shows that the incentives here are very far from aligned, and your simplified good-behavior models are very far from convincing. In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for analysis of but that means bigger miners can get an advantage argument. Executive summary: if little miners are stupid and produce huge blocks, then yes, big miners have an advantage. I'll talk about transaction fees in a second, but there are several problems with this already. As pointed out in the original mail, gfw has already been known to interfere with Bitcoin P2P traffic. So now by little miners, you mean any miner who is not located in mainland China? Whats worse, the disadvantage is symmetric - little miners are at a disadvantage when *anyone* mines a bigger block, and miners dont even have to be evil for this to happen - just optimize for profits. But the disadvantage is tiny. And essentially zero if they connect to your fast relay network (or anything like it). The disadvantage is small with 1MB blocks, but already non-zero. 20MB blocks are much, much worse (lots of things here dont scale linearly, even just transfer over a high-packet-loss-link). I mentioned this in my original email as something which doesnt make me comfortable with 20MB blocks, but something which needs simulation and study, and might actually be just fine! But they're not, so they won't. I dont know what you're referring to with this. Are you claiming little miners today optimize for relay times and have good visibility into the Bitcoin network and calculate an optimal block size based on this (or would with a 20MB block size)? Do you have another explanation for why miners choose to leave fee-paying transactions in their mempool and create small blocks? Defaults? Dumb designs? Most miners just use the default 750K blocks, as far as I can tell, other miners probably didnt see transactions relayed across several hops or so, and a select few miners are doing crazy things like making their blocks fit in a single packet to cross the gfw, but that is probably overkill and not well-researched. Until the block reward goes away, and assuming transaction fees become an important source of revenue for miners. I think it is too early to worry about that; see: http://gavinandresen.ninja/when-the-block-reward-goes-away You dont make any points here with which I can argue, but let me respond with the reason /I/ think it is a problem worth thinking a little bit about...If we increase the blocksize sufficiently such that transaction fees are not the way in which miners make their money I'm not suggesting that we increase the blocksize sufficiently such that transaction fees are not the way in which miners make their money. I'm suggesting the blocksize be increased to 20MB (and then doubled every couple of years). Do you have convincing evidence that at 20MB miners will be able to break even on transaction fees for a long time? (The answer is no because no one has any idea how bitcoin transaction volumes are going to scale, period.) And in which miners make their money is the wrong metric-- we want enough mining so the network to be secure enough against double-spends. Sure, do you have a value of hashpower which is secure enough (which is a whole other rabbit hole to
Re: [Bitcoin-development] Block Size Increase Requirements
Stop trying to dictate block growth limits. Block size will be determined by competition between miners and availability of transactions, not through hard-coded limits. Do you even game theory, bro? It doesn't work that way. Mike Hearn described the problem in this article: https://medium.com/@octskyward/hashing-7d04a887acc8 But the solution he's proposing is ridiculously bad and unsound: he expects business owners to donate large sums of money towards mining. If it comes to this, what sane business owner will donate, say, 100 BTC to miners instead of seeking some alternatives? Proof-of-stake coins are already there. I'm well aware of theoretical issues with PoS security, but those theoretical issues aren't as bad as donation-funded cryptocurrency security. But you know what works? Mining fees + block size limit. Users and merchants are interested in their transactions being confirmed, but block size limit won't allow it to turn into a race to bottom. This is actually game-theoretically sound. I see now the temporary 1MB limit was a mistake. It should have gone in as a dynamic limit that scales with average block size. This means that miners will control it, and miners couldn't care less about things like decentralization and about problems of ordinary users. This means that in this scenario Bitcoin will be 100% controlled by few huge-ass mining operations. Possibly a single operation. We already saw GHASH.IO using 51% of total hashpower. Is that what you want? Miners are NOT benevolent. This was already demonstrated. They are greedy. -- ___ 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 Fri, May 29, 2015 at 7:42 PM, Chun Wang 1240...@gmail.com wrote: Hello. I am from F2Pool. We are currently mining the biggest blocks on the network. Thanks for giving your opinion! 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). We think the max block size should be increased, but must be increased smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB, and so on. Thanks. Why 2 MB ? You said that server bandwidth is much more expensive in China; what would be the difference in your bandwidth costs between 2MB blocks and 20MB blocks? -- -- 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
Matt brought this up on Twitter, I have no idea why I didn't respond weeks ago (busy writing blog posts, probably): On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. If block propagation isn't fixed, then mines have a strong incentive to create smaller blocks. So the max block size is irrelevant, it won't get hit. In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for analysis of but that means bigger miners can get an advantage argument. Executive summary: if little miners are stupid and produce huge blocks, then yes, big miners have an advantage. But they're not, so they won't. Until the block reward goes away, and assuming transaction fees become an important source of revenue for miners. I think it is too early to worry about that; see: http://gavinandresen.ninja/when-the-block-reward-goes-away * I'd very much like to see someone working on better scaling technology, both in terms of development and in terms of getting traction in the marketplace. Ok. What does this have to do with the max block size? Are you arguing that work won't happen if the max block size increases? * I'd like to see some better conclusions to the discussion around long-term incentives within the system. Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away for what I think about that. -- -- 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 05/29/15 22:36, Gavin Andresen wrote: Matt brought this up on Twitter, I have no idea why I didn't respond weeks ago (busy writing blog posts, probably): On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. If block propagation isn't fixed, then mines have a strong incentive to create smaller blocks. So the max block size is irrelevant, it won't get hit. Sadly, this is very far from the whole story. The issue of miners optimizing for returns has been discussed several times during this discussion, and, sadly, miners who are geographically colocated who are optimizing for returns with a free-floating blocksize will optimize away 50% of the network! In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for analysis of but that means bigger miners can get an advantage argument. Executive summary: if little miners are stupid and produce huge blocks, then yes, big miners have an advantage. I'll talk about transaction fees in a second, but there are several problems with this already. As pointed out in the original mail, gfw has already been known to interfere with Bitcoin P2P traffic. So now by little miners, you mean any miner who is not located in mainland China? Whats worse, the disadvantage is symmetric - little miners are at a disadvantage when *anyone* mines a bigger block, and miners dont even have to be evil for this to happen - just optimize for profits. But they're not, so they won't. I dont know what you're referring to with this. Are you claiming little miners today optimize for relay times and have good visibility into the Bitcoin network and calculate an optimal block size based on this (or would with a 20MB block size)? Until the block reward goes away, and assuming transaction fees become an important source of revenue for miners. I think it is too early to worry about that; see: http://gavinandresen.ninja/when-the-block-reward-goes-away You dont make any points here with which I can argue, but let me respond with the reason /I/ think it is a problem worth thinking a little bit about...If we increase the blocksize sufficiently such that transaction fees are not the way in which miners make their money, then either miners are not being funded (ie hashpower has to drop to very little), or the only people mining/funding miners are large orgs who are running Bitcoin (ie the web wallets, payment processors, big merchants, and exchanges of the world). Sadly, this is no longer a decentralized Bitcoin and is, in fact, pretty much how the banking world works today. I'm not sure who, if anyone, claims Bitcoin is novel or interesting for any reason other than its decentralization properties, and, in a world which you are apparently proposing, the natural course of things is to very strongly centralize. * I'd very much like to see someone working on better scaling technology, both in terms of development and in terms of getting traction in the marketplace. Ok. What does this have to do with the max block size? Are you arguing that work won't happen if the max block size increases? Yes, I am arguing that by increasing the blocksize the incentives to actually make Bitcoin scale go away. Even if amazing technologies get built, no one will have any reason to use them. * I'd like to see some better conclusions to the discussion around long-term incentives within the system. Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away for what I think about that. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
Hello. I am from F2Pool. We are currently mining the biggest blocks on the network. So far top 100 biggest bitcoin blocks are all from us. We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. I know most blocks would not be 20 MB over night. But only if a small fraction of blocks more than 10 MB, it could dramatically increase of our orphan rate, result of higher fee to miners. Bad miners could attack us and the network with artificial big blocks. As yhou know, other Chinese pools, AntPool, BW, they produces ASIC chips and mining mostly with their own machines. They do not care about a few percent of orphan increase as much as we do. They would continue their zero fee policy. We would be the biggest loser. As the exchanges had taught us, zero fee is not health to the network. Also we have to redevelop our block broadcast logic. Server bandwidth is a lot more expensive in China. And the Internet is slow. Currently China has more than 50% of mining power, if block size increases, I bet European and American pools could suffer more than us. We think the max block size should be increased, but must be increased smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB, and so on. Thanks. On Fri, May 8, 2015 at 6:02 AM, Matt Corallo bitcoin-l...@bluematt.me wrote: OK, so lets do that. I've seen a lot of I'm not entirely comfortable with committing to this right now, but think we should eventually, but not much I'd be comfortable with committing to this when I see X. In the interest of ignoring debate and pushing people towards a consensus at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the second. Personally, there are several things that worry me significantly about committing to a blocksize increase, which I'd like to see resolved before I'd consider supporting a blocksize increase commitment. * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. I'd expect to see these not only implemented but being used in production (though I dont particularly care about them being all that stable). I'd want to see measurements of how they perform both in production and in the face of high packet loss (eg across the GFW or in the case of small/moderate DoS). In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. * I'd very much like to see someone working on better scaling technology, both in terms of development and in terms of getting traction in the marketplace. I know StrawPay is working on development, though its not obvious to me how far they are from their website, but I dont know of any commitments by large players (either SPV wallets, centralized wallet services, payment processors, or any others) to support such a system (to be fair, its probably too early for such players to commit to anything, since anything doesnt exist in public). * I'd like to see some better conclusions to the discussion around long-term incentives within the system. If we're just building Bitcoin to work in five years, great, but if we want it all to keep working as subsidy drops significantly, I'd like a better answer than we'll deal with it when we get there or it will happen, all the predictions based on people's behavior today say so (which are hopefully invalid thanks to the previous point). Ideally, I'd love to see some real free pressure already on the network starting to develop when we commit to hardforking in a year. Not just full blocks with some fees because wallets are including far greater fees than they really need to, but software which properly handles fees across the ecosystem, smart fee increases when transactions arent confirming (eg replace-by-fee, which could be limited to increase-in-fees-only for those worried about double-spends). I probably forgot one or two and certainly dont want to back myself into a corner on committing to something here, but those are a few things I see today as big blockers on larger blocks. Luckily, people have been making progress on building the software needed in all of the above for a while now, but I think they're all very, very immature today. On 05/07/15 19:13, Jeff Garzik wrote: On Thu, May 7, 2015 at 3:03 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: -snip- If, instead, there had been an intro on the list as I think we should do the blocksize increase soon, what do people think?, the response could likely have focused much more around creating a specific list of things we should do before we (the technical community) think we are prepared for a blocksize increase. Agreed, but that is water under the bridge at this point. You - rightly - opened the topic here and now we're discussing it.
Re: [Bitcoin-development] Block Size Increase Requirements
On Sat, May 9, 2015 at 4:08 AM, Peter Todd p...@petertodd.org wrote: I wonder if having a miner flag would be good for the network. Makes it trivial to find miners and DoS attack them - a huge risk to the network as a whole, as well as the miners. To mitigate against this, two chaintips could be tracked. The miner tip and the client tip. Miners would build on the miner tip. When performing client services, like wallets, they would use the client tip. The client would act exactly the same as any node, the only change would be that it gives miner work based on the mining tip. If the two tips end up significantly forking, there would be a warning to the miner and perhaps eventually refuse to give out new work. That would happen when there was a miner level hard-fork. That'd be an excellent way to double-spend merchants, significantly increasing the chance that the double-spend would succeed as you only have to get sufficient hashing power to get the lucky blocks; you don't need enough hashing power to *also* ensure those blocks don't become the longest chain, removing the need to sybil attack your target. To launch that attack, you need to produce fake blocks. That is expensive. Stephen Cale's suggestion to wait more than one block before counting a transaction as confirmed would also help mitigate. -- 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 Requirements
On Sat, May 16, 2015 at 5:39 AM, Stephen stephencalebmo...@gmail.com wrote: I think this could be mitigated by counting confirmations differently. We should think of confirmations as only coming from blocks following the miners' more strict rule set. So if a merchant were to see payment for the first time in a block that met their own size restrictions but not the miners', then they would simply count it as unconfirmed. In effect, there is a confirm penalty for less strict blocks. Confirms = max(miner_confirms, merchant_confirms - 3, 0) Merchants who don't upgrade end up having to wait longer to hit confirmations. If they get deep enough in the chain, though, the client should probably count them as being confirmed anyway, even if they don't meet the client nodes' expectation of the miners' block size limit. This happening probably just means that the client has not updated their software (or -minermaxblocksize configuration, depending on how it is implemented) in a long time. That is a good idea. Any parameters that have miner/merchant differences should be modifiable (but only upwards) in the command line. Why are my transactions taking longer to confirm? There was a soft fork to make the block size larger and your client is being careful. You need to add minermaxblocksize=4MB to your bitcoin.conf file. Hah, it could be called a semi-hard fork? -- 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 Requirements
Comments in line: On May 8, 2015, at 11:08 PM, Peter Todd p...@petertodd.org wrote: Makes it trivial to find miners and DoS attack them - a huge risk to the network as a whole, as well as the miners. Right now pools already get DoSed all the time through their work submission systems; getting DoS attacked via their nodes as well would be a disaster. It seems that using a -miner flag to follow rules about smaller blocks would only reveal miner nodes if one sent the node a solved block that that was valid in every way except the block size. While not impossible, I wouldn't call this trivial, as it still requires wasting an entire block's worth of energy. When in miner mode, the client would reject 4MB blocks and wouldn't build on them. The reference client might even track the miner and the non-miner chain tip. Miners would refuse to build on 5MB blocks, but merchants and general users would accept them. That'd be an excellent way to double-spend merchants, significantly increasing the chance that the double-spend would succeed as you only have to get sufficient hashing power to get the lucky blocks; you don't need enough hashing power to *also* ensure those blocks don't become the longest chain, removing the need to sybil attack your target. I think this could be mitigated by counting confirmations differently. We should think of confirmations as only coming from blocks following the miners' more strict rule set. So if a merchant were to see payment for the first time in a block that met their own size restrictions but not the miners', then they would simply count it as unconfirmed. If they get deep enough in the chain, though, the client should probably count them as being confirmed anyway, even if they don't meet the client nodes' expectation of the miners' block size limit. This happening probably just means that the client has not updated their software (or -minermaxblocksize configuration, depending on how it is implemented) in a long time. I actually like Tier's suggestion quite a bit. I think we could have the default client limit set to some higher number, and have miners agree out of band on the latest block size limit. Or maybe even build in a way to vote into the blockchain. Best, Stephen -- 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 Requirements
--[remove this line and above]-- On Thu, 7 May 2015, Gregory Maxwell wrote: Date: Thu, 7 May 2015 00:37:54 + From: Gregory Maxwell gmaxw...@gmail.com To: Matt Corallo bitcoin-l...@bluematt.me Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Block Size Increase Thanks Matt; I was actually really confused by this sudden push with not a word here or on Github--so much so that I responded on Reddit to people pointing to commits in Gavin's personal repository saying they were reading too much into it. I saw this. I was also pointing this out to the people who were asking me. A commit to a personal repository does not at first seem more than experimental. sipa commits weird/neat things to private branches all the time, after all. to share behavior. In the case of mining, we're trying to optimize the social good of POW security. (But the analogy applies in other ways too: About the only argument IMO in favour of block size increases is to assume that making more room in a block will make it attractive to use for more people at some point in the future: increasing transaction velocity, increasing economy size, increasing value overall. increases to the chain side are largely an externality; miners enjoy the benefits, everyone else takes the costs--either in reduced security or higher node operating else.) Who else but miners and pool operators will run full nodes when full nodes are being shut down because they are too large and unwieldy to maintain? It is already so that casual users refuse to run full nodes. This fact is indisputable. The only question remaining is, Do we care? Arguments against users who feel that the dataset is too large to run a full node, full-time, start from a premise that these users are a static and irrelevant fraction. Is this even true? Do we care? I do. I will shortly only be able to run half the nodes I currently do thanks to the growth of the blockchain at its current rate. One potential argument is that maybe miners would be _regulated_ to behave correctly. But this would require undermining the openness of the system--where anyone can mine anonymously--in order to enforce behavior, and that same enforcement mechanism would leave a political level to impose additional rules that violate the extra properties of the system. I would refuse to mine under such a regulated regime; moreover, I would enjoy forking away from this, and, I suspect, the only miners who remain would be those whose ultimate motivations do not coincide with the users. That is, the set of miners who are users, and the set of users who are miners, would be wholly non-intersecting. So far the mining ecosystem has become incredibly centralized over time. This is unfortunate but true. of the regular contributors to Bitcoin Core do. Many participants have never mined or only did back in 2010/2011... we've basically ignored the mining ecosystem, and this has had devastating effects, causing a latent undermining of the security model: hacking a dozen or so computers--operated under totally unknown and probably not strong security policies--could compromise the network at least at the tip... The explicit form of the block dictated by the reference client and agreed-to by the people who were sold on bitcoin near the beginning (myself included) was explicitly the notion that the rules were static; that the nature of transaction foundations and the subsidies would not be altered. Here we have a hardfork being contemplated which is not only controversial, but does not even address some of the highest-utility and most-requested features in peoples' hardfork wishlists. The fact that mining has effectively been centralized directly implies that destabilizing changes that some well-heeled (and thus theoretically capable, at least) people have explicitly begun plans to fork the blockchain about will have an unknown, and completely unforeseen combined effect. We can pretend that, If merchants and miners and exchanges go along, then who else matters, but the reality is that the value in bitcoin exists because *people* use it for real transactions: Not miners, whose profits are parasitically fractionally based on the quality and strength of the bitcoin economy as a whole; not exchanges who lubricate transactions in service to the economy; not even today's merchants whose primary means of accepting bitcoin seems to be to convert them instantly to fiat and not participate meaningfully in the economy at all; not enriched felons; but actual users themselves. Rightfully we should be regarding this an an emergency, and probably should have been have since 2011. There are two ways to look at it, assuming that the blocksize change increases bitcoin's value to people after all: mining centralization will be corrected; or, mining centralization will not be corrected. I would argue that rapidly increasing
Re: [Bitcoin-development] Block Size Increase Requirements
* Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. With a 20mb cap, miners still have the option of the soft limit. I would actually be quite surprised if there were no point along the road from 1mb to 20mb where miners felt a need to throttle their block sizes artificially, for the exact reason you point out: propagation delays. But we don't *need* to have fancy protocol upgrades implemented right now. All we need is to demolish one bottleneck (the hard cap) so we can then move on and demolish the next one (whatever that is, probably faster propagation). Scaling is a series of walls we punch through as we encounter them. One down, onto the next. We don't have to tackle them all simultaneously. FWIW I don't think the GFW just triggers packet loss, these days. It's blocked port 8333 entirely. * I'd very much like to see someone working on better scaling technology ... I know StrawPay is working on development, So this request is already satisfied, isn't it? As you point out, expecting more at this stage in development is unreasonable, there's nothing for anyone to experiment with or commit to. They have code here, by the way: https://github.com/strawpay You can find their fork of MultiBit HD, their implementation library, etc. They've contributed patches and improvements to the payment channels code we wrote. * I'd like to see some better conclusions to the discussion around long-term incentives within the system. What are your thoughts on using assurance contracts to fund network security? I don't *know* if hashing assurance contracts (HACs) will work. But I don't know they won't work either. And right now I'm pretty sure that plain old fee pressure won't work. Demand doesn't outstrip supply forever - people find substitutes. -- 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 Requirements
On Fri, May 08, 2015 at 12:03:04PM +0200, Mike Hearn wrote: * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. With a 20mb cap, miners still have the option of the soft limit. The soft-limit is there miners themselves produce smaller blocks; the soft-limit does not prevent other miners from producing larger blocks. As we're talking about ways that other miners can use 20MB blocks to harm the competition, talking about the soft-limit is irrelevant. Similarly, as security engineers we must plan for the worst case; as we've seen before by your campaigns to raise the soft-limit(1) even at a time when the vast majority of transaction volume was from one user (SatoshiDice) soft-limits are an extremely weak form of control. For the proposes of discussing blocksize increase requirements we can stop talking about the soft-limit. 1) https://bitcointalk.org/index.php?topic=149668.0 -- 'peter'[:-1]@petertodd.org 09344ba165781ee352f93d657c8b098c8e518e6011753e59 signature.asc Description: Digital signature -- 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 Requirements
On Fri, May 8, 2015 at 5:37 PM, Peter Todd p...@petertodd.org wrote: The soft-limit is there miners themselves produce smaller blocks; the soft-limit does not prevent other miners from producing larger blocks. I wonder if having a miner flag would be good for the network. Clients for general users and merchants would have a less strict rule than the rule for miners. Miners who don't set their miners flag might get orphaned off the chain. For example, the limits could be setup as follows. Clients: 20MB Miners: 4MB When in miner mode, the client would reject 4MB blocks and wouldn't build on them. The reference client might even track the miner and the non-miner chain tip. Miners would refuse to build on 5MB blocks, but merchants and general users would accept them. This allows the miners to soft fork the limit at some point in the future. If 75% of miners decided to up the limit to 8MB, then all merchants and the general users would accept the new blocks. It could follow the standard soft fork rules. This is a more general version of the system where miners are allowed to vote on the block size (subject to a higher limit). A similar system is where clients track all header trees. Your wallet could warn you that there is an invalid tree that has 75% of the hashing power and you might want to upgrade. -- 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 Requirements
On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote: On Fri, May 8, 2015 at 5:37 PM, Peter Todd p...@petertodd.org wrote: The soft-limit is there miners themselves produce smaller blocks; the soft-limit does not prevent other miners from producing larger blocks. I wonder if having a miner flag would be good for the network. Makes it trivial to find miners and DoS attack them - a huge risk to the network as a whole, as well as the miners. Right now pools already get DoSed all the time through their work submission systems; getting DoS attacked via their nodes as well would be a disaster. When in miner mode, the client would reject 4MB blocks and wouldn't build on them. The reference client might even track the miner and the non-miner chain tip. Miners would refuse to build on 5MB blocks, but merchants and general users would accept them. That'd be an excellent way to double-spend merchants, significantly increasing the chance that the double-spend would succeed as you only have to get sufficient hashing power to get the lucky blocks; you don't need enough hashing power to *also* ensure those blocks don't become the longest chain, removing the need to sybil attack your target. -- 'peter'[:-1]@petertodd.org 04bd67400df7577a30e6f509b6bd82633efeabe6395eb65a signature.asc Description: Digital signature -- 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 Requirements
Hi Matt, I agree that starting discussion on how to approach this problem is necessary and it's difficult taking positions without details on what is being discussed. A simple hard 20-megabyte increase will likely create perverse incentives, perhaps a method can exist with some safe transition. I think ultimately, the underlying tension with this discussion is about the relative power of miners. Any transition of blocksize increase will increase the influence of miners, and it is about understanding the tradeoffs for each possible approach. On Thu, May 07, 2015 at 10:02:09PM +, Matt Corallo wrote: * I'd like to see some better conclusions to the discussion around long-term incentives within the system. If we're just building Bitcoin to work in five years, great, but if we want it all to keep working as subsidy drops significantly, I'd like a better answer than we'll deal with it when we get there or it will happen, all the predictions based on people's behavior today say so (which are hopefully invalid thanks to the previous point). Ideally, I'd love to see some real free pressure already on the network starting to develop when we commit to hardforking in a year. Not just full blocks with some fees because wallets are including far greater fees than they really need to, but software which properly handles fees across the ecosystem, smart fee increases when transactions arent confirming (eg replace-by-fee, which could be limited to increase-in-fees-only for those worried about double-spends). I think the long-term fee incentive structure needs to be significantly more granular. We've all seen miners and pools take the path of least resistance; often they just do whatever the community tells them to blindly. While this status quo can change in the future, I think designing sane defaults is a good path for any possible transition. It seems especially reasonable to maintain fee pressure for normal transactions during a hard-fork transition. It's possible to do so using some kind of soft-cap structure. Building in a default soft-cap of 1 megabyte for some far future scheduled fork would seem like a sane thing to do for bitcoin-core. It seems also viable to be far more aggressive. What's your (and the community's) opinion on some kind of coinbase voting protocol for soft-cap enforcement? It's possible to write in messages to the coinbase for a enforcible soft-cap that orphans out any transaction which violates these rules. It seems safest to have the transition has the first hardforked block be above 1MB, however, the next block default to an enforced 1MB block. If miners agree to go above this, they must vote in their coinbase to do so. There's a separate discussion about this starting on: cae-z3oxnjayluehbu0hdwu5pkrj6fpj7yptgbmq7hkxg3sj...@mail.gmail.com I think defaulting some kind of mechanism on reading the coinbase seems to be a good idea, I think left alone, miners may not do so. That way, it's possible to have your cake and eat it too, fee pressure will still exist, while block sizes can increase (provided it's in the miners' greater interests to do so). The Lightning Network's security model in the long-term may rely on a multi-tier soft-cap, but I'm not sure. If 2nd order systemic miner incentives were not a concern, a system which has an enforced soft-cap and permits breaching that soft-cap with some agreed upon much higher fee would work best. LN works without this, but it seems to be more secure if some kind of miner consensus rule is reached regarding prioritizing behavior of 2nd-layer consensus states. No matter how it's done, certain aspects of the security model of something like Lightning is reliant upon having block-space availability for transactions to enter into the blockchain in a timely manner (since deprecated channel states become valid again after some agreed upon block-time). I think pretty much everyone agrees that the 1MB block cap will eventually be a problem. While people may disagree with when that will be and how it'll play out, I think we're all in agreement that discussion about it is a good idea, especially when it comes to resolving blocking concerns. Starting a discussion on how a hypothetical blocksize increase will occur and the necessary blocking/want-to-have features/tradeoffs seems to be a great way to approach this problem. The needs for Lightning Network may be best optimized by being able to prioritizing a large mass of timeout transactions at once (when a well-connected node stops communicating). -- Joseph Poon -- 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
Re: [Bitcoin-development] Block Size Increase Requirements
On Thu, May 07, 2015 at 10:02:09PM +, Matt Corallo wrote: OK, so lets do that. I've seen a lot of I'm not entirely comfortable with committing to this right now, but think we should eventually, but not much I'd be comfortable with committing to this when I see X. In the interest of ignoring debate and pushing people towards a consensus at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the second. Personally, there are several things that worry me significantly about committing to a blocksize increase, which I'd like to see resolved before I'd consider supporting a blocksize increase commitment. * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. I'd expect to see these not only implemented but being used in production (though I dont particularly care about them being all that stable). I'd want to see measurements of how they perform both in production and in the face of high packet loss (eg across the GFW or in the case of small/moderate DoS). In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. It's really important that we remember that we're building security software: it *must* hold up well even in the face of attack. That means we need to figure out how it can be attacked, what the cost/profits of such attacks are, and if the holes can be patched. Just testing the software with simulated loads is insufficient. Also, re: breaking, don't forget that this may not be a malicious act. For instance, someone can send contradictory transactions to different parts of the network simultaneously to prevent mempool consistency - there's no easy way to fix this. There are also cases where miners have different policy than others, e.g. version disagreements, commercial contracts for tx mining, etc. Finally, remember that it's not in miners' incentives in many situations for their blocks to propagate to more than ~30% of the hashing power.(1) Personally, I'm really skeptical that we'll ever find a block propagation latency reduction technique that sucesfully meets all the above criteria without changing the consensus algorithm itself. * How do we ensure miners don't cheat and stop validating blocks fully before building on them? This is a significant moral hazard with larger blocks if fees don't become significant, and can lead to dangerous forks. Also, think of the incentives: Why would a miner ever switch from the longest chain, even if they don't actually have the blocks to back it up? * We need a clear understanding of how we expect new full nodes, pruned or not, to sync up to the blockchain. Obviously 20MB blocks significantly increases the time and data required to sync. Are we planning on simply giving up on full validation and trusting others for copies of UTXO sets? Are we going to rely on UTXO commitments? What happens if the UTXO set size itself increases greatly? * I'd very much like to see someone working on better scaling technology, both in terms of development and in terms of getting traction in the marketplace. I know StrawPay is working on development, though its not obvious to me how far they are from their website, but I dont know of any commitments by large players (either SPV wallets, centralized wallet services, payment processors, or any others) to support such a system (to be fair, its probably too early for such players to commit to anything, since anything doesnt exist in public). A good start would be for those players to commit to the general principles of these systems; if they can't commit explain why. For instance I'd be very interested in knowing if services like Coinbase see legal issues with adopting technologies such as payment channels between hosted wallet providers, payment processors, etc. I certainly wouldn't be surprised if they see doing anythign not on-blockchain as a source of legal uncertainty - based on discussions I've had with regulatory types in this space it sounds like there's a reasonable chance protocol details such as requiring that transactions happen on a public blockchain will be baked into regulatory requirements. * I'd like to see some better conclusions to the discussion around long-term incentives within the system. If we're just building Bitcoin to work in five years, great, but if we want it all to keep working as subsidy drops significantly, I'd like a better answer than we'll deal with it when we get there or it will happen, all the predictions based on people's behavior today say so (which are hopefully invalid thanks to the previous point). Ideally, I'd love to see some real free pressure already on the network starting to develop when we commit to hardforking in a year. Agreed. Not just full blocks with some fees because wallets are including far greater fees
[Bitcoin-development] Block Size Increase Requirements
OK, so lets do that. I've seen a lot of I'm not entirely comfortable with committing to this right now, but think we should eventually, but not much I'd be comfortable with committing to this when I see X. In the interest of ignoring debate and pushing people towards a consensus at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the second. Personally, there are several things that worry me significantly about committing to a blocksize increase, which I'd like to see resolved before I'd consider supporting a blocksize increase commitment. * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. I'd expect to see these not only implemented but being used in production (though I dont particularly care about them being all that stable). I'd want to see measurements of how they perform both in production and in the face of high packet loss (eg across the GFW or in the case of small/moderate DoS). In addition, I'd expect to see analysis of how these systems perform in the worst-case, not just packet-loss-wise, but in the face of miners attempting to break the system. * I'd very much like to see someone working on better scaling technology, both in terms of development and in terms of getting traction in the marketplace. I know StrawPay is working on development, though its not obvious to me how far they are from their website, but I dont know of any commitments by large players (either SPV wallets, centralized wallet services, payment processors, or any others) to support such a system (to be fair, its probably too early for such players to commit to anything, since anything doesnt exist in public). * I'd like to see some better conclusions to the discussion around long-term incentives within the system. If we're just building Bitcoin to work in five years, great, but if we want it all to keep working as subsidy drops significantly, I'd like a better answer than we'll deal with it when we get there or it will happen, all the predictions based on people's behavior today say so (which are hopefully invalid thanks to the previous point). Ideally, I'd love to see some real free pressure already on the network starting to develop when we commit to hardforking in a year. Not just full blocks with some fees because wallets are including far greater fees than they really need to, but software which properly handles fees across the ecosystem, smart fee increases when transactions arent confirming (eg replace-by-fee, which could be limited to increase-in-fees-only for those worried about double-spends). I probably forgot one or two and certainly dont want to back myself into a corner on committing to something here, but those are a few things I see today as big blockers on larger blocks. Luckily, people have been making progress on building the software needed in all of the above for a while now, but I think they're all very, very immature today. On 05/07/15 19:13, Jeff Garzik wrote: On Thu, May 7, 2015 at 3:03 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: -snip- If, instead, there had been an intro on the list as I think we should do the blocksize increase soon, what do people think?, the response could likely have focused much more around creating a specific list of things we should do before we (the technical community) think we are prepared for a blocksize increase. Agreed, but that is water under the bridge at this point. You - rightly - opened the topic here and now we're discussing it. Mike and Gavin are due the benefit of doubt because making a change to a leaderless automaton powered by leaderless open source software is breaking new ground. I don't focus so much on how we got to this point, but rather, where we go from here. -- 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
