[Bitcoin-development] Block Size Increase
Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Block size is a question to which there is no answer, but which certainly has a LOT of technical tradeoffs to consider. I know a lot of people here have varying levels of strong or very strong opinions about this, and the fact that it is not being discussed in a technical community publicly anywhere is rather disappointing. So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase. Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler). This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo[1]. Matt [1] https://twitter.com/coinbase/status/595741967759335426 -- 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] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Wed, May 6, 2015 at 8:37 AM, Jorge Timón jti...@jtimon.cc wrote: This gives you less flexibility and I don't think it's necessary. Please let's try to avoid this if it's possible. It is just a switch that turns on and off the new mode. In retrospect, it would be better to just up the transaction version. In transactions from v2 onwards, the sequence field means height. That means legacy transactions would be spendable. This is a pure soft-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
On Wed, May 6, 2015 at 11:12 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: Personally, I'm rather strongly against any commitment to a block size increase in the near future. Miners can already soft-fork to reduce the maximum block size. If 51% of miners agree to a 250kB block size, then that is the maximum block size. The question being discussed is what is the maximum block size merchants and users will accept. This puts a reasonable limit on the maximum size miners can increase the block size to. In effect, the block size is set by the minimum of the miner's and the merchants/user's size.min(miner, merchants/users). This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo[1]. Would you accept a rule that the maximum size is 20MB (doubling every 2 years), but that miners have an efficient method for choosing a lower size? If miners could specify the maximum block size in their block headers, then they could coordinate to adjust the block size. If 75% vote to lower the size, then it is lowered and vice versa for raiding. Every 2016 blocks, the votes are counter. If the 504th lowest of the 2016 blocks is higher than the previous size, then the size is set to that size. Similarly, if the 504th highest is lower than the previous size, it becomes the new size. There could be 2 default trajectories. The reference client might always vote to double the size every 4 years. To handle large blocks (32MB) requires a change to the p2p protocol message size limits, or a way to split blocks over multiple messages. It would be nice to add new features to any hard-fork. I favour adding an auxiliary header. The Merkle root in the header could be replaced with hash(merkle_root | hash(aux_header)). This is a fairly simple change, but helps with things like commitments. One of the fields in the auxiliary header could be an extra nonce field. This would mean fast regeneration of the merkle root for ASIC miners. This is a pretty simple change. -- 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
For now, lets leave the discussion to JUST the block size increase. If it helps - everyone should assume that their pet feature is included in a hard fork or, if you prefer, that no other features are included in a hard fork. On 05/06/15 23:11, Matt Whitlock wrote: I'm not so much opposed to a block size increase as I am opposed to a hard fork. My problem with a hard fork is that everyone and their brother wants to seize the opportunity of a hard fork to insert their own pet feature, and such a mad rush of lightly considered, obscure feature additions would be extremely risky for Bitcoin. If it could be guaranteed that raising the block size limit would be the only incompatible change introduced in the hard fork, then I would support it, but I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences. -- 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
Replies inline. On 05/06/15 22:44, Tier Nolan wrote: On Wed, May 6, 2015 at 11:12 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: Personally, I'm rather strongly against any commitment to a block size increase in the near future. -snip- The question being discussed is what is the maximum block size merchants and users will accept. This puts a reasonable limit on the maximum size miners can increase the block size to. In effect, the block size is set by the minimum of the miner's and the merchants/user's size.min(miner, merchants/users). Indeed, the bitcoin community of users and miners can decide to do whatever they want, but this is univeral - they could decide whatever they want if they want to hardfork. That said, we should be having a rigorous technical discussion about whether it is sane to recommend a given course of action by releasing software which makes it happen. This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo[1]. Would you accept a rule that the maximum size is 20MB (doubling every 2 years), but that miners have an efficient method for choosing a lower size? If miners could specify the maximum block size in their block headers, then they could coordinate to adjust the block size. If 75% vote to lower the size, then it is lowered and vice versa for raiding. Every 2016 blocks, the votes are counter. If the 504th lowest of the 2016 blocks is higher than the previous size, then the size is set to that size. Similarly, if the 504th highest is lower than the previous size, it becomes the new size. There could be 2 default trajectories. The reference client might always vote to double the size every 4 years. To handle large blocks (32MB) requires a change to the p2p protocol message size limits, or a way to split blocks over multiple messages. It would be nice to add new features to any hard-fork. I favour adding an auxiliary header. The Merkle root in the header could be replaced with hash(merkle_root | hash(aux_header)). This is a fairly simple change, but helps with things like commitments. One of the fields in the auxiliary header could be an extra nonce field. This would mean fast regeneration of the merkle root for ASIC miners. This is a pretty simple change. The point of the hard block size limit is exactly because giving miners free rule to do anything they like with their blocks would allow them to do any number of crazy attacks. The incentives for miners to pick block sizes are no where near compatible with what allows the network to continue to run in a decentralized manner. -- 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 Wed, May 6, 2015 at 5:12 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Well, there has been significant public discussion in #bitcoin-wizards on irc.freenode.net which is available in public logs, specifically about why increasing the max block size is kicking the can down the road while possibly compromising blockchain security. There were many excellent objections that were raised that, sadly, I see are not referenced at all in the recent media blitz. Frankly I can't help but feel that if contributions, like those from #bitcoin-wizards, have been ignored in lieu of technical analysis, and the absence of discussion on this mailing list, that I feel perhaps there are other subtle and extremely important technical details that are completely absent from this--and other-- proposals. I have some rather general thoughts to offer. Secured decentralization is the most important and most interesting property of bitcoin. Everything else is rather trivial and could be achieved millions of times more efficiently with conventional technology. Our technical work should be informed by the technical nature of the system we have constructed. I suspect that as bitcoin continues to grow in all dimensions and metrics, that we will see an unending wave of those who are excited by the idea of Something Different in the face of archaic, crumbling software and procedures in the rest of the financial world. Money has found its way into every aspect of human life. There's no doubt in my mind that bitcoin will always see the most extreme campaigns and the most extreme misunderstandings. Like moths to a flame or water in the desert, almost everyone is excited by ANY status quo change whatsoever. This is something that we have to be vigilante about, because their excitement is motivation to do excellent work, not simply any work. For some who are excited about general status quo changes that bitcoin represents, they may not mind if bitcoin decentralization disappears and is replaced with just a handful of centralized nodes. Whereas for development purposes we must hold ourselves to extremely high standards before proposing changes, especially to the public, that have the potential to be unsafe and economically unsafe. We have examples from NASA about how to engineer extremely fault tolerant systems, and we have examples from Linux about how to have high standards in open-source projects. Safety is absolutely critical, even in the face of seemingly irrational excuberance of others who want to scale to trillions of daily coffee transactions individually stored forever in the blockchain. When designing bitcoin or even some other system, an important design target is what the system should be capable of. How many transactions should the system perform? What is the correct number of transactions for a healthy, modern civilization to perform every day? And how fast should that (not) grow? Should we allow for 2 billion trillion coffee transactions every day, or what about 100 trillion transactions per second? I suspect that these sorts of questions are entirely unanswerable and boring. So in the absence of technical targets to reach during the design phase, I suspect that Jeff Garzik was right when he pointed out a few months ago that bitcoin is good at settlement and clearing. There are many potential technical solutions for aggregating millions (trillions?) of transactions into tiny bundles. As a small proof-of-concept, imagine two parties sending transactions back and forth 100 million times. Instead of recording every transaction, you could record the start state and the end state, and end up with two transactions or less. That's a 100 million fold, without modifying max block size and without potentially compromising secured decentralization. The MIT group should listen up and get to work figuring out how to measure decentralization and its security :-). Maybe we should be collectively pestering Andrew Miller to do this, too. No pressure, dude. Getting this measurement right would be really beneficial because we would have a more academic and technical understanding to work with. I would also characterize this as high priority next to the formally verified correctness proofs for Script and libbitcoinconsensus. Also, I think that getting this out in the open on this mailing list is an excellent step forward. - Bryan http://heybryan.org/ 1 512 203 0507 -- 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
On 5/6/2015 3:12 PM, Matt Corallo wrote: Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. I think it's way too early to even consider a future era when the fiat value of the block reward is no longer the biggest-by-far mining incentive. Creating fee pressure means driving some people to choose something else, not bitcoin. Too many people using bitcoin is nowhere on the list of problems today. It's reckless to tinker with adoption in hopes of spurring innovation on speculation, while a can kick is available. Adoption is currently at miniscule, test-flight, relatively insignificant levels when compared to global commerce. As Gavin discussed in the article, under Block size and miner fees… again, the best way to maximize miner incentives is to focus on doing things that are likely to increase adoption, which, in our fiat-dominated world, lead to a justifiably increased exchange rate. Any innovation attractive enough to relieve the block size pressure will do so just as well without artificial stimulus. Thanks for kicking off the discussion. -- 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
I don’t really have a strong opinion on block size either…but if we’re going to do a hard fork, let’s use this as an opportunity to create a good process for hard forks (which we’ll inevitably need to do again in the future). The change in block size is a very simple change that still allows us to explore all the complexities involved with deployment of hard forks. Let’s not just do a one-off ad-hoc thing. - Eric Lombrozo On May 6, 2015, at 3:30 PM, slush sl...@centrum.cz wrote: I don't have strong opinion @ block size topic. But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE (https://bitcointalk.org/index.php?topic=181734.0 https://bitcointalk.org/index.php?topic=181734.0) or its alternative. All developers of lightweight (blockchain-less) clients will adore you! slush On Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Block size is a question to which there is no answer, but which certainly has a LOT of technical tradeoffs to consider. I know a lot of people here have varying levels of strong or very strong opinions about this, and the fact that it is not being discussed in a technical community publicly anywhere is rather disappointing. So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase. Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler). This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo[1]. Matt [1] https://twitter.com/coinbase/status/595741967759335426 https://twitter.com/coinbase/status/595741967759335426 -- 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 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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
Re: [Bitcoin-development] Block Size Increase
On Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me wrote: The point of the hard block size limit is exactly because giving miners free rule to do anything they like with their blocks would allow them to do any number of crazy attacks. The incentives for miners to pick block sizes are no where near compatible with what allows the network to continue to run in a decentralized manner. Miners can always reduce the block size (if they coordinate). Increasing the maximum block size doesn't necessarily cause an increase. A majority of miners can soft-fork to set the limit lower than the hard limit. Setting the hard-fork limit higher means that a soft fork can be used to adjust the limit in the future. The reference client would accept blocks above the soft limit for wallet purposes, but not build on them. Blocks above the hard limit would be rejected completely. -- 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
I don't have strong opinion @ block size topic. But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE ( https://bitcointalk.org/index.php?topic=181734.0) or its alternative. All developers of lightweight (blockchain-less) clients will adore you! slush On Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me wrote: Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Block size is a question to which there is no answer, but which certainly has a LOT of technical tradeoffs to consider. I know a lot of people here have varying levels of strong or very strong opinions about this, and the fact that it is not being discussed in a technical community publicly anywhere is rather disappointing. So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase. Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler). This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo[1]. Matt [1] https://twitter.com/coinbase/status/595741967759335426 -- 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] Block Size Increase
I'm not so much opposed to a block size increase as I am opposed to a hard fork. My problem with a hard fork is that everyone and their brother wants to seize the opportunity of a hard fork to insert their own pet feature, and such a mad rush of lightly considered, obscure feature additions would be extremely risky for Bitcoin. If it could be guaranteed that raising the block size limit would be the only incompatible change introduced in the hard fork, then I would support it, but I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences. -- 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 Wed, May 06, 2015 at 11:41:37PM +, Matt Corallo wrote: Yes, but this does NOT make an actual policy. Note that the vast majority of miners already apply their own patches to Bitcoin Core, so applying one more is not all that hard. When blocks start to become limited (ie there is any fee left on the table by transactions not included in a block) there becomes incentive for miners to change that behavior pretty quick. Not just that, the vast majority of the hashpower is behind very large miners, who have little to no decentralization pressure. This results in very incompatible incentives, mainly that the incentive would be for the large miners to interconnect in a private network and generate only maximum-size blocks, creating a strong centralization pressure in the network. I'll also point out that miners with the goal of finding more blocks than their competition - a viable long-term strategy to increase market share and/or a short-term strategy to get more transaction fees - actually have a perverse incentive(1) to ensure their blocks do *not* get to more than ~30% of the hashing power. The main thing holding them back from doing that is that the inflation subsidy is still quite high - better to get the reward now than try to push your competition out of business. It's plausible that with a limited blocksize there won't be an opportunity to delay propagation by broadcasting larger blocks - if blocks propagate in a matter of seconds worst case there's no opportunity for gaming the system. But it does strongly show that we must build systems where that worst case propagation time in all circumstances is very short relative to the block interval. 1) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html -- 'peter'[:-1]@petertodd.org 04dc867e4541315090329f45ed4dd30e2fd7423a38a72c0e 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
On Wed, May 6, 2015 at 10:12 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell. 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. So please forgive me for the more than typical disorganization in this message; I've been caught a bit flatfooted on this and I'm trying to catch up. I'm juggling a fair amount of sudden pressure in my mailbox, and trying to navigate complex discussions in about eight different forums concurrently. There have been about a kazillion pages of discussion elsewhere (e.g. public IRC and Bitcointalk; private discussions in the past), not all of which is well known, and I can't hope to summarize even a tiny fraction of it in a single message-- but that's no reason to not start on it. Block size is a question to which there is no answer, but which certainly has a LOT of technical tradeoffs to consider. There are several orthogonal angles from which block size is a concern (both increases and non-increases). Most of them have subtle implications and each are worth its own research paper or six, so it can be difficult to only touch them slightly without creating a gish gallop that is hard to respond to. We're talking about tuning one of the fundamental scarcities of the Bitcoin Economy and cryptosystem--leaving the comfort of rule by math and venturing into the space of political decisions; elsewhere you'd expect to see really in-depth neutral analysis of the risks and tradeoffs, technically and economically. And make no mistake: there are real tradeoffs here, though we don't know their exact contours. Fundamentally this question exposes ideological differences between people interested in Bitcoin. Is Bitcoin more of a digital gold or is it more of a competitor to Square? Is Bitcoin something that should improve personal and commercial autonomy from central banks? From commercial banks? Or from just the existing status-quo commercial banks? What are people's fundamental rights with Bitcoin? Do participants have a right to mine? How much control should third parties have over their transactions? How much security must be provided? Is there a deadline for world domination or bust? Is Bitcoin only for the developed world? Must it be totally limited by the most impoverished parts of the world? Bitcoin exists at the intersection of many somewhat overlapping belief systems--and people of many views can find that Bitcoin meets their needs even when they don't completely agree politically. When Bitcoin is changed fundamentally, via a hard fork, to have different properties, the change can create winners or losers (if nothing else, then in terms of the kind of ideology supported by it). There are non-trivial number of people who hold extremes on any of these general belief patterns; Even among the core developers there is not a consensus on Bitcoin's optimal role in society and the commercial marketplace. To make it clear how broad the views go, even without getting into monetary policy... some people even argue that Bitcoin should act as censor-resistant storage system for outlawed content; -- I think this view is unsound, not achievable with the technology, and largely incompatible with Bitcoin's use as a money (because it potentially creates an externalized legal/harassment liability for node operators); but these are my personal value judgments; the view is earnestly held by more than a few; and that's a group that certainly wants the largest possible blocksizes (though even then that won't be enough). The subject is complicated even more purely on the technical side by the fact that Bitcoin has a layered security model which is not completely defined or understood: Bitcoin is secure if a majority of hashrate is honest (where honesty is a technical term which means follows the right rules without fail, even at a loss), but why might it be honest? That sends us into complex economic and social arguments, and the security thresholds start becoming worse when we assume some miners are economically rational instead of honest. increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are To elaborate, in my view there is a at least a two fold concern on this particular (Long term Mining incentives) front: One is that the long-held argument is that security of the Bitcoin system in the long term depends on fee income funding autonomous, anonymous, decentralized miners profitably applying enough
Re: [Bitcoin-development] Block Size Increase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 03:49 AM, Peter Todd wrote: I'm not sure if you've seen this, but a good paper on this topic was published recently: The Economics of Bitcoin Transaction Fees ..for some very strange definitions of good. That paper may present valid game theory, yet game theory has a well-known limitation when it comes to predicting real world behavior in that the predictions are only as good as the simplified model those predictions are based on is accurate. At the very least, we should wait to draw any conclusions from that paper until it has been sanity checked by a praxeological review. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVStYTAAoJECpf2nDq2eYjqzAQAJkLwVq3cJxaP5MirS6j+SkN NuRIQS8EzJkvojZvHCSRz3xPZpl9Cx2T6/hsLjIfzvMuDHKsaOkkLlL0q95ekv4T acfami64326DFAxiO0ptspPjCRipagmjSEwZGZwC/QZtTdnt+N9LsH0SFDP6hxbY Kf11LRd11Ap4v/VnBg/zb4daZnVm0k0nfZxK4rG1zN14r5JEu6eiodUBZc6e4qih LmopoddIwJS4MY1GoR2kCehAbJseZZyQQmHFEX1Vhc74ETGXWApfgF0tpo6ZMutd OT0WGhCpj4yG1u5bRaiNnsOy9WcBTKzDOLZUVVh/GhUGHWUulZu8ujYrX7Q6GR5S VPvOOL6Ts/RGEAE1UWKzHfPjrLZAHKgLAzBjm6o1ZXdBcnV+FsThNvd7fxHvaJsO pWGSu8qDmN/wH657Tphbthb4T/awnuf4rO6oBP+OGu+ydPIlIlt6rM2E4Bq366yy CJbzSR3x/P7fRmT2bbSg4rxTDyLFJpNIWOcNaMRBeO69OdNZxlranvFvEl/6FfqK GO/LPQiYCe/+yhXgUJzzlYpayPiPFWCg0FxwQ+xl1josTsrfPE4BUivkZvIlqOIY LX1fDHt/IIUNp8OUkY2eERxeB//dlY55nP7VGUEJLNnBkXuoBd70lMtGXxtgvw2M Wy5VER9CiEOUMMwzWi3Q =8mit -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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 Wed, May 06, 2015 at 10:12:14PM +, Matt Corallo wrote: Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler). Agreed. I'm not sure if you've seen this, but a good paper on this topic was published recently: The Economics of Bitcoin Transaction Fees Abstract We study the economics of Bitcoin transaction fees in a simple static partial equilibrium model with the specificity that the system security is directly linked to the total computational power of miners. We show that any situation with a fixed fee is equivalent to another situation with a limited block size. In both cases, we give the optimal value of the transaction fee or of the block size. We also show that making the block size a non binding constraint and, in the same time, letting the fee be fixed as the outcome of a decentralized competitive market cannot guarantee the very existence of Bitcoin in the long-term. -http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2400519 In short, without either a fixed blocksize or fixed fee per transaction Bitcoin will will not survive as there is no viable way to pay for PoW security. The latter option - fixed fee per transaction - is non-trivial to implement in a way that's actually meaningful - it's easy to give miners kickbacks - leaving us with a fixed blocksize. This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies I think this lack of understanding of the limitations of blockchain tech is very dangerous, never mind, downright misleading. I keep running into startups at conferences with completely unrealistic ideas about how large they'll be able to grow their on-blockchain businesses. For example, a few weeks ago at the Stanford blockchain conference I spoke to a company planning on using multisig escrow contracts to settle financial instruments, and expected to be doing about as many transactions/day on the blockchain for their business within a year or so as all other Bitcoin users currently do combined. These guys quite frankly had no understanding of the issues, and had apparently based their plans on the highly optimistic Bitcoin wiki page on scalability.(1) (I'd fix this now, but the wiki seems to not be allowing logins) We'd do a lot of startups a lot of good to give them accurate, and honest, advice about the scalability of the system. The wiki definitely isn't that. Neither is the bitcoin.org developer documentation(2), which doesn't mention scalability at all. which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo[1]. Even a relatively small increase to 20MB will greatly reduce the number of people who can participate fully in Bitcoin, creating an environment where the next increase requires the consent of an even smaller portion of the Bitcoin ecosystem. Where does that stop? What's the proposed mechanism that'll create an incentive and social consensus to not just 'kick the can down the road'(3) and further centralize but actually scale up Bitcoin the hard way? The only proposal that I've seen that attempts to do this is John Dillon's proof-of-stake blocksize vote(4), and that is far from getting consensus. 1) https://en.bitcoin.it/wiki/Scalability 2) https://bitcoin.org/en/developer-guide 3) http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea 4) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 04dc867e4541315090329f45ed4dd30e2fd7423a38a72c0e 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
On Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me wrote: Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Thanks for bringing this up. I'll try to keep my arguments brief, to avoid a long wall of text. I may be re-iterating some things that have been said before, though. I am - in general - in favor of increasing the size blocks: as technology grows, there is no reason why the systems built on them can't scale proportionally. I have so far not commented much about this, in a hope to avoid getting into a public debate, but the way seems to be going now, worries me greatly. * Controversial hard forks. I hope the mailing list here today already proves it is a controversial issue. Independent of personal opinions pro or against, I don't think we can do a hard fork that is controversial in nature. Either the result is effectively a fork, and pre-existing coins can be spent once on both sides (effectively failing Bitcoin's primary purpose), or the result is one side forced to upgrade to something they dislike - effectively giving a power to developers they should never have. Quoting someone: I did not sign up to be part of a central banker's committee. * The reason for increasing is need. If we need more space in blocks is the reason to do an upgrade, it won't stop after 20 MB. There is nothing fundamental possible with 20 MB blocks that isn't with 1 MB blocks. Changetip does not put their microtransactions on the chain, not with 1 MB, and I doubt they would with 20 MB blocks. The reason for increase should be because we choose to accept the trade-offs. * Misrepresentation of the trade-offs. You can argue all you want that none of the effects of larger blocks are particularly damaging, so everything is fine. They will damage something (see below for details), and we should analyze these effects, and be honest about them, and present them as a trade-off made we choose to make to scale the system better. If you just ask people if they want more transactions, of course you'll hear yes. If you ask people if they want to pay less taxes, I'm sure the vast majority will agree as well. * Miner centralization. There is currently, as far as I know, no technology that can relay and validate 20 MB blocks across the planet, in a manner fast enough to avoid very significant costs to mining. There is work in progress on this (including Gavin's IBLT-based relay, or Greg's block network coding), but I don't think we should be basing the future of the economics of the system on undemonstrated ideas. Without those (or even with), the result may be that miners self-limit the size of their blocks to propagate faster, but if this happens, larger, better-connected, and more centrally-located groups of miners gain a competitive advantage by being able to produce larger blocks. I would like to point out that there is nothing evil about this - a simple feedback to determine an optimal block size for an individual miner will result in larger blocks for better connected hash power. If we do not want miners to have this ability, we (as in: those using full nodes) should demand limitations that prevent it. One such limitation is a block size limit (whatever it is). * Ability to use a full node. I very much dislike the trend of people saying we need to encourage people to run full nodes, in order to make the network more decentralized. Running 1000 nodes which are otherwise unused only gives some better ability for full nodes to download the block chain, or for SPV nodes to learn about transactions (or be Sybil-attacked...). However, *using* a full node for validating your business (or personal!) transactions empowers you to using a financial system that requires less trust in *anyone* (not even in a decentralized group of peers) than anything else. Moreover, using a full node is what given you power of the systems' rules, as anyone who wants to change it now needs to convince you to upgrade. And yes, 20 MB blocks will change people's ability to use full nodes, even if the costs are small. * Skewed incentives for improvements. I think I can personally say that I'm responsible for most of the past years' performance improvements in Bitcoin Core. And there is a lot of room for improvement left there - things like silly waiting loops, single-threaded network processing, huge memory sinks, lock contention, ... which in my opinion don't nearly get the attention they deserve. This is in addition to more pervasive changes like optimizing the block transfer protocol, support for orthogonal systems with a different security/scalability trade-off like Lightning, making full validation optional, ... Call me cynical, but without actual pressure to work on these, I doubt much will change. Increasing the size of blocks now
