* [bitcoin-dev] The need for larger blocks @ 2015-06-26 14:09 Pieter Wuille 2015-06-26 14:38 ` Venzen Khaosan ` (4 more replies) 0 siblings, 5 replies; 61+ messages in thread From: Pieter Wuille @ 2015-06-26 14:09 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3217 bytes --] Hello all, here I'm going to try to address a part of the block size debate which has been troubling me since the beginning: the reason why people seem to want it. People say that larger blocks are necessary. In the long term, I agree - in the sense that systems that do not evolve tend to be replaced by other systems. This evolution can come in terms of layers on top of Bitcoin's blockchain, in terms of the technology underlying various aspects of the blockchain itself, and also in the scale that this technology supports. I do, however, fundamentally disagree that a fear for a change in economics should be considered to necessitate larger blocks. If it is, and there is consensus that we should adapt to it, then there is effectively no limit going forward. This is similar to how Congress voting to increase the copyright term retroactively from time to time is really no different from having an infinite copyright term in the first place. This scares me. Here is how Gavin summarizes the future without increasing block sizes in PR 6341: > 1. Transaction confirmation times for transactions with a given fee will rise; very-low-fee transactions will fail to get confirmed at all. > 2. Average transaction fee paid will rise > 3. People or applications unwilling or unable to pay the rising fees will stop submitting transactions > 4. People and businesses will shelve plans to use Bitcoin, stunting growth and adoption Is it fair to summarize this as "Some use cases won't fit any more, people will decide to no longer use the blockchain for these purposes, and the fees will adapt."? I think that is already happening, and will happen at any scale. I believe demand for payments in general is nearly infinite, and only a small portion of it will eventually fit on a block chain (independent of whether its size is limited by consensus rules or economic or technological means). Furthermore, systems that compete with Bitcoin in this space already offer orders of magnitude more capacity than we can reasonably achieve with any blockchain technology at this point. I don't know what subset of use cases Bitcoin will cater to in the long term. They have already changed - you see way less betting transactions these days than a few years ago for example - and they will keep changing, independent of what effective block sizes we end up with. I don't think we should be afraid of this change or try to stop it. If you look at graphs of block sizes over time (for example, http://rusty.ozlabs.org/?p=498), it seems to me that there is very little "organic" growth, and a lot of sudden changes (which could correspond to changing defaults in miner software, introduction of popular sites/services, changes in the economy). I think these can be seen as the economy changing to full up the available space, and I believe these will keep happening at any size effectively available. None of this is a reason why the size can't increase. However, in my opinion, we should do it because we believe it increases utility and understand the risks; not because we're afraid of what might happen if we don't hurry up. And from that point of view, it seems silly to make a huge increase at once... -- Pieter [-- Attachment #2: Type: text/html, Size: 3629 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 14:09 [bitcoin-dev] The need for larger blocks Pieter Wuille @ 2015-06-26 14:38 ` Venzen Khaosan 2015-06-26 15:22 ` Milly Bitcoin ` (3 subsequent siblings) 4 siblings, 0 replies; 61+ messages in thread From: Venzen Khaosan @ 2015-06-26 14:38 UTC (permalink / raw) To: Pieter Wuille, bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pieter, Sure. Your thinking is sound. I take things beyond where you have in your post, so I neither imply that this is your position or that this is the progression of your stated point. In one sense, one has to ask the question: is there a reasonable case for making Bitcoin super-capacitated so it can compete with Visa and just be the fastest-ever payment network with everyone jizzing in their pants over its speed and capacity and availability and dividends. By virtue of the core requirement of decentralization, for Bitcoin to remain meaningful, it will never compete with Visa or the Fed's new blockchain-based payment system. So, why attempt the impossible and expend energy on the futile? Bitcoin's protocol and payment network has features and benefits that Visa et all cannot have, so I refute the notion, sometimes expressed here, that 7tps is a major cap on growth and adoption. Such thinking takes as its axiom the idea that increased adoption correlates to increased value. Not true. Look at the price chart for proof: More businesses accept and more people are using and transacting via Bitcoin now than ever before and yet the price chart points *down*, not up. Why should any explicitly centralized exchange and business venture have their use of the protocol facilitated? Was the protocol designed to conform to financial capital demands or was it designed to fundamentally change the way ordinary users interact with markets? If those present here, do not realize that the blockchain is a means of escaping (and destroying through its use and promotion) centralization, then they have shells over their eyes. Bitcoin is not meant to fit into the system, it will evolve the system, by the system coming to it. Does that mean we shouldn't raise the blocksize? Maybe. But 8GB with BIP100's protections seems a reasonable change given the sudden increase in network usage that a global liquidity crisis will impose. Many scenarios are possible, but there is no onus on developers or on Bitcoin to "keep up". Like it or not, the global economy will inevitably be forced to Slow Down as a result of the same thinking that upholds constant growth without sympathetic contraction. Venzen Khaosan On 06/26/2015 09:09 PM, Pieter Wuille wrote: > Hello all, > > here I'm going to try to address a part of the block size debate > which has been troubling me since the beginning: the reason why > people seem to want it. > > People say that larger blocks are necessary. In the long term, I > agree - in the sense that systems that do not evolve tend to be > replaced by other systems. This evolution can come in terms of > layers on top of Bitcoin's blockchain, in terms of the technology > underlying various aspects of the blockchain itself, and also in > the scale that this technology supports. > > I do, however, fundamentally disagree that a fear for a change in > economics should be considered to necessitate larger blocks. If it > is, and there is consensus that we should adapt to it, then there > is effectively no limit going forward. This is similar to how > Congress voting to increase the copyright term retroactively from > time to time is really no different from having an infinite > copyright term in the first place. This scares me. > > Here is how Gavin summarizes the future without increasing block > sizes in PR 6341: > >> 1. Transaction confirmation times for transactions with a given >> fee > will rise; very-low-fee transactions will fail to get confirmed at > all. >> 2. Average transaction fee paid will rise 3. People or >> applications unwilling or unable to pay the rising fees > will stop submitting transactions >> 4. People and businesses will shelve plans to use Bitcoin, >> stunting > growth and adoption > > Is it fair to summarize this as "Some use cases won't fit any > more, people will decide to no longer use the blockchain for these > purposes, and the fees will adapt."? > > I think that is already happening, and will happen at any scale. I > believe demand for payments in general is nearly infinite, and only > a small portion of it will eventually fit on a block chain > (independent of whether its size is limited by consensus rules or > economic or technological means). Furthermore, systems that compete > with Bitcoin in this space already offer orders of magnitude more > capacity than we can reasonably achieve with any blockchain > technology at this point. > > I don't know what subset of use cases Bitcoin will cater to in the > long term. They have already changed - you see way less betting > transactions these days than a few years ago for example - and they > will keep changing, independent of what effective block sizes we > end up with. I don't think we should be afraid of this change or > try to stop it. > > If you look at graphs of block sizes over time (for example, > http://rusty.ozlabs.org/?p=498), it seems to me that there is very > little "organic" growth, and a lot of sudden changes (which could > correspond to changing defaults in miner software, introduction of > popular sites/services, changes in the economy). I think these can > be seen as the economy changing to full up the available space, and > I believe these will keep happening at any size effectively > available. > > None of this is a reason why the size can't increase. However, in > my opinion, we should do it because we believe it increases utility > and understand the risks; not because we're afraid of what might > happen if we don't hurry up. And from that point of view, it seems > silly to make a huge increase at once... > > -- Pieter > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVjWQAAAoJEGwAhlQc8H1mIRMH/Rr8v+N3XdAL/EeEXuniT+Iu /TrtieLJKrhmMPkyIX/jAWc4ggUirzWuTMIQZ7qPwOkVrbcWPcKKHOBKTmmUaCc5 GdnA8wiiC6D6ZMamO1NKtkU2QW7Kzuna/Y4EeqBZWsKWPrMvu1vkirDYH8XRvdiC bMksVCzoRFm7QnTMYfimrSYNxNPdwQZxCfhtJDSBnJs2Mi0J68Xpw5riVbx6S0mD TOcNlKWosQJEub11TWeh+wD3i901t5GfxFqBNU5XGN85JRn+vAIrrm2io0bbfbIZ y58XdqcYcWrx8MQNUdHpQT1EK5+4DAkhxrouW60sjk8jfWHGIVIgfYweDQawbOg= =f9Fg -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 14:09 [bitcoin-dev] The need for larger blocks Pieter Wuille 2015-06-26 14:38 ` Venzen Khaosan @ 2015-06-26 15:22 ` Milly Bitcoin 2015-06-26 15:24 ` Pieter Wuille 2015-06-26 15:38 ` Tom Harding ` (2 subsequent siblings) 4 siblings, 1 reply; 61+ messages in thread From: Milly Bitcoin @ 2015-06-26 15:22 UTC (permalink / raw) To: bitcoin-dev >None of this is a reason why the size can't increase. However, in my opinion, we should do it because we believe it increases utility and understand the risks; not because we're afraid of what might happen if we don't hurry up. And from that point of view, it seems silly to make a huge increase at once... Yes. I think people/businesses want some kind of assurance that there is a path to get things done when needed rather than immediate changes. Since there is currently no clear path/schedule to get any changes accomplished they gets anxious. Russ ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 15:22 ` Milly Bitcoin @ 2015-06-26 15:24 ` Pieter Wuille 2015-06-26 18:05 ` Jeff Garzik 0 siblings, 1 reply; 61+ messages in thread From: Pieter Wuille @ 2015-06-26 15:24 UTC (permalink / raw) To: Milly Bitcoin; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 721 bytes --] On Fri, Jun 26, 2015 at 5:22 PM, Milly Bitcoin <milly@bitcoins.info> wrote: > >None of this is a reason why the size can't increase. However, in my > opinion, we should do it because we believe it increases utility and > understand the risks; not because we're afraid of what might happen if we > don't hurry up. And from that point of view, it seems silly to make a huge > increase at once... > > Yes. I think people/businesses want some kind of assurance that there is > a path to get things done when needed rather than immediate changes. Since > there is currently no clear path/schedule to get any changes accomplished > they gets anxious. > I think you just proved my point by saying "when needed". -- Pieter [-- Attachment #2: Type: text/html, Size: 1102 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 15:24 ` Pieter Wuille @ 2015-06-26 18:05 ` Jeff Garzik 2015-06-26 18:32 ` Milly Bitcoin 0 siblings, 1 reply; 61+ messages in thread From: Jeff Garzik @ 2015-06-26 18:05 UTC (permalink / raw) To: Pieter Wuille; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2185 bytes --] On Fri, Jun 26, 2015 at 8:24 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote: > On Fri, Jun 26, 2015 at 5:22 PM, Milly Bitcoin <milly@bitcoins.info> > wrote: > >> >None of this is a reason why the size can't increase. However, in my >> opinion, we should do it because we believe it increases utility and >> understand the risks; not because we're afraid of what might happen if we >> don't hurry up. And from that point of view, it seems silly to make a huge >> increase at once... >> >> Yes. I think people/businesses want some kind of assurance that there is >> a path to get things done when needed rather than immediate changes. Since >> there is currently no clear path/schedule to get any changes accomplished >> they gets anxious. >> > > I think you just proved my point by saying "when needed". > Proposing inaction is not the way you convince people that bitcoin can scale. People and businesses cannot perform any capacity planning and future projections under the proposal of "economic change through inaction." There will be no growth, by your argument, until there is fee pressure. And what happens then? a) Block size limit increases, disrupting and rebooting the fee market. or b) You argue that fees have taken care of the capacity. Waiting until blocks are full before taking action produces even more disruption and market-unpredictable behavior than today. I understand you want a fee market to develop, and increasing the block size limit retards/prevents that. The fact remains that that is a _major_ change to economic policy that creates a _more_ unpredictable system. Who knows when Pieter will agree that a fee market is healthy? And at that time, once blocks are full, changing the block size limit then will produce even more disruption, going from little pressure -> lots of pressure -> little pressure Inaction produces fee pressure produces volatility. And makes it more difficult for system users to perform capacity planning. I see a lot of microscopic fee analysis - economically insignificant for at least 12 months to come - and very little holistic analysis from people arguing that inaction is the best course. [-- Attachment #2: Type: text/html, Size: 3358 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 18:05 ` Jeff Garzik @ 2015-06-26 18:32 ` Milly Bitcoin 0 siblings, 0 replies; 61+ messages in thread From: Milly Bitcoin @ 2015-06-26 18:32 UTC (permalink / raw) To: bitcoin-dev > Proposing inaction is not the way you convince people that bitcoin can > scale. > > People and businesses cannot perform any capacity planning and future > projections under the proposal of "economic change through inaction." > > There will be no growth, by your argument, until there is fee > pressure. And what happens then? It is not clear he is proposing "inaction." I am not sure what he is proposing other than being against knee-jerk reactions. He has also said he doesn't want to take on the responsibility of deciding on whether to approve hard fork changes which is understandable considering all the other things he is doing. Such a responsibility is probably too much of a burden to put on any one individual no matter who it is. The next step is to come up with a process to handle proposed hard-fork changes other than just to ask the Core maintainer to do it. Russ ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 14:09 [bitcoin-dev] The need for larger blocks Pieter Wuille 2015-06-26 14:38 ` Venzen Khaosan 2015-06-26 15:22 ` Milly Bitcoin @ 2015-06-26 15:38 ` Tom Harding 2015-06-26 16:22 ` Venzen Khaosan 2015-06-26 17:57 ` Jeff Garzik 2015-06-27 7:43 ` Wladimir J. van der Laan 4 siblings, 1 reply; 61+ messages in thread From: Tom Harding @ 2015-06-26 15:38 UTC (permalink / raw) To: Pieter Wuille; +Cc: bitcoin-dev On 6/26/2015 7:09 AM, Pieter Wuille wrote: > Furthermore, systems that compete with Bitcoin in this space already > offer orders of magnitude more capacity than we can reasonably achieve > with any blockchain technology at this point. "Reasonably achievable" is a guideline that would keep bitcoin out of trouble caused by either too little, or too much, declared capacity. This matches Gavin's thinking, though you may differ on the numbers. > it seems silly to make a huge increase at once... Unless it is reasonably achievable. Leave the rest to the free market. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 15:38 ` Tom Harding @ 2015-06-26 16:22 ` Venzen Khaosan 2015-06-26 17:04 ` Tom Harding 0 siblings, 1 reply; 61+ messages in thread From: Venzen Khaosan @ 2015-06-26 16:22 UTC (permalink / raw) To: Tom Harding, bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Apologies in advance for pulling you up on your statement, Tom, I've noticed you're a regular and well respected poster in this list: "free market" who? Are you aware that the Bitcoin rally of 2013 was a result of speculation by elements in Citi Bank, JPMorgan, and by many other Wall Street trading desk managers who saw the opportunity of a free-floating, unregulated commodity? If the intention is to leave Bitcoin to the "free market" it already is, and has been there for some time. As for miners, those are finance capitalist interest too - if not currently, in their majority, then eventually in China and the rest of the world, so what does the term "free market" really mean? It must be defined, because you are speaking to developers here, not visionary economists or politicized brains, necessarily. We cannot speak about "the market" without referencing concerns about centralization, because any centralized business that plays the game right seeks, by the rules, to corner the market. If they cannot do it alone, they will seek allies. "Free market" means as much under capitalism as "open democracy" under Stalinism. Do you see my point? "Free Market" is a multivariate term and Bitcoin does not (and should not have to) cater to all its demands. That's like applying Microsoft standards to FOSS efforts - becuase that's the "business use-case". Bitcoin developers have to think about economy in an informed manner and make provision with protection, else one can just make like Mike Hearn and jump up and down shouting "faster-faster more-more". Economics, markets and speculation is more complicated than that. Venzen On 06/26/2015 10:38 PM, Tom Harding wrote: > On 6/26/2015 7:09 AM, Pieter Wuille wrote: >> Furthermore, systems that compete with Bitcoin in this space >> already offer orders of magnitude more capacity than we can >> reasonably achieve with any blockchain technology at this point. > > "Reasonably achievable" is a guideline that would keep bitcoin out > of trouble caused by either too little, or too much, declared > capacity. This matches Gavin's thinking, though you may differ on > the numbers. > > >> it seems silly to make a huge increase at once... > > Unless it is reasonably achievable. Leave the rest to the free > market. > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVjXw4AAoJEGwAhlQc8H1mX2kIAJCLodhsEhkzxkzZl1hUITkZ fFZWuiKomsHTHU+6cCr0snt0VDI7+mP8SgyawWrwXNKdGKqpiUAX+B454I9POYBQ pf/CUq/sWMFN/WRO1EYpVBz3zH/mDgMUZeLvnGYti05+3YzxJxBsy2cmkX5HCfUL oUErqWEo+OjeQNT+ZgFSbYYLSBLO2fDJglPzXD4eTF6RrK3AsZpHgnVqQzlAC+4G Q7zRQN/h3voXJ5ed684Hy8bb04KKsEo0EYx2Nz6Hd9mGkSnnqydIa8ieJO3ChYyi IDyJVXpDOth0TshZARbTFuicYg0ULUmU/l5x38Z3HFp9J1G4GFhnoivBwRozlQ8= =a+o4 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 16:22 ` Venzen Khaosan @ 2015-06-26 17:04 ` Tom Harding 2015-06-26 17:55 ` Gavin Andresen 0 siblings, 1 reply; 61+ messages in thread From: Tom Harding @ 2015-06-26 17:04 UTC (permalink / raw) To: venzen; +Cc: bitcoin-dev Venzen -- The market for block space is not at all the same as the market for bitcoin. The centralization risk that is discussed in relation to the market for block space arises from the resources (network, storage, processor...) required to run a full node. That is a consideration in determining the actual (as opposed to declared) capacity of the system. The 1MB cap was not indexed to increasing resource availability to begin with, so one way to determine the size of any initial hard cap increase would be to estimate the change in resource availability since that time. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 17:04 ` Tom Harding @ 2015-06-26 17:55 ` Gavin Andresen 0 siblings, 0 replies; 61+ messages in thread From: Gavin Andresen @ 2015-06-26 17:55 UTC (permalink / raw) To: Tom Harding; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 854 bytes --] I completely agree with Pieter: usage will grow to fill whatever maximum block size the miners decide to allow (or whatever maximum block size is imposed by minimum transaction fees or a hard cap on block size). I am not scared by increased usage, though: more usage and adoption means more investment, more smart engineers, and more people with incentives to solve whatever scaling problems crop up. All of that makes Bitcoin stronger. And I don't feel like this process has been hurried: I've been working on this (thinking, testing, simulating, talking, writing code, talking to key people and companies) almost exclusively since late last year. In my humble opinion, BIP 101 is a good compromise between "no limit, let the miners decide" and "lower the max size so a raspberry pi running on a 56K modem can be a full node." -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 1057 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 14:09 [bitcoin-dev] The need for larger blocks Pieter Wuille ` (2 preceding siblings ...) 2015-06-26 15:38 ` Tom Harding @ 2015-06-26 17:57 ` Jeff Garzik 2015-06-26 18:12 ` Pieter Wuille 2015-06-27 7:43 ` Wladimir J. van der Laan 4 siblings, 1 reply; 61+ messages in thread From: Jeff Garzik @ 2015-06-26 17:57 UTC (permalink / raw) To: Pieter Wuille; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4845 bytes --] It is not "fear" of fee pressure. 1) Blocks are mostly not-full on average. 2) Absent long blocks and stress tests, there is little fee pressure above the anti-spam relay fee metric, because of #1. 3) As such, inducing fee pressure is a delta, a change from years-long bitcoin economic policy. Each time we approach the soft limit, Bitcoin Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al. lobbies miners to upgrade. (note - this is not an endorsement of these actions - it is a neutral observation) 4) Inaction leads to consistent fee pressure as the months tick on and system volume grows; thus, inaction leads to economic policy change. 5) Economic policy change leads to market and software disruption. The market and software - notably wallets - is not prepared for this. 6) If you want to change economic policy, that's fine. But be honest and admit you are arguing for a change, a delta from current market expectations and behavior. 7) It is critical to first deal with what _is_, not what you wish the world to be. You want a fee market to develop. There is nothing wrong with that desire. It remains a delta from where we are today, and that is critically relevant in a $3b+ market. On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote: > Hello all, > > here I'm going to try to address a part of the block size debate which has > been troubling me since the beginning: the reason why people seem to want > it. > > People say that larger blocks are necessary. In the long term, I agree - > in the sense that systems that do not evolve tend to be replaced by other > systems. This evolution can come in terms of layers on top of Bitcoin's > blockchain, in terms of the technology underlying various aspects of the > blockchain itself, and also in the scale that this technology supports. > > I do, however, fundamentally disagree that a fear for a change in > economics should be considered to necessitate larger blocks. If it is, and > there is consensus that we should adapt to it, then there is effectively no > limit going forward. This is similar to how Congress voting to increase the > copyright term retroactively from time to time is really no different from > having an infinite copyright term in the first place. This scares me. > > Here is how Gavin summarizes the future without increasing block sizes in > PR 6341: > > > 1. Transaction confirmation times for transactions with a given fee will > rise; very-low-fee transactions will fail to get confirmed at all. > > 2. Average transaction fee paid will rise > > 3. People or applications unwilling or unable to pay the rising fees > will stop submitting transactions > > 4. People and businesses will shelve plans to use Bitcoin, stunting > growth and adoption > > Is it fair to summarize this as "Some use cases won't fit any more, people > will decide to no longer use the blockchain for these purposes, and the > fees will adapt."? > > I think that is already happening, and will happen at any scale. I believe > demand for payments in general is nearly infinite, and only a small portion > of it will eventually fit on a block chain (independent of whether its size > is limited by consensus rules or economic or technological means). > Furthermore, systems that compete with Bitcoin in this space already offer > orders of magnitude more capacity than we can reasonably achieve with any > blockchain technology at this point. > > I don't know what subset of use cases Bitcoin will cater to in the long > term. They have already changed - you see way less betting transactions > these days than a few years ago for example - and they will keep changing, > independent of what effective block sizes we end up with. I don't think we > should be afraid of this change or try to stop it. > > If you look at graphs of block sizes over time (for example, > http://rusty.ozlabs.org/?p=498), it seems to me that there is very little > "organic" growth, and a lot of sudden changes (which could correspond to > changing defaults in miner software, introduction of popular > sites/services, changes in the economy). I think these can be seen as the > economy changing to full up the available space, and I believe these will > keep happening at any size effectively available. > > None of this is a reason why the size can't increase. However, in my > opinion, we should do it because we believe it increases utility and > understand the risks; not because we're afraid of what might happen if we > don't hurry up. And from that point of view, it seems silly to make a huge > increase at once... > > -- > Pieter > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 6059 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 17:57 ` Jeff Garzik @ 2015-06-26 18:12 ` Pieter Wuille 2015-06-26 18:23 ` Jeff Garzik 2015-06-26 18:29 ` Alex Morcos 0 siblings, 2 replies; 61+ messages in thread From: Pieter Wuille @ 2015-06-26 18:12 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 5743 bytes --] I am not saying that economic change is what we want. Only that it is inevitable, independent of whether larger blocks happen or not. I am saying that acting because of fear of economic change is a bad reason. The reason for increase should be because of the higher utility. We need it at some point, but there should be no rush. I do understand that we want to avoid a *sudden* change in economic policy, but I'm generally not too worried. Either fees increase and they get paid, and we're good. But more likely is that some uses just move off-chain because the block chain does not offer what they need. That's sad, but it is inevitable at any size: some uses fit, some don't. -- Pieter On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote: > It is not "fear" of fee pressure. > > 1) Blocks are mostly not-full on average. > > 2) Absent long blocks and stress tests, there is little fee pressure above > the anti-spam relay fee metric, because of #1. > > 3) As such, inducing fee pressure is a delta, a change from years-long > bitcoin economic policy. Each time we approach the soft limit, Bitcoin > Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al. > lobbies miners to upgrade. > > (note - this is not an endorsement of these actions - it is a neutral > observation) > > 4) Inaction leads to consistent fee pressure as the months tick on and > system volume grows; thus, inaction leads to economic policy change. > > 5) Economic policy change leads to market and software disruption. The > market and software - notably wallets - is not prepared for this. > > 6) If you want to change economic policy, that's fine. But be honest and > admit you are arguing for a change, a delta from current market > expectations and behavior. > > 7) It is critical to first deal with what _is_, not what you wish the > world to be. You want a fee market to develop. There is nothing wrong > with that desire. It remains a delta from where we are today, and that is > critically relevant in a $3b+ market. > > > > > > > > > On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille@gmail.com> > wrote: > >> Hello all, >> >> here I'm going to try to address a part of the block size debate which >> has been troubling me since the beginning: the reason why people seem to >> want it. >> >> People say that larger blocks are necessary. In the long term, I agree - >> in the sense that systems that do not evolve tend to be replaced by other >> systems. This evolution can come in terms of layers on top of Bitcoin's >> blockchain, in terms of the technology underlying various aspects of the >> blockchain itself, and also in the scale that this technology supports. >> >> I do, however, fundamentally disagree that a fear for a change in >> economics should be considered to necessitate larger blocks. If it is, and >> there is consensus that we should adapt to it, then there is effectively no >> limit going forward. This is similar to how Congress voting to increase the >> copyright term retroactively from time to time is really no different from >> having an infinite copyright term in the first place. This scares me. >> >> Here is how Gavin summarizes the future without increasing block sizes in >> PR 6341: >> >> > 1. Transaction confirmation times for transactions with a given fee >> will rise; very-low-fee transactions will fail to get confirmed at all. >> > 2. Average transaction fee paid will rise >> > 3. People or applications unwilling or unable to pay the rising fees >> will stop submitting transactions >> > 4. People and businesses will shelve plans to use Bitcoin, stunting >> growth and adoption >> >> Is it fair to summarize this as "Some use cases won't fit any more, >> people will decide to no longer use the blockchain for these purposes, and >> the fees will adapt."? >> >> I think that is already happening, and will happen at any scale. I >> believe demand for payments in general is nearly infinite, and only a small >> portion of it will eventually fit on a block chain (independent of whether >> its size is limited by consensus rules or economic or technological means). >> Furthermore, systems that compete with Bitcoin in this space already offer >> orders of magnitude more capacity than we can reasonably achieve with any >> blockchain technology at this point. >> >> I don't know what subset of use cases Bitcoin will cater to in the long >> term. They have already changed - you see way less betting transactions >> these days than a few years ago for example - and they will keep changing, >> independent of what effective block sizes we end up with. I don't think we >> should be afraid of this change or try to stop it. >> >> If you look at graphs of block sizes over time (for example, >> http://rusty.ozlabs.org/?p=498), it seems to me that there is very >> little "organic" growth, and a lot of sudden changes (which could >> correspond to changing defaults in miner software, introduction of popular >> sites/services, changes in the economy). I think these can be seen as the >> economy changing to full up the available space, and I believe these will >> keep happening at any size effectively available. >> >> None of this is a reason why the size can't increase. However, in my >> opinion, we should do it because we believe it increases utility and >> understand the risks; not because we're afraid of what might happen if we >> don't hurry up. And from that point of view, it seems silly to make a huge >> increase at once... >> >> -- >> Pieter >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > [-- Attachment #2: Type: text/html, Size: 7125 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 18:12 ` Pieter Wuille @ 2015-06-26 18:23 ` Jeff Garzik 2015-06-26 18:31 ` Mark Friedenbach ` (3 more replies) 2015-06-26 18:29 ` Alex Morcos 1 sibling, 4 replies; 61+ messages in thread From: Jeff Garzik @ 2015-06-26 18:23 UTC (permalink / raw) To: Pieter Wuille; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 7081 bytes --] Failure to plan now for a hard fork increase 6(?) months in the future produces that lumpy, unpredictable market behavior. The market has baked in the years-long behavior of low fees. From the market PoV, inaction does lead to precisely that, a sudden change over the span of a few months. At a higher level, people look at bitcoin and see people delaying, waiting, dawdling until the barn is actually on fire before taking action to put out the fire. They see a system that is not responsive to higher level externalities of people & businesses making plans for the future. Based on current proposal of change-through-inaction, businesses will simply shelve plans to use bitcoin and not bother putting those new users on the network. If you wait until the need to increase block size is acute, it is already too late. (1) Businesses have permanently shelved plans to use bitcoin and (2) change at that point produces _larger_ disruption to the fee market. Hard forks require planning many months in advance. Gavin's timing is sound, even though the Gavin/Hearn Bitcoin-XT antics were sub-optimal. On Fri, Jun 26, 2015 at 11:12 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote: > I am not saying that economic change is what we want. Only that it is > inevitable, independent of whether larger blocks happen or not. > > I am saying that acting because of fear of economic change is a bad > reason. The reason for increase should be because of the higher utility. We > need it at some point, but there should be no rush. > > I do understand that we want to avoid a *sudden* change in economic > policy, but I'm generally not too worried. Either fees increase and they > get paid, and we're good. But more likely is that some uses just move > off-chain because the block chain does not offer what they need. That's > sad, but it is inevitable at any size: some uses fit, some don't. > > -- > Pieter > On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote: > >> It is not "fear" of fee pressure. >> >> 1) Blocks are mostly not-full on average. >> >> 2) Absent long blocks and stress tests, there is little fee pressure >> above the anti-spam relay fee metric, because of #1. >> >> 3) As such, inducing fee pressure is a delta, a change from years-long >> bitcoin economic policy. Each time we approach the soft limit, Bitcoin >> Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al. >> lobbies miners to upgrade. >> >> (note - this is not an endorsement of these actions - it is a neutral >> observation) >> >> 4) Inaction leads to consistent fee pressure as the months tick on and >> system volume grows; thus, inaction leads to economic policy change. >> >> 5) Economic policy change leads to market and software disruption. The >> market and software - notably wallets - is not prepared for this. >> >> 6) If you want to change economic policy, that's fine. But be honest and >> admit you are arguing for a change, a delta from current market >> expectations and behavior. >> >> 7) It is critical to first deal with what _is_, not what you wish the >> world to be. You want a fee market to develop. There is nothing wrong >> with that desire. It remains a delta from where we are today, and that is >> critically relevant in a $3b+ market. >> >> >> >> >> >> >> >> >> On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille@gmail.com> >> wrote: >> >>> Hello all, >>> >>> here I'm going to try to address a part of the block size debate which >>> has been troubling me since the beginning: the reason why people seem to >>> want it. >>> >>> People say that larger blocks are necessary. In the long term, I agree - >>> in the sense that systems that do not evolve tend to be replaced by other >>> systems. This evolution can come in terms of layers on top of Bitcoin's >>> blockchain, in terms of the technology underlying various aspects of the >>> blockchain itself, and also in the scale that this technology supports. >>> >>> I do, however, fundamentally disagree that a fear for a change in >>> economics should be considered to necessitate larger blocks. If it is, and >>> there is consensus that we should adapt to it, then there is effectively no >>> limit going forward. This is similar to how Congress voting to increase the >>> copyright term retroactively from time to time is really no different from >>> having an infinite copyright term in the first place. This scares me. >>> >>> Here is how Gavin summarizes the future without increasing block sizes >>> in PR 6341: >>> >>> > 1. Transaction confirmation times for transactions with a given fee >>> will rise; very-low-fee transactions will fail to get confirmed at all. >>> > 2. Average transaction fee paid will rise >>> > 3. People or applications unwilling or unable to pay the rising fees >>> will stop submitting transactions >>> > 4. People and businesses will shelve plans to use Bitcoin, stunting >>> growth and adoption >>> >>> Is it fair to summarize this as "Some use cases won't fit any more, >>> people will decide to no longer use the blockchain for these purposes, and >>> the fees will adapt."? >>> >>> I think that is already happening, and will happen at any scale. I >>> believe demand for payments in general is nearly infinite, and only a small >>> portion of it will eventually fit on a block chain (independent of whether >>> its size is limited by consensus rules or economic or technological means). >>> Furthermore, systems that compete with Bitcoin in this space already offer >>> orders of magnitude more capacity than we can reasonably achieve with any >>> blockchain technology at this point. >>> >>> I don't know what subset of use cases Bitcoin will cater to in the long >>> term. They have already changed - you see way less betting transactions >>> these days than a few years ago for example - and they will keep changing, >>> independent of what effective block sizes we end up with. I don't think we >>> should be afraid of this change or try to stop it. >>> >>> If you look at graphs of block sizes over time (for example, >>> http://rusty.ozlabs.org/?p=498), it seems to me that there is very >>> little "organic" growth, and a lot of sudden changes (which could >>> correspond to changing defaults in miner software, introduction of popular >>> sites/services, changes in the economy). I think these can be seen as the >>> economy changing to full up the available space, and I believe these will >>> keep happening at any size effectively available. >>> >>> None of this is a reason why the size can't increase. However, in my >>> opinion, we should do it because we believe it increases utility and >>> understand the risks; not because we're afraid of what might happen if we >>> don't hurry up. And from that point of view, it seems silly to make a huge >>> increase at once... >>> >>> -- >>> Pieter >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> [-- Attachment #2: Type: text/html, Size: 8956 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 18:23 ` Jeff Garzik @ 2015-06-26 18:31 ` Mark Friedenbach 2015-06-26 19:05 ` Aaron Voisine 2015-06-26 18:34 ` Pieter Wuille ` (2 subsequent siblings) 3 siblings, 1 reply; 61+ messages in thread From: Mark Friedenbach @ 2015-06-26 18:31 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 8067 bytes --] Jeff, block size limits large enough to prevent fee pressure is absolutely, unequivocally unsustainable. We are already running against technological limits in the tradeoff between decentralization and utility. Increases of the block size limit in advance of fee pressure only delay the problem -- it does not and cannot solve it! We must be careful to use the block size limit now to get infrastructure to support a world with full blocks -- it's not that hard -- while still having a little room to grow fast if things unexpectedly break. On Fri, Jun 26, 2015 at 11:23 AM, Jeff Garzik <jgarzik@gmail.com> wrote: > Failure to plan now for a hard fork increase 6(?) months in the future > produces that lumpy, unpredictable market behavior. > > The market has baked in the years-long behavior of low fees. From the > market PoV, inaction does lead to precisely that, a sudden change over the > span of a few months. > > At a higher level, people look at bitcoin and see people delaying, > waiting, dawdling until the barn is actually on fire before taking action > to put out the fire. > > They see a system that is not responsive to higher level externalities of > people & businesses making plans for the future. Based on current proposal > of change-through-inaction, businesses will simply shelve plans to use > bitcoin and not bother putting those new users on the network. > > If you wait until the need to increase block size is acute, it is already > too late. (1) Businesses have permanently shelved plans to use bitcoin and > (2) change at that point produces _larger_ disruption to the fee market. > > Hard forks require planning many months in advance. Gavin's timing is > sound, even though the Gavin/Hearn Bitcoin-XT antics were sub-optimal. > > > > > > > > On Fri, Jun 26, 2015 at 11:12 AM, Pieter Wuille <pieter.wuille@gmail.com> > wrote: > >> I am not saying that economic change is what we want. Only that it is >> inevitable, independent of whether larger blocks happen or not. >> >> I am saying that acting because of fear of economic change is a bad >> reason. The reason for increase should be because of the higher utility. We >> need it at some point, but there should be no rush. >> >> I do understand that we want to avoid a *sudden* change in economic >> policy, but I'm generally not too worried. Either fees increase and they >> get paid, and we're good. But more likely is that some uses just move >> off-chain because the block chain does not offer what they need. That's >> sad, but it is inevitable at any size: some uses fit, some don't. >> >> -- >> Pieter >> On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote: >> >>> It is not "fear" of fee pressure. >>> >>> 1) Blocks are mostly not-full on average. >>> >>> 2) Absent long blocks and stress tests, there is little fee pressure >>> above the anti-spam relay fee metric, because of #1. >>> >>> 3) As such, inducing fee pressure is a delta, a change from years-long >>> bitcoin economic policy. Each time we approach the soft limit, Bitcoin >>> Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al. >>> lobbies miners to upgrade. >>> >>> (note - this is not an endorsement of these actions - it is a neutral >>> observation) >>> >>> 4) Inaction leads to consistent fee pressure as the months tick on and >>> system volume grows; thus, inaction leads to economic policy change. >>> >>> 5) Economic policy change leads to market and software disruption. The >>> market and software - notably wallets - is not prepared for this. >>> >>> 6) If you want to change economic policy, that's fine. But be honest >>> and admit you are arguing for a change, a delta from current market >>> expectations and behavior. >>> >>> 7) It is critical to first deal with what _is_, not what you wish the >>> world to be. You want a fee market to develop. There is nothing wrong >>> with that desire. It remains a delta from where we are today, and that is >>> critically relevant in a $3b+ market. >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille@gmail.com> >>> wrote: >>> >>>> Hello all, >>>> >>>> here I'm going to try to address a part of the block size debate which >>>> has been troubling me since the beginning: the reason why people seem to >>>> want it. >>>> >>>> People say that larger blocks are necessary. In the long term, I agree >>>> - in the sense that systems that do not evolve tend to be replaced by other >>>> systems. This evolution can come in terms of layers on top of Bitcoin's >>>> blockchain, in terms of the technology underlying various aspects of the >>>> blockchain itself, and also in the scale that this technology supports. >>>> >>>> I do, however, fundamentally disagree that a fear for a change in >>>> economics should be considered to necessitate larger blocks. If it is, and >>>> there is consensus that we should adapt to it, then there is effectively no >>>> limit going forward. This is similar to how Congress voting to increase the >>>> copyright term retroactively from time to time is really no different from >>>> having an infinite copyright term in the first place. This scares me. >>>> >>>> Here is how Gavin summarizes the future without increasing block sizes >>>> in PR 6341: >>>> >>>> > 1. Transaction confirmation times for transactions with a given fee >>>> will rise; very-low-fee transactions will fail to get confirmed at all. >>>> > 2. Average transaction fee paid will rise >>>> > 3. People or applications unwilling or unable to pay the rising fees >>>> will stop submitting transactions >>>> > 4. People and businesses will shelve plans to use Bitcoin, stunting >>>> growth and adoption >>>> >>>> Is it fair to summarize this as "Some use cases won't fit any more, >>>> people will decide to no longer use the blockchain for these purposes, and >>>> the fees will adapt."? >>>> >>>> I think that is already happening, and will happen at any scale. I >>>> believe demand for payments in general is nearly infinite, and only a small >>>> portion of it will eventually fit on a block chain (independent of whether >>>> its size is limited by consensus rules or economic or technological means). >>>> Furthermore, systems that compete with Bitcoin in this space already offer >>>> orders of magnitude more capacity than we can reasonably achieve with any >>>> blockchain technology at this point. >>>> >>>> I don't know what subset of use cases Bitcoin will cater to in the long >>>> term. They have already changed - you see way less betting transactions >>>> these days than a few years ago for example - and they will keep changing, >>>> independent of what effective block sizes we end up with. I don't think we >>>> should be afraid of this change or try to stop it. >>>> >>>> If you look at graphs of block sizes over time (for example, >>>> http://rusty.ozlabs.org/?p=498), it seems to me that there is very >>>> little "organic" growth, and a lot of sudden changes (which could >>>> correspond to changing defaults in miner software, introduction of popular >>>> sites/services, changes in the economy). I think these can be seen as the >>>> economy changing to full up the available space, and I believe these will >>>> keep happening at any size effectively available. >>>> >>>> None of this is a reason why the size can't increase. However, in my >>>> opinion, we should do it because we believe it increases utility and >>>> understand the risks; not because we're afraid of what might happen if we >>>> don't hurry up. And from that point of view, it seems silly to make a huge >>>> increase at once... >>>> >>>> -- >>>> Pieter >>>> >>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>>> >>> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 10258 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 18:31 ` Mark Friedenbach @ 2015-06-26 19:05 ` Aaron Voisine 0 siblings, 0 replies; 61+ messages in thread From: Aaron Voisine @ 2015-06-26 19:05 UTC (permalink / raw) To: Mark Friedenbach; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 9188 bytes --] > Jeff, block size limits large enough to prevent fee pressure is absolutely, unequivocally unsustainable. This is demonstrably false. It's clear that having no fee pressure is unsustainable, of course. But people are paying fees today, so that means there must be fee pressure. How is this the case then since blocks are typically below the block size limit? There must be some other mechanism inducing fee pressure. This mechanism is standard minimum relay rules, and transaction selection rules for blocks. These are the methods that all bitcoin software today has been built around, and handles well. Aaron Voisine co-founder and CEO breadwallet.com On Fri, Jun 26, 2015 at 11:31 AM, Mark Friedenbach <mark@friedenbach.org> wrote: > Jeff, block size limits large enough to prevent fee pressure is > absolutely, unequivocally unsustainable. We are already running against > technological limits in the tradeoff between decentralization and utility. > Increases of the block size limit in advance of fee pressure only delay the > problem -- it does not and cannot solve it! > > We must be careful to use the block size limit now to get infrastructure > to support a world with full blocks -- it's not that hard -- while still > having a little room to grow fast if things unexpectedly break. > > > On Fri, Jun 26, 2015 at 11:23 AM, Jeff Garzik <jgarzik@gmail.com> wrote: > >> Failure to plan now for a hard fork increase 6(?) months in the future >> produces that lumpy, unpredictable market behavior. >> >> The market has baked in the years-long behavior of low fees. From the >> market PoV, inaction does lead to precisely that, a sudden change over the >> span of a few months. >> >> At a higher level, people look at bitcoin and see people delaying, >> waiting, dawdling until the barn is actually on fire before taking action >> to put out the fire. >> >> They see a system that is not responsive to higher level externalities of >> people & businesses making plans for the future. Based on current proposal >> of change-through-inaction, businesses will simply shelve plans to use >> bitcoin and not bother putting those new users on the network. >> >> If you wait until the need to increase block size is acute, it is already >> too late. (1) Businesses have permanently shelved plans to use bitcoin and >> (2) change at that point produces _larger_ disruption to the fee market. >> >> Hard forks require planning many months in advance. Gavin's timing is >> sound, even though the Gavin/Hearn Bitcoin-XT antics were sub-optimal. >> >> >> >> >> >> >> >> On Fri, Jun 26, 2015 at 11:12 AM, Pieter Wuille <pieter.wuille@gmail.com> >> wrote: >> >>> I am not saying that economic change is what we want. Only that it is >>> inevitable, independent of whether larger blocks happen or not. >>> >>> I am saying that acting because of fear of economic change is a bad >>> reason. The reason for increase should be because of the higher utility. We >>> need it at some point, but there should be no rush. >>> >>> I do understand that we want to avoid a *sudden* change in economic >>> policy, but I'm generally not too worried. Either fees increase and they >>> get paid, and we're good. But more likely is that some uses just move >>> off-chain because the block chain does not offer what they need. That's >>> sad, but it is inevitable at any size: some uses fit, some don't. >>> >>> -- >>> Pieter >>> On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote: >>> >>>> It is not "fear" of fee pressure. >>>> >>>> 1) Blocks are mostly not-full on average. >>>> >>>> 2) Absent long blocks and stress tests, there is little fee pressure >>>> above the anti-spam relay fee metric, because of #1. >>>> >>>> 3) As such, inducing fee pressure is a delta, a change from years-long >>>> bitcoin economic policy. Each time we approach the soft limit, Bitcoin >>>> Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al. >>>> lobbies miners to upgrade. >>>> >>>> (note - this is not an endorsement of these actions - it is a neutral >>>> observation) >>>> >>>> 4) Inaction leads to consistent fee pressure as the months tick on and >>>> system volume grows; thus, inaction leads to economic policy change. >>>> >>>> 5) Economic policy change leads to market and software disruption. The >>>> market and software - notably wallets - is not prepared for this. >>>> >>>> 6) If you want to change economic policy, that's fine. But be honest >>>> and admit you are arguing for a change, a delta from current market >>>> expectations and behavior. >>>> >>>> 7) It is critical to first deal with what _is_, not what you wish the >>>> world to be. You want a fee market to develop. There is nothing wrong >>>> with that desire. It remains a delta from where we are today, and that is >>>> critically relevant in a $3b+ market. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille@gmail.com >>>> > wrote: >>>> >>>>> Hello all, >>>>> >>>>> here I'm going to try to address a part of the block size debate which >>>>> has been troubling me since the beginning: the reason why people seem to >>>>> want it. >>>>> >>>>> People say that larger blocks are necessary. In the long term, I agree >>>>> - in the sense that systems that do not evolve tend to be replaced by other >>>>> systems. This evolution can come in terms of layers on top of Bitcoin's >>>>> blockchain, in terms of the technology underlying various aspects of the >>>>> blockchain itself, and also in the scale that this technology supports. >>>>> >>>>> I do, however, fundamentally disagree that a fear for a change in >>>>> economics should be considered to necessitate larger blocks. If it is, and >>>>> there is consensus that we should adapt to it, then there is effectively no >>>>> limit going forward. This is similar to how Congress voting to increase the >>>>> copyright term retroactively from time to time is really no different from >>>>> having an infinite copyright term in the first place. This scares me. >>>>> >>>>> Here is how Gavin summarizes the future without increasing block sizes >>>>> in PR 6341: >>>>> >>>>> > 1. Transaction confirmation times for transactions with a given fee >>>>> will rise; very-low-fee transactions will fail to get confirmed at all. >>>>> > 2. Average transaction fee paid will rise >>>>> > 3. People or applications unwilling or unable to pay the rising fees >>>>> will stop submitting transactions >>>>> > 4. People and businesses will shelve plans to use Bitcoin, stunting >>>>> growth and adoption >>>>> >>>>> Is it fair to summarize this as "Some use cases won't fit any more, >>>>> people will decide to no longer use the blockchain for these purposes, and >>>>> the fees will adapt."? >>>>> >>>>> I think that is already happening, and will happen at any scale. I >>>>> believe demand for payments in general is nearly infinite, and only a small >>>>> portion of it will eventually fit on a block chain (independent of whether >>>>> its size is limited by consensus rules or economic or technological means). >>>>> Furthermore, systems that compete with Bitcoin in this space already offer >>>>> orders of magnitude more capacity than we can reasonably achieve with any >>>>> blockchain technology at this point. >>>>> >>>>> I don't know what subset of use cases Bitcoin will cater to in the >>>>> long term. They have already changed - you see way less betting >>>>> transactions these days than a few years ago for example - and they will >>>>> keep changing, independent of what effective block sizes we end up with. I >>>>> don't think we should be afraid of this change or try to stop it. >>>>> >>>>> If you look at graphs of block sizes over time (for example, >>>>> http://rusty.ozlabs.org/?p=498), it seems to me that there is very >>>>> little "organic" growth, and a lot of sudden changes (which could >>>>> correspond to changing defaults in miner software, introduction of popular >>>>> sites/services, changes in the economy). I think these can be seen as the >>>>> economy changing to full up the available space, and I believe these will >>>>> keep happening at any size effectively available. >>>>> >>>>> None of this is a reason why the size can't increase. However, in my >>>>> opinion, we should do it because we believe it increases utility and >>>>> understand the risks; not because we're afraid of what might happen if we >>>>> don't hurry up. And from that point of view, it seems silly to make a huge >>>>> increase at once... >>>>> >>>>> -- >>>>> Pieter >>>>> >>>>> >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>> >>>>> >>>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 11997 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 18:23 ` Jeff Garzik 2015-06-26 18:31 ` Mark Friedenbach @ 2015-06-26 18:34 ` Pieter Wuille 2015-06-26 19:18 ` Ross Nicoll 2015-06-26 18:47 ` Patrick Strateman 2015-06-26 20:44 ` Owen Gunden 3 siblings, 1 reply; 61+ messages in thread From: Pieter Wuille @ 2015-06-26 18:34 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 925 bytes --] > If you wait until the need to increase block size It is this sentence I disagree with. Why would there be a need? Bitcoin provides utility at any block size, and potentially more with larger blocks. But no matter what, I believe the economy will adapt to what is available. And setting a precedent that increasing the size "because of a need" is reasonable is to me essentially the same as saying the size should forever scale to whatever people want. I believe the most important effect of a limit block size - people deciding not to use (on chain) Bitcoin transactions, is already happening, and it will keep happening at any scale. Either the resulting market is one which can live with high variability in confirmation times, and blocks will end up being nearly full. Or maybe the current fill level is what is acceptable, and we don't see much growth beyond this, only a change in what it is used for. -- Pieter [-- Attachment #2: Type: text/html, Size: 1057 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 18:34 ` Pieter Wuille @ 2015-06-26 19:18 ` Ross Nicoll 2015-06-26 19:36 ` Peter Todd 0 siblings, 1 reply; 61+ messages in thread From: Ross Nicoll @ 2015-06-26 19:18 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2841 bytes --] I'd argue that at the point where there's consistently more transactions than the network can handle, there are two significant risks. Firstly, that people don't care enough to pay the transaction fees required to get their transaction prioritised over another's, and secondly that as transactions start outright failing (which will happen with enough transactions backlogged) the network is considered unreliable, the currency illiquid, and there's a virtual "bank rush" to get into a more usable currency. I understand the desire to use current demand to model future, however I feel there's a lack of understanding of just how inadequate the main chain is as a global clearance network. My go-to example for this is CHIPS (US-only, inter-bank only clearance) which already handles slightly over 3 transactions per second on average across a year (https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en). If Bitcoin is to be used across a wider portion of the world's population, and/or beyond clearance between financial institutions, it needs larger blocks. This is not about handling the several orders of magnitude more transactions that would be required to replace credit cards or cash, but simply to enabling other technologies to perform that scaling. Also, and I'm aware most on this list do understand the situation better than this, I find it immensely frustrating to see people suggesting that Greece or other large groups should adopt Bitcoin, while there's clearly inadequate support (on chain or off) to do so. Ross On 26/06/2015 19:34, Pieter Wuille wrote: > > > If you wait until the need to increase block size > > It is this sentence I disagree with. Why would there be a need? > Bitcoin provides utility at any block size, and potentially more with > larger blocks. > > But no matter what, I believe the economy will adapt to what is > available. And setting a precedent that increasing the size "because > of a need" is reasonable is to me essentially the same as saying the > size should forever scale to whatever people want. > > I believe the most important effect of a limit block size - people > deciding not to use (on chain) Bitcoin transactions, is already > happening, and it will keep happening at any scale. > > Either the resulting market is one which can live with high > variability in confirmation times, and blocks will end up being nearly > full. Or maybe the current fill level is what is acceptable, and we > don't see much growth beyond this, only a change in what it is used for. > > -- > Pieter > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 4022 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 19:18 ` Ross Nicoll @ 2015-06-26 19:36 ` Peter Todd 2015-06-27 6:13 ` Filipe Farinha 0 siblings, 1 reply; 61+ messages in thread From: Peter Todd @ 2015-06-26 19:36 UTC (permalink / raw) To: Ross Nicoll; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2746 bytes --] On Fri, Jun 26, 2015 at 08:18:07PM +0100, Ross Nicoll wrote: > I'd argue that at the point where there's consistently more > transactions than the network can handle, there are two significant > risks. Firstly, that people don't care enough to pay the transaction > fees required to get their transaction prioritised over another's, > and secondly that as transactions start outright failing (which will > happen with enough transactions backlogged) the network is > considered unreliable, the currency illiquid, and there's a virtual > "bank rush" to get into a more usable currency. The supply and demand fee market means that there is a range of reliability levels depending on what fee you pay; regardless of how high demand is if you pay a sufficiently high fee that outbids less important/lower fee transactions you'll get reliable transaction confirmaiton. The perceived lack of reliability is a function of the poor state of wallet software, not an inherent problem with the system. Fixing that software is much easier and much less risky than any hard-fork ever will be. From my article on transaction fees during the CoinWallet.eu flood: What needs to be done ===================== Transaction fees aren't going away, blocksize increase or not. CoinWallet.eu is only spending $5k flooding the network; even an 8MB blocksize increase can only raise the cost of that attack to $40k, which is still very affordable. For instance an attacker looking to manipulate the Bitcoin price could probably afford to spend $40k doing it with the right trading strategy; let alone governments, banks, big businesses, criminal enterprises, etc. to whom $40k is chump-change. Wallets need to become smarter about fees, as does the rest of the Bitcoin community. What we need to do: * Add fee/KB displays to block explorers. * Change wallets to calculate and set fees in fee/KB rather than fixed fees regardless of tx size. * Make websites with easy to understand displays of what the current mempool backlog is, and what fee/KB is needed to get to the front of the queue. We've done a great job for Bitcoin price charts, let's extend that to transaction fees. * Add the ability to set any fee/KB to wallets, rather than be stuck with predefined options that may not be high enough. * Add support for fee-bumping via (FSS)-RBF to wallets and Bitcoin Core. Capacity limits are just a fact of life in the design of the Bitcoin protocol, but that doesn't mean we can't give users the tools to deal with them intelligently. -https://gist.github.com/petertodd/8e87c782bdf342ef18fb -- 'peter'[:-1]@petertodd.org 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 19:36 ` Peter Todd @ 2015-06-27 6:13 ` Filipe Farinha 2015-06-27 7:14 ` Aaron Voisine 0 siblings, 1 reply; 61+ messages in thread From: Filipe Farinha @ 2015-06-27 6:13 UTC (permalink / raw) To: bitcoin-dev On 27/06/2015 03:36, Peter Todd wrote: > * Make websites with easy to understand displays of what the current mempool > backlog is, and what fee/KB is needed to get to the front of the queue. We've > done a great job for Bitcoin price charts, let's extend that to transaction > fees. > +1 This is especially important if take into account all the projects that aim to build upon the bitcoin blockchain and that can have a significant impact, both in terms of storage space as well as transaction volume spikes. Just recently I suggested the need for a BIP to standardize reporting of "delay alerts" in wallets, so that users can act accordingly (i.e. fee-bump, postpone, cancel) before sending their transactions during these periods of increased transaction volume. https://community.blockstack.org/t/blockstore-footprint-on-blockchain/68/5?u=ktorn IMHO keeping the users informed of potential issues before committing transactions to the network can go a long way towards preventing frustration and potential backlashes against blockchain tech. Filipe Farinha ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 6:13 ` Filipe Farinha @ 2015-06-27 7:14 ` Aaron Voisine 2015-06-27 15:13 ` Peter Todd 0 siblings, 1 reply; 61+ messages in thread From: Aaron Voisine @ 2015-06-27 7:14 UTC (permalink / raw) To: Filipe Farinha; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1707 bytes --] Also remember that the sender is not the one who cares about delays or even getting confirmations at all, it's the receiver who's concerned with these things. They have to tell the sender up-front what they're willing to accept in exchange for goods and services. Aaron Voisine co-founder and CEO breadwallet.com On Fri, Jun 26, 2015 at 11:13 PM, Filipe Farinha <filipe@ktorn.com> wrote: > On 27/06/2015 03:36, Peter Todd wrote: > >> * Make websites with easy to understand displays of what the current >> mempool >> backlog is, and what fee/KB is needed to get to the front of the >> queue. We've >> done a great job for Bitcoin price charts, let's extend that to >> transaction >> fees. >> >> +1 > > This is especially important if take into account all the projects that > aim to build upon the bitcoin blockchain and that can have a significant > impact, both in terms of storage space as well as transaction volume spikes. > > Just recently I suggested the need for a BIP to standardize reporting of > "delay alerts" in wallets, so that users can act accordingly (i.e. > fee-bump, postpone, cancel) before sending their transactions during these > periods of increased transaction volume. > > > https://community.blockstack.org/t/blockstore-footprint-on-blockchain/68/5?u=ktorn > > IMHO keeping the users informed of potential issues before committing > transactions to the network can go a long way towards preventing > frustration and potential backlashes against blockchain tech. > > Filipe Farinha > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 2821 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 7:14 ` Aaron Voisine @ 2015-06-27 15:13 ` Peter Todd 2015-06-27 19:40 ` Aaron Voisine 0 siblings, 1 reply; 61+ messages in thread From: Peter Todd @ 2015-06-27 15:13 UTC (permalink / raw) To: Aaron Voisine, Filipe Farinha; +Cc: bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 27 June 2015 03:14:41 GMT-04:00, Aaron Voisine <voisine@gmail.com> wrote: >Also remember that the sender is not the one who cares about delays or >even >getting confirmations at all, it's the receiver who's concerned with >these >things. They have to tell the sender up-front what they're willing to >accept in exchange for goods and services. You're assuming a receiver who is accepting a zeroconf transaction; most receivers don't. For instance, when I deposit funds on my exchange they don't credit those funds until 4 confirmations, so I very much cafe about how long it takes to get the first confirmation. -----BEGIN PGP SIGNATURE----- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVjr2g AAoJEMCF8hzn9Lnc47AIAJBa5O+H+XEqok4j8AEly9rjAMmdcOrqJSoNvtCj897l R34cN/5SfYIRpvFoyBKXfY+xo0RR/42VM08uju+vvCAvImiwOyrUNPTS2TmDdE3M PTGgQrYIctQxTcek9VL8TV94bHns+kJxMiOySdsOA+7NLl0oKoNKoHhYbbWPcn/+ 13p+su2Xi/ydO6HjHHxR/3kpQE4q8tupGDH0ZaPUijyd04uvB4GK4pPA5P7EeM9b ixXB8aZnSYhbVnknUFfcTBLHzo70BQbTh0QFTZCOkNSwIoBfyEhd53IZ+BfJGbLo 2K2VcMHeVU91Zbg+rgKNfGuLQvr5hEfZIkqZckXDj6I= =B/YW -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 15:13 ` Peter Todd @ 2015-06-27 19:40 ` Aaron Voisine 0 siblings, 0 replies; 61+ messages in thread From: Aaron Voisine @ 2015-06-27 19:40 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 968 bytes --] On Sat, Jun 27, 2015 at 8:13 AM, Peter Todd <pete@petertodd.org> wrote: > On 27 June 2015 03:14:41 GMT-04:00, Aaron Voisine <voisine@gmail.com> > wrote: > >Also remember that the sender is not the one who cares about delays or > >even > >getting confirmations at all, it's the receiver who's concerned with > >these > >things. They have to tell the sender up-front what they're willing to > >accept in exchange for goods and services. > > You're assuming a receiver who is accepting a zeroconf transaction; most > receivers don't. > > For instance, when I deposit funds on my exchange they don't credit those > funds until 4 confirmations, so I very much cafe about how long it takes to > get the first confirmation. > Yes, the receiver can tell the sender up-front that they are only willing accept 4-confirmations, and put that on the sender to figure out, but the sender then only cares because it's the receiver's requirement. The receiver is the one who cares. [-- Attachment #2: Type: text/html, Size: 1425 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 18:23 ` Jeff Garzik 2015-06-26 18:31 ` Mark Friedenbach 2015-06-26 18:34 ` Pieter Wuille @ 2015-06-26 18:47 ` Patrick Strateman 2015-06-26 19:03 ` Tier Nolan 2015-06-26 20:44 ` Owen Gunden 3 siblings, 1 reply; 61+ messages in thread From: Patrick Strateman @ 2015-06-26 18:47 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 8991 bytes --] Planning for a hard forks which change the consensus rules (including the blocksize limit) is something we can all agree is worthy of time and effort. However there is clearly not consensus sufficient today to deploy a hard fork that changs the blocksize without there being serious and potentially experiment ending consequences. For a proposed hard fork to reach a level of consensus necessary to be safe requires that there be a clear and self evident course of action. That simply does not exist on the blocksize limit question. On 06/26/2015 11:23 AM, Jeff Garzik wrote: > Failure to plan now for a hard fork increase 6(?) months in the future > produces that lumpy, unpredictable market behavior. > > The market has baked in the years-long behavior of low fees. From the > market PoV, inaction does lead to precisely that, a sudden change over > the span of a few months. > > At a higher level, people look at bitcoin and see people delaying, > waiting, dawdling until the barn is actually on fire before taking > action to put out the fire. > > They see a system that is not responsive to higher level externalities > of people & businesses making plans for the future. Based on current > proposal of change-through-inaction, businesses will simply shelve > plans to use bitcoin and not bother putting those new users on the > network. > > If you wait until the need to increase block size is acute, it is > already too late. (1) Businesses have permanently shelved plans to > use bitcoin and (2) change at that point produces _larger_ disruption > to the fee market. > > Hard forks require planning many months in advance. Gavin's timing is > sound, even though the Gavin/Hearn Bitcoin-XT antics were sub-optimal. > > > > > > > > On Fri, Jun 26, 2015 at 11:12 AM, Pieter Wuille > <pieter.wuille@gmail.com <mailto:pieter.wuille@gmail.com>> wrote: > > I am not saying that economic change is what we want. Only that it > is inevitable, independent of whether larger blocks happen or not. > > I am saying that acting because of fear of economic change is a > bad reason. The reason for increase should be because of the > higher utility. We need it at some point, but there should be no rush. > > I do understand that we want to avoid a *sudden* change in > economic policy, but I'm generally not too worried. Either fees > increase and they get paid, and we're good. But more likely is > that some uses just move off-chain because the block chain does > not offer what they need. That's sad, but it is inevitable at any > size: some uses fit, some don't. > > -- > Pieter > > On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik@gmail.com > <mailto:jgarzik@gmail.com>> wrote: > > It is not "fear" of fee pressure. > > 1) Blocks are mostly not-full on average. > > 2) Absent long blocks and stress tests, there is little fee > pressure above the anti-spam relay fee metric, because of #1. > > 3) As such, inducing fee pressure is a delta, a change from > years-long bitcoin economic policy. Each time we approach the > soft limit, Bitcoin Core increases the soft limit to prevent > "full" blocks. Mike Hearn et. al. lobbies miners to upgrade. > > (note - this is not an endorsement of these actions - it is a > neutral observation) > > 4) Inaction leads to consistent fee pressure as the months > tick on and system volume grows; thus, inaction leads to > economic policy change. > > 5) Economic policy change leads to market and software > disruption. The market and software - notably wallets - is > not prepared for this. > > 6) If you want to change economic policy, that's fine. But be > honest and admit you are arguing for a change, a delta from > current market expectations and behavior. > > 7) It is critical to first deal with what _is_, not what you > wish the world to be. You want a fee market to develop. > There is nothing wrong with that desire. It remains a delta > from where we are today, and that is critically relevant in a > $3b+ market. > > > > > > > > > On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille > <pieter.wuille@gmail.com <mailto:pieter.wuille@gmail.com>> wrote: > > Hello all, > > here I'm going to try to address a part of the block size > debate which has been troubling me since the beginning: > the reason why people seem to want it. > > People say that larger blocks are necessary. In the long > term, I agree - in the sense that systems that do not > evolve tend to be replaced by other systems. This > evolution can come in terms of layers on top of Bitcoin's > blockchain, in terms of the technology underlying various > aspects of the blockchain itself, and also in the scale > that this technology supports. > > I do, however, fundamentally disagree that a fear for a > change in economics should be considered to necessitate > larger blocks. If it is, and there is consensus that we > should adapt to it, then there is effectively no limit > going forward. This is similar to how Congress voting to > increase the copyright term retroactively from time to > time is really no different from having an infinite > copyright term in the first place. This scares me. > > Here is how Gavin summarizes the future without increasing > block sizes in PR 6341: > > > 1. Transaction confirmation times for transactions with > a given fee will rise; very-low-fee transactions will fail > to get confirmed at all. > > 2. Average transaction fee paid will rise > > 3. People or applications unwilling or unable to pay the > rising fees will stop submitting transactions > > 4. People and businesses will shelve plans to use > Bitcoin, stunting growth and adoption > > Is it fair to summarize this as "Some use cases won't fit > any more, people will decide to no longer use the > blockchain for these purposes, and the fees will adapt."? > > I think that is already happening, and will happen at any > scale. I believe demand for payments in general is nearly > infinite, and only a small portion of it will eventually > fit on a block chain (independent of whether its size is > limited by consensus rules or economic or technological > means). Furthermore, systems that compete with Bitcoin in > this space already offer orders of magnitude more capacity > than we can reasonably achieve with any blockchain > technology at this point. > > I don't know what subset of use cases Bitcoin will cater > to in the long term. They have already changed - you see > way less betting transactions these days than a few years > ago for example - and they will keep changing, independent > of what effective block sizes we end up with. I don't > think we should be afraid of this change or try to stop it. > > If you look at graphs of block sizes over time (for > example, http://rusty.ozlabs.org/?p=498), it seems to me > that there is very little "organic" growth, and a lot of > sudden changes (which could correspond to changing > defaults in miner software, introduction of popular > sites/services, changes in the economy). I think these can > be seen as the economy changing to full up the available > space, and I believe these will keep happening at any size > effectively available. > > None of this is a reason why the size can't increase. > However, in my opinion, we should do it because we believe > it increases utility and understand the risks; not because > we're afraid of what might happen if we don't hurry up. > And from that point of view, it seems silly to make a huge > increase at once... > > -- > Pieter > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 18405 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 18:47 ` Patrick Strateman @ 2015-06-26 19:03 ` Tier Nolan 2015-06-26 19:12 ` Mark Friedenbach 0 siblings, 1 reply; 61+ messages in thread From: Tier Nolan @ 2015-06-26 19:03 UTC (permalink / raw) Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 613 bytes --] On Fri, Jun 26, 2015 at 7:47 PM, Patrick Strateman < patrick.strateman@gmail.com> wrote: > For a proposed hard fork to reach a level of consensus necessary to be > safe requires that there be a clear and self evident course of action. > Safety increases with more lead-in time. If the reference client was updated so that the hard fork happened in two years, it would be pretty safe. Miners would have time to update. If miners (or the community) objected, it is sort of like a game of chicken. This is one of the problems with not making decisions in advance, the resulting hard fork is inherently safer. [-- Attachment #2: Type: text/html, Size: 1046 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 19:03 ` Tier Nolan @ 2015-06-26 19:12 ` Mark Friedenbach 0 siblings, 0 replies; 61+ messages in thread From: Mark Friedenbach @ 2015-06-26 19:12 UTC (permalink / raw) To: Tier Nolan; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1172 bytes --] This is a hard fork. It is not about miners, at all. 2013 showed that when there is true consensus mining can be coordinated on the order of hours or days. This is about pushing through a coercive change to the decentralization tradeoffs of bitcoin without unanimous consent. On Jun 26, 2015 12:03 PM, "Tier Nolan" <tier.nolan@gmail.com> wrote: > On Fri, Jun 26, 2015 at 7:47 PM, Patrick Strateman < > patrick.strateman@gmail.com> wrote: > >> For a proposed hard fork to reach a level of consensus necessary to be >> safe requires that there be a clear and self evident course of action. >> > > Safety increases with more lead-in time. If the reference client was > updated so that the hard fork happened in two years, it would be pretty > safe. Miners would have time to update. > > If miners (or the community) objected, it is sort of like a game of > chicken. > > This is one of the problems with not making decisions in advance, the > resulting hard fork is inherently safer. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 2008 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 18:23 ` Jeff Garzik ` (2 preceding siblings ...) 2015-06-26 18:47 ` Patrick Strateman @ 2015-06-26 20:44 ` Owen Gunden 2015-06-27 2:18 ` Eric Lombrozo 3 siblings, 1 reply; 61+ messages in thread From: Owen Gunden @ 2015-06-26 20:44 UTC (permalink / raw) To: bitcoin-dev On 06/26/2015 02:23 PM, Jeff Garzik wrote: > Failure to plan now for a hard fork increase 6(?) months in the future > produces that lumpy, unpredictable market behavior. > > The market has baked in the years-long behavior of low fees. From the > market PoV, inaction does lead to precisely that, a sudden change over > the span of a few months. Which market participants are you referring to? I entered the bitcoin market with open eyes, aware that it faces hard scalability challenges by design. I was also aware that because of these challenges, eventually transaction fees would have to rise. Nevertheless, I made the decision to invest because of the utility I gain from the anti-censorship, privacy, control, store of value, and security aspects of bitcoin -- many of which stem from decentralization, which others have demonstrated to be linked to the block size. On the other hand, there are undoubtedly other market participants who heard hype about "zero fee transactions to anywhere in the world", believed it would scale, and made (mal)investments as a result. As for how many market participants of each flavor, and how deep their respective pockets, who knows? My experience in markets has lead me to realize that it's never wise to assume I know what "the market" does and doesn't know. If Jeff Garzik is right about what the market has priced in, then yes, filled blocks will be rocking the boat. But who's to say that the smartest, biggest investors and traders don't already see this scaling problem, and have already priced it in? In this case, a sudden large increase in the block size is actually rocking the boat. The point is, you can't know either way, so trying to pre-empt the market in this way is erroneous. Regarding entrepreneurial investment specifically, why should we favor the entrepreneurs who require a more centralized bitcoin over those who were more considerate of the possibility of rising transaction fees when making their business models? In my mind, we should favor neither, which is why I'm basically in agreement with Pieter that this sense of "emergency" shouldn't really be a part of the debate. Not that I'm taking a stand on the specific block size issue either way. I just think this particular line of reasoning (presupposing what information the market has and has not already baked in) is unsound. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 20:44 ` Owen Gunden @ 2015-06-27 2:18 ` Eric Lombrozo 2015-06-27 2:54 ` Eric Lombrozo 2015-06-27 8:16 ` Venzen Khaosan 0 siblings, 2 replies; 61+ messages in thread From: Eric Lombrozo @ 2015-06-27 2:18 UTC (permalink / raw) To: Owen Gunden; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4507 bytes --] I’ve been pondering this whole scale issue considerably…and am left with the conclusion that blockchains are ultimately dispute resolution mechanisms. The vast majority of crypto negotiation will be taking place at levels lesser than global consensus in the future - global consensus is just far too expensive to require for every single cappuccino. There really is little need to take most cases globally…unless the participants disagree. I’ve commented in other places that blockchains are essentially a “fix” to the prisoner’s dilemma - they make cooperation the equilibrium strategy. Regardless of whatever linear factor we scale the blockchain by, it is simple math to see that any exponential growth (even if for a short time) in usage will overwhelm the current network. If we ever intend to take bitcoin mainstream, we will most likely experience at least a short time of exponential growth…at least until we either reach an inherent limitation or until we saturate. As Pieter said earlier, FAPP right now the demand for payments might as well be infinite. We’re nowhere near the ability to service it all. The block size issue is really a usability issue at this point. There are two fundamental things we need to solve: 1) There’s no model for how we’ll introduce a fee market, even though the design of Bitcoin fundamentally depends on fees for its survival (at least in the current form of the design.) 2) There’s no mechanism for how to perform fee bidding and estimation. Most wallets simply have no way to do this without serious usability problems. If we’re going to talk about block fees, let’s keep it in the context of these relevant issues and not confound it with the scalability issue…these are two very different issues. - Eric Lombrozo > On Jun 26, 2015, at 1:44 PM, Owen Gunden <ogunden@phauna.org> wrote: > > On 06/26/2015 02:23 PM, Jeff Garzik wrote: >> Failure to plan now for a hard fork increase 6(?) months in the future >> produces that lumpy, unpredictable market behavior. >> >> The market has baked in the years-long behavior of low fees. From the >> market PoV, inaction does lead to precisely that, a sudden change over >> the span of a few months. > > Which market participants are you referring to? > > I entered the bitcoin market with open eyes, aware that it faces hard scalability challenges by design. I was also aware that because of these challenges, eventually transaction fees would have to rise. > > Nevertheless, I made the decision to invest because of the utility I gain from the anti-censorship, privacy, control, store of value, and security aspects of bitcoin -- many of which stem from decentralization, which others have demonstrated to be linked to the block size. > > On the other hand, there are undoubtedly other market participants who heard hype about "zero fee transactions to anywhere in the world", believed it would scale, and made (mal)investments as a result. > > As for how many market participants of each flavor, and how deep their respective pockets, who knows? My experience in markets has lead me to realize that it's never wise to assume I know what "the market" does and doesn't know. If Jeff Garzik is right about what the market has priced in, then yes, filled blocks will be rocking the boat. But who's to say that the smartest, biggest investors and traders don't already see this scaling problem, and have already priced it in? In this case, a sudden large increase in the block size is actually rocking the boat. The point is, you can't know either way, so trying to pre-empt the market in this way is erroneous. > > Regarding entrepreneurial investment specifically, why should we favor the entrepreneurs who require a more centralized bitcoin over those who were more considerate of the possibility of rising transaction fees when making their business models? > > In my mind, we should favor neither, which is why I'm basically in agreement with Pieter that this sense of "emergency" shouldn't really be a part of the debate. > > Not that I'm taking a stand on the specific block size issue either way. I just think this particular line of reasoning (presupposing what information the market has and has not already baked in) is unsound. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 842 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 2:18 ` Eric Lombrozo @ 2015-06-27 2:54 ` Eric Lombrozo 2015-06-27 8:16 ` Venzen Khaosan 1 sibling, 0 replies; 61+ messages in thread From: Eric Lombrozo @ 2015-06-27 2:54 UTC (permalink / raw) To: Owen Gunden; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4882 bytes --] I should add that a strategy of “let’s avoid fee pressure as much as possible. let’s avoid even thinking about how we’ll transition as much as possible.” strikes me as at least a tad bit myopic. - Eric Lombrozo > On Jun 26, 2015, at 7:18 PM, Eric Lombrozo <elombrozo@gmail.com> wrote: > > I’ve been pondering this whole scale issue considerably…and am left with the conclusion that blockchains are ultimately dispute resolution mechanisms. The vast majority of crypto negotiation will be taking place at levels lesser than global consensus in the future - global consensus is just far too expensive to require for every single cappuccino. There really is little need to take most cases globally…unless the participants disagree. I’ve commented in other places that blockchains are essentially a “fix” to the prisoner’s dilemma - they make cooperation the equilibrium strategy. > > Regardless of whatever linear factor we scale the blockchain by, it is simple math to see that any exponential growth (even if for a short time) in usage will overwhelm the current network. If we ever intend to take bitcoin mainstream, we will most likely experience at least a short time of exponential growth…at least until we either reach an inherent limitation or until we saturate. As Pieter said earlier, FAPP right now the demand for payments might as well be infinite. We’re nowhere near the ability to service it all. > > The block size issue is really a usability issue at this point. There are two fundamental things we need to solve: > > 1) There’s no model for how we’ll introduce a fee market, even though the design of Bitcoin fundamentally depends on fees for its survival (at least in the current form of the design.) > > 2) There’s no mechanism for how to perform fee bidding and estimation. Most wallets simply have no way to do this without serious usability problems. > > > > If we’re going to talk about block fees, let’s keep it in the context of these relevant issues and not confound it with the scalability issue…these are two very different issues. > > > - Eric Lombrozo > > >> On Jun 26, 2015, at 1:44 PM, Owen Gunden <ogunden@phauna.org> wrote: >> >> On 06/26/2015 02:23 PM, Jeff Garzik wrote: >>> Failure to plan now for a hard fork increase 6(?) months in the future >>> produces that lumpy, unpredictable market behavior. >>> >>> The market has baked in the years-long behavior of low fees. From the >>> market PoV, inaction does lead to precisely that, a sudden change over >>> the span of a few months. >> >> Which market participants are you referring to? >> >> I entered the bitcoin market with open eyes, aware that it faces hard scalability challenges by design. I was also aware that because of these challenges, eventually transaction fees would have to rise. >> >> Nevertheless, I made the decision to invest because of the utility I gain from the anti-censorship, privacy, control, store of value, and security aspects of bitcoin -- many of which stem from decentralization, which others have demonstrated to be linked to the block size. >> >> On the other hand, there are undoubtedly other market participants who heard hype about "zero fee transactions to anywhere in the world", believed it would scale, and made (mal)investments as a result. >> >> As for how many market participants of each flavor, and how deep their respective pockets, who knows? My experience in markets has lead me to realize that it's never wise to assume I know what "the market" does and doesn't know. If Jeff Garzik is right about what the market has priced in, then yes, filled blocks will be rocking the boat. But who's to say that the smartest, biggest investors and traders don't already see this scaling problem, and have already priced it in? In this case, a sudden large increase in the block size is actually rocking the boat. The point is, you can't know either way, so trying to pre-empt the market in this way is erroneous. >> >> Regarding entrepreneurial investment specifically, why should we favor the entrepreneurs who require a more centralized bitcoin over those who were more considerate of the possibility of rising transaction fees when making their business models? >> >> In my mind, we should favor neither, which is why I'm basically in agreement with Pieter that this sense of "emergency" shouldn't really be a part of the debate. >> >> Not that I'm taking a stand on the specific block size issue either way. I just think this particular line of reasoning (presupposing what information the market has and has not already baked in) is unsound. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 842 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 2:18 ` Eric Lombrozo 2015-06-27 2:54 ` Eric Lombrozo @ 2015-06-27 8:16 ` Venzen Khaosan 1 sibling, 0 replies; 61+ messages in thread From: Venzen Khaosan @ 2015-06-27 8:16 UTC (permalink / raw) To: Eric Lombrozo, bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, Eric, blockchains are a means of mathematically determining consensus among those who use them. The application goes beyond value token into the realm of vote and deterministic politics. Eventually, blockchains will allows citizens to choose state projects and to contribute taxes according to their ability, and to benefit according to their need. Economic Participants The dichotomy of the mining operator as an economic class on one hand and the user as a dependent on the other is based on the current Keynesian model of economics that views the centralized as inevitable and the citizen as a consumer to be enlisted into spending at every opportunity. Schools of Thought Although not a definitive answer, the Austrian School of Economics illustrates that the Keynesian model (which we all harbor to some degree, thanks to its global hegemony) is fundamentally flawed: https://www.youtube.com/watch?v=SLfnpwHu4Hw (Of all the resources available, this speaker is most succinct, although I cannot vouch for his degree of Frankfurt School compliance or potential Zionist leanings - the account conforms to academic agreement of what the Austrian School of Economics stands for). Developers are, by necessity, making economic decisions If the developers will seize this moment of having to make economic decisions about how Bitcoin will be influenced and grow according to market dynamics, they should make an informed decision (only the developers can make the decision at this time), they should strive to make a well-informed decision - not some fumbled "hurry-the-blocksize-is-running-out" decision. Pieter Wuille argues the point convincingly in his initial post. Fulcrum The fundamental question to be answered here is: Do developers want to compete with existing payment networks, or do developers want to define Bitcoin's network in its own right? If Bitcoin must compete and win, then centralize it and it will soon beat the competition on every metric. If Bitcoin is its own beast, then users and finance capital must adapt to its constraints, for the benefit of all involved. Developers have a crucial role to play in implementing economic policy. It's not self-evident: a multinational or government sponsored entity mining this blockchain with the purpose of dominating it does not mean you have done your job of surrendering Bitcoin to the "free market". The decision rests on your informed understanding of economics (and myths about economics) and choosing the way that liberates Bitcoin and its users, and does not co-opt them into a system that seeks to devour competition. Talk about making Bitcoin more compliant to finance capital business is counter-Bitcoin and speakers harboring this opinion have come to dominate discussion here. If increased business and user adoption truly increased value, you would see it in the price chart. What has ignorant, fashion-prone mainstreet adoption done for Bitcoin? Will it really do something else, as some posters claim, or will it do more of the same? Venzen Khaosan On 06/27/2015 09:18 AM, Eric Lombrozo wrote: > I’ve been pondering this whole scale issue considerably…and am left > with the conclusion that blockchains are ultimately dispute > resolution mechanisms. The vast majority of crypto negotiation will > be taking place at levels lesser than global consensus in the > future - global consensus is just far too expensive to require for > every single cappuccino. There really is little need to take most > cases globally…unless the participants disagree. I’ve commented in > other places that blockchains are essentially a “fix” to the > prisoner’s dilemma - they make cooperation the equilibrium > strategy. > > Regardless of whatever linear factor we scale the blockchain by, it > is simple math to see that any exponential growth (even if for a > short time) in usage will overwhelm the current network. If we ever > intend to take bitcoin mainstream, we will most likely experience > at least a short time of exponential growth…at least until we > either reach an inherent limitation or until we saturate. As Pieter > said earlier, FAPP right now the demand for payments might as well > be infinite. We’re nowhere near the ability to service it all. > > The block size issue is really a usability issue at this point. > There are two fundamental things we need to solve: > > 1) There’s no model for how we’ll introduce a fee market, even > though the design of Bitcoin fundamentally depends on fees for its > survival (at least in the current form of the design.) > > 2) There’s no mechanism for how to perform fee bidding and > estimation. Most wallets simply have no way to do this without > serious usability problems. > > > > If we’re going to talk about block fees, let’s keep it in the > context of these relevant issues and not confound it with the > scalability issue…these are two very different issues. > > > - Eric Lombrozo > > >> On Jun 26, 2015, at 1:44 PM, Owen Gunden <ogunden@phauna.org> >> wrote: >> >> On 06/26/2015 02:23 PM, Jeff Garzik wrote: >>> Failure to plan now for a hard fork increase 6(?) months in the >>> future produces that lumpy, unpredictable market behavior. >>> >>> The market has baked in the years-long behavior of low fees. >>> From the market PoV, inaction does lead to precisely that, a >>> sudden change over the span of a few months. >> >> Which market participants are you referring to? >> >> I entered the bitcoin market with open eyes, aware that it faces >> hard scalability challenges by design. I was also aware that >> because of these challenges, eventually transaction fees would >> have to rise. >> >> Nevertheless, I made the decision to invest because of the >> utility I gain from the anti-censorship, privacy, control, store >> of value, and security aspects of bitcoin -- many of which stem >> from decentralization, which others have demonstrated to be >> linked to the block size. >> >> On the other hand, there are undoubtedly other market >> participants who heard hype about "zero fee transactions to >> anywhere in the world", believed it would scale, and made >> (mal)investments as a result. >> >> As for how many market participants of each flavor, and how deep >> their respective pockets, who knows? My experience in markets has >> lead me to realize that it's never wise to assume I know what >> "the market" does and doesn't know. If Jeff Garzik is right about >> what the market has priced in, then yes, filled blocks will be >> rocking the boat. But who's to say that the smartest, biggest >> investors and traders don't already see this scaling problem, and >> have already priced it in? In this case, a sudden large increase >> in the block size is actually rocking the boat. The point is, you >> can't know either way, so trying to pre-empt the market in this >> way is erroneous. >> >> Regarding entrepreneurial investment specifically, why should we >> favor the entrepreneurs who require a more centralized bitcoin >> over those who were more considerate of the possibility of rising >> transaction fees when making their business models? >> >> In my mind, we should favor neither, which is why I'm basically >> in agreement with Pieter that this sense of "emergency" shouldn't >> really be a part of the debate. >> >> Not that I'm taking a stand on the specific block size issue >> either way. I just think this particular line of reasoning >> (presupposing what information the market has and has not already >> baked in) is unsound. >> _______________________________________________ bitcoin-dev >> mailing list bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVjlvYAAoJEGwAhlQc8H1malgH/jKkN27KpNecMQPcSZ+RX/s8 UDIvrqIsNesWUtwnWk1/2WcaoDA8V9ho42VPXmDgGh0GTmYKzKnBUuKPeIBfe1z+ XCtG7OeWRAlo+1Zk+dT8Crv/PEHocpy7q2OFW2iOapWfTEYO/1FTA58RYMYSmKXQ 0snm3QhVIdJA3/3BE12616y0+Oo2aV3H9El6buqQVge/26Z8X8TLIsY5h8dQbTBF +J9Kq1YdJc8ogANZBpZfZBnURmNRsolyvQ+Sb5SxnpPQz73X3QPGaTyjnNsE0oVX Occxx6BREN/byoelIS5HMRsEYExmALIisXTiM1kysKzbcYp+ysB6Uzvyp1GzbFg= =PE+q -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 18:12 ` Pieter Wuille 2015-06-26 18:23 ` Jeff Garzik @ 2015-06-26 18:29 ` Alex Morcos 1 sibling, 0 replies; 61+ messages in thread From: Alex Morcos @ 2015-06-26 18:29 UTC (permalink / raw) To: Pieter Wuille; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 6977 bytes --] I think thats the crux of the issue: "some uses fit, some don't". I don't think anyone can claim to know which fall in which category for sure. But its clear that with the existing technology, achieving decentralization and lack of trusted third parties is expensive, therefore I think it does the world a disservice to pretend everyone can put their microtransactions on the block chain. More importantly, I don't think I'm worried about economic policy or change at all. I'm worried about decentralization. That's the piece we should be concentrating on. Sure a bitcoin with giant blocks could probably serve a bunch more use cases, but what value would it provide if there are 10 centralized miners and processing nodes running the network. We'll beat out Apple Pay or Paypal or Google at their game? Who cares. On Fri, Jun 26, 2015 at 2:12 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote: > I am not saying that economic change is what we want. Only that it is > inevitable, independent of whether larger blocks happen or not. > > I am saying that acting because of fear of economic change is a bad > reason. The reason for increase should be because of the higher utility. We > need it at some point, but there should be no rush. > > I do understand that we want to avoid a *sudden* change in economic > policy, but I'm generally not too worried. Either fees increase and they > get paid, and we're good. But more likely is that some uses just move > off-chain because the block chain does not offer what they need. That's > sad, but it is inevitable at any size: some uses fit, some don't. > > -- > Pieter > On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik@gmail.com> wrote: > >> It is not "fear" of fee pressure. >> >> 1) Blocks are mostly not-full on average. >> >> 2) Absent long blocks and stress tests, there is little fee pressure >> above the anti-spam relay fee metric, because of #1. >> >> 3) As such, inducing fee pressure is a delta, a change from years-long >> bitcoin economic policy. Each time we approach the soft limit, Bitcoin >> Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al. >> lobbies miners to upgrade. >> >> (note - this is not an endorsement of these actions - it is a neutral >> observation) >> >> 4) Inaction leads to consistent fee pressure as the months tick on and >> system volume grows; thus, inaction leads to economic policy change. >> >> 5) Economic policy change leads to market and software disruption. The >> market and software - notably wallets - is not prepared for this. >> >> 6) If you want to change economic policy, that's fine. But be honest and >> admit you are arguing for a change, a delta from current market >> expectations and behavior. >> >> 7) It is critical to first deal with what _is_, not what you wish the >> world to be. You want a fee market to develop. There is nothing wrong >> with that desire. It remains a delta from where we are today, and that is >> critically relevant in a $3b+ market. >> >> >> >> >> >> >> >> >> On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille@gmail.com> >> wrote: >> >>> Hello all, >>> >>> here I'm going to try to address a part of the block size debate which >>> has been troubling me since the beginning: the reason why people seem to >>> want it. >>> >>> People say that larger blocks are necessary. In the long term, I agree - >>> in the sense that systems that do not evolve tend to be replaced by other >>> systems. This evolution can come in terms of layers on top of Bitcoin's >>> blockchain, in terms of the technology underlying various aspects of the >>> blockchain itself, and also in the scale that this technology supports. >>> >>> I do, however, fundamentally disagree that a fear for a change in >>> economics should be considered to necessitate larger blocks. If it is, and >>> there is consensus that we should adapt to it, then there is effectively no >>> limit going forward. This is similar to how Congress voting to increase the >>> copyright term retroactively from time to time is really no different from >>> having an infinite copyright term in the first place. This scares me. >>> >>> Here is how Gavin summarizes the future without increasing block sizes >>> in PR 6341: >>> >>> > 1. Transaction confirmation times for transactions with a given fee >>> will rise; very-low-fee transactions will fail to get confirmed at all. >>> > 2. Average transaction fee paid will rise >>> > 3. People or applications unwilling or unable to pay the rising fees >>> will stop submitting transactions >>> > 4. People and businesses will shelve plans to use Bitcoin, stunting >>> growth and adoption >>> >>> Is it fair to summarize this as "Some use cases won't fit any more, >>> people will decide to no longer use the blockchain for these purposes, and >>> the fees will adapt."? >>> >>> I think that is already happening, and will happen at any scale. I >>> believe demand for payments in general is nearly infinite, and only a small >>> portion of it will eventually fit on a block chain (independent of whether >>> its size is limited by consensus rules or economic or technological means). >>> Furthermore, systems that compete with Bitcoin in this space already offer >>> orders of magnitude more capacity than we can reasonably achieve with any >>> blockchain technology at this point. >>> >>> I don't know what subset of use cases Bitcoin will cater to in the long >>> term. They have already changed - you see way less betting transactions >>> these days than a few years ago for example - and they will keep changing, >>> independent of what effective block sizes we end up with. I don't think we >>> should be afraid of this change or try to stop it. >>> >>> If you look at graphs of block sizes over time (for example, >>> http://rusty.ozlabs.org/?p=498), it seems to me that there is very >>> little "organic" growth, and a lot of sudden changes (which could >>> correspond to changing defaults in miner software, introduction of popular >>> sites/services, changes in the economy). I think these can be seen as the >>> economy changing to full up the available space, and I believe these will >>> keep happening at any size effectively available. >>> >>> None of this is a reason why the size can't increase. However, in my >>> opinion, we should do it because we believe it increases utility and >>> understand the risks; not because we're afraid of what might happen if we >>> don't hurry up. And from that point of view, it seems silly to make a huge >>> increase at once... >>> >>> -- >>> Pieter >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 9127 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-26 14:09 [bitcoin-dev] The need for larger blocks Pieter Wuille ` (3 preceding siblings ...) 2015-06-26 17:57 ` Jeff Garzik @ 2015-06-27 7:43 ` Wladimir J. van der Laan 2015-06-27 9:55 ` NxtChg 2015-06-27 10:13 ` Jorge Timón 4 siblings, 2 replies; 61+ messages in thread From: Wladimir J. van der Laan @ 2015-06-27 7:43 UTC (permalink / raw) To: Pieter Wuille; +Cc: bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Fri, Jun 26, 2015 at 04:09:18PM +0200, Pieter Wuille wrote: > People say that larger blocks are necessary. In the long term, I agree - in > the sense that systems that do not evolve tend to be replaced by other > systems. This evolution can come in terms of layers on top of Bitcoin's > blockchain, in terms of the technology underlying various aspects of the > blockchain itself, and also in the scale that this technology supports. > > I do, however, fundamentally disagree that a fear for a change in economics > should be considered to necessitate larger blocks. If it is, and there is > consensus that we should adapt to it, then there is effectively no limit > going forward. This is similar to how Congress voting to increase the > copyright term retroactively from time to time is really no different from > having an infinite copyright term in the first place. This scares me. Fully agree Pieter. Couldn't have stated it better. It has been disappointing and scary to see political pressure tactics being used to change a distributed consensus system. By using the system everyone agreed on one set of consensus rules, that was the "social contract" of Bitcoin. To me, the consensus rules are more like rules of physics than laws. They cannot be changed willy-nilly according to needs of some groups, much less than lower gravity can be legislated to help the airline industry. It is shocking to hear wide misunderstanding that it is supposedly 'the developers' that decide on such changes. As if this is merely a private top-down project. No, the point was that this can continue without any kind of central guidance, with expected stability. As a developer I work on improving the technical aspects and fixing bugs, not on 'governing' it. By expecting a few developers to make controversial decisions you are breaking the expectations, as well as making life dangerous for those developers. I'll jump ship before being forced to merge an even remotely controversial hardfork. The stressful conditions of last weeks have thus made me hostile toward the idea of hardforks. At least to hardforks that make politically loaded changes. In this case further centralization to well-connected geographic locales by increasing network bandwidth requirements. Resiliency and decentralization are the key aspects. I would not want to risk breaking the system, or at least wildly changing its properties and applicability out of perceived necessity, and fear. Wladimir -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJVjlOMAAoJEHSBCwEjRsmmveAH+wWN6j+0LsLibl2XWs3hxs64 nOT63JMNEIYzSsxZkEkzU4AWsdPG8TWXeaYhaR5rd7pXspFHHFYpPNxyOAWB4nY9 yS9eI4JRkOLtZY+rulFppkvnpggL82MFcT5rMNom+S1+EKE6C1NFqXl+OzZqatWL pysza7ZHg/d3hKWkm/JtlfTYTOgrxFIX6INghfQiOl2hEyXE5iZF8+CRnZQA4dG7 jr/Jn2H4EzkUF8SDYVkIYsX+hPL5ib9mMm12ZXH8M8lFkdwweJCwbA7tVtNoalG3 dzHb/8rotlqiDTNuLIlB7TE4maivcr2cXVKTfry6HBRJvNf0cD3oP67vCQj6iis= =pipo -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 7:43 ` Wladimir J. van der Laan @ 2015-06-27 9:55 ` NxtChg 2015-06-27 10:04 ` Wladimir J. van der Laan 2015-06-27 10:19 ` Venzen Khaosan 2015-06-27 10:13 ` Jorge Timón 1 sibling, 2 replies; 61+ messages in thread From: NxtChg @ 2015-06-27 9:55 UTC (permalink / raw) To: Wladimir J. van der Laan, Pieter Wuille; +Cc: bitcoin-dev On 6/27/2015 at 10:43 AM, "Wladimir J. van der Laan" <laanwj@gmail.com> wrote: > It has been disappointing and scary to see political pressure tactics being used to change a distributed consensus system. That's why some people are advocating formalizing the process. Political pressure will happen anyway, whether somebody likes it or not. It's better to deal with it in the open. > They cannot be changed willy-nilly according to needs of some groups, much less than lower gravity can be legislated to help the airline industry. Except the block size is not gravity. It's more like an arbitrary decision to limit planes' wingspan to the most typical hangar door of 1940. And now we have a "controversy" that we can't have modern planes out of the fear they won't fit into some of the old hangars. And to continue with this nice example, some people are even arguing that "the demand for flight is, essentially, limitless, so why bother making larger jets at all?" ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 9:55 ` NxtChg @ 2015-06-27 10:04 ` Wladimir J. van der Laan 2015-06-27 10:29 ` NxtChg 2015-06-27 10:19 ` Venzen Khaosan 1 sibling, 1 reply; 61+ messages in thread From: Wladimir J. van der Laan @ 2015-06-27 10:04 UTC (permalink / raw) To: NxtChg; +Cc: bitcoin-dev On Sat, Jun 27, 2015 at 12:55:01PM +0300, NxtChg wrote: > > > They cannot be changed willy-nilly according to needs of some groups, much less than lower gravity can be legislated to help the airline industry. > > Except the block size is not gravity. It's more like an arbitrary decision to limit planes' wingspan to the most typical hangar door of 1940. > > And now we have a "controversy" that we can't have modern planes out of the fear they won't fit into some of the old hangars. > > And to continue with this nice example, some people are even arguing that "the demand for flight is, essentially, limitless, so why bother making larger jets at all?" At least there's always an 'exit' option. At this point it would be more realistic to create a sidechain, or altcoin with larger blocks, and not experiment with the current one in-flight. Then you won't risk the other 'passengers' who don't consent to it. It's important to face reality instead of being wishful here. I'd also have preferred to have one happy family, but it is clear that is not the case, and pretending is only going to cause damage by creating false expectations, or eventually even double-spending possibility because of conflicting forks. Wladimir ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 10:04 ` Wladimir J. van der Laan @ 2015-06-27 10:29 ` NxtChg 2015-06-27 11:04 ` Jorge Timón 0 siblings, 1 reply; 61+ messages in thread From: NxtChg @ 2015-06-27 10:29 UTC (permalink / raw) To: Wladimir J. van der Laan; +Cc: bitcoin-dev On 6/27/2015 at 1:04 PM, "Wladimir J. van der Laan" <laanwj@gmail.com> wrote: > Then you won't risk the other 'passengers' who don't consent to it. But you can look at it the other way: what about risking the 'passengers' when the plane suddenly doesn't fly anymore? Increasing block limit increases the risk of centralization, but it also keeps the current status quo of blocks not being filled, rather then risking an unknown option of hitting the limit hard. >... and pretending is only going to cause damage by creating false expectations, or eventually even double-spending possibility because of conflicting forks. So you personally see the risks of a hard-fork outweigh the risks of not increasing the block size. It's a valid opinion, but you probably don't want to decide the fate of Bitcoin single-handedly by denying any change, which is not a technical emergency. That's why there should be a mechanism where the whole community can vote. Lacking that, that's what Gavin and Mike are doing: creating their own mechanism for consensus changes. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 10:29 ` NxtChg @ 2015-06-27 11:04 ` Jorge Timón 2015-06-27 11:18 ` Eric Lombrozo 2015-06-27 12:10 ` NxtChg 0 siblings, 2 replies; 61+ messages in thread From: Jorge Timón @ 2015-06-27 11:04 UTC (permalink / raw) To: NxtChg; +Cc: bitcoin-dev On Sat, Jun 27, 2015 at 12:29 PM, NxtChg <nxtchg@hush.com> wrote: > > On 6/27/2015 at 1:04 PM, "Wladimir J. van der Laan" <laanwj@gmail.com> wrote: > >> Then you won't risk the other 'passengers' who don't consent to it. > > But you can look at it the other way: what about risking the 'passengers' when the plane suddenly doesn't fly anymore? > > Increasing block limit increases the risk of centralization, but it also keeps the current status quo of blocks not being filled, rather then risking an unknown option of hitting the limit hard. But that option is not unknown, that's the point of this thread. "Doing nothing" would require to fix the mempool to scale with the number of unconfirmed transaction. This is something that we will eventually have to fix unless the plan is to eventually remove the blocksize limit. What will happen with full blocks is that fees will likely rise and the transactions with bigger fees will get confirmed first. This is something that will eventually happen unless the blocksize limit is removed before ever being hit. What this thread is saying is that this option (the so-called "doing nothing" option, which actually requires more work than any of the current proposals for increasing the blocksize) is perfectly valid, which is in contradiction to a perceived "need to increase the blocksize limit soon". Increasing the block size is only an option, not a "need". And changing the consensus rules and forcing everybody to adapt their software to the changes is certainly not "maintaining the status quo", I'm getting tired of hearing that absurd notion. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 11:04 ` Jorge Timón @ 2015-06-27 11:18 ` Eric Lombrozo 2015-06-27 11:43 ` Jorge Timón 2015-06-27 12:10 ` NxtChg 1 sibling, 1 reply; 61+ messages in thread From: Eric Lombrozo @ 2015-06-27 11:18 UTC (permalink / raw) To: Jorge Timón; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2276 bytes --] The economic policy’s status quo has been to avoid fee pressure. But the consensus status quo obviously is not to have a hard fork. There’s clearly a contradiction between these two policies, which is a big part of the reason this issue has come to this point. These two policies are fundamentally at odds. - Eric Lombrozo > On Jun 27, 2015, at 4:04 AM, Jorge Timón <jtimon@jtimon.cc> wrote: > > On Sat, Jun 27, 2015 at 12:29 PM, NxtChg <nxtchg@hush.com> wrote: >> >> On 6/27/2015 at 1:04 PM, "Wladimir J. van der Laan" <laanwj@gmail.com> wrote: >> >>> Then you won't risk the other 'passengers' who don't consent to it. >> >> But you can look at it the other way: what about risking the 'passengers' when the plane suddenly doesn't fly anymore? >> >> Increasing block limit increases the risk of centralization, but it also keeps the current status quo of blocks not being filled, rather then risking an unknown option of hitting the limit hard. > > But that option is not unknown, that's the point of this thread. > "Doing nothing" would require to fix the mempool to scale with the > number of unconfirmed transaction. This is something that we will > eventually have to fix unless the plan is to eventually remove the > blocksize limit. > What will happen with full blocks is that fees will likely rise and > the transactions with bigger fees will get confirmed first. This is > something that will eventually happen unless the blocksize limit is > removed before ever being hit. > What this thread is saying is that this option (the so-called "doing > nothing" option, which actually requires more work than any of the > current proposals for increasing the blocksize) is perfectly valid, > which is in contradiction to a perceived "need to increase the > blocksize limit soon". Increasing the block size is only an option, > not a "need". And changing the consensus rules and forcing everybody > to adapt their software to the changes is certainly not "maintaining > the status quo", I'm getting tired of hearing that absurd notion. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 842 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 11:18 ` Eric Lombrozo @ 2015-06-27 11:43 ` Jorge Timón 0 siblings, 0 replies; 61+ messages in thread From: Jorge Timón @ 2015-06-27 11:43 UTC (permalink / raw) To: Eric Lombrozo; +Cc: bitcoin-dev On Sat, Jun 27, 2015 at 1:18 PM, Eric Lombrozo <elombrozo@gmail.com> wrote: > The economic policy’s status quo has been to avoid fee pressure. But the consensus status quo obviously is not to have a hard fork. > > There’s clearly a contradiction between these two policies, which is a big part of the reason this issue has come to this point. These two policies are fundamentally at odds. Ok, so then the decision is to either change a policy or change a consensus rule and then maintaining the status quo is simply not possible. Since per-node and per-wallet policies weren't universal anyway (nobody can be forced to run the standard policy), making some changes to the policy code of the different implementations that weren't prepared for the current consensus rules (that includes bitcoin core) seems orders of magnitude closer to "maintaining the status quo" than a hardfork. It's interesting to note that increasing the blocksize without fixing the underlying problems that make it a perceived "need" will leave the implementations unprepared for the new rules too (it is just unprepared for ANY block size limit, not specifically unprepared for 1MB blocks). So increasing the block size is actually the "lazy option" regardless of how the "doing nothing option" is perceived by many uninformed participants in the discussions. Then I guess by "maintaining the status quo" some people just mean "not fixing the known problems we have yet, leave it for later". Not only some people propose to delay solving this problems: they don't even want to be forced to fix them in 20 years! That...or they just want to remove the block size limit entirely forever, don't fear centralization, and are not being clear about it. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 11:04 ` Jorge Timón 2015-06-27 11:18 ` Eric Lombrozo @ 2015-06-27 12:10 ` NxtChg 2015-06-28 12:13 ` Jorge Timón 1 sibling, 1 reply; 61+ messages in thread From: NxtChg @ 2015-06-27 12:10 UTC (permalink / raw) To: Jorge Timón; +Cc: bitcoin-dev On 6/27/2015 at 2:04 PM, "Jorge Timón" <jtimon@jtimon.cc> wrote: >But that option is not unknown... It is, until it actually happens. Before that, anything is a speculation. That's why risk is attached to both "doing nothing" and "raising the limit". For example, there's another risk that a lot of people will be disappointed in a system that can't scale (or adapt to any significant changes, for that matter). Yes, there is the "exit" option, but that path would probably be a lot messier and unwarranted. Various people perceive these risks differently and there is no clear mechanism currently to somehow gauge what the majority wants. So it's tempting to just give up and say: let's do nothing. In this situation, doing a "software fork" seems like the only way to actually see how many people/interests are in favor of bigger blocks. (Whether the majority has a moral right to dictate the minority is a tough philosophical question, which should probably be left out of this discussion :) ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 12:10 ` NxtChg @ 2015-06-28 12:13 ` Jorge Timón 2015-06-28 13:51 ` Ivan Brightly 2015-06-28 15:28 ` s7r 0 siblings, 2 replies; 61+ messages in thread From: Jorge Timón @ 2015-06-28 12:13 UTC (permalink / raw) To: NxtChg; +Cc: bitcoin-dev On Sat, Jun 27, 2015 at 2:10 PM, NxtChg <nxtchg@hush.com> wrote: > > On 6/27/2015 at 2:04 PM, "Jorge Timón" <jtimon@jtimon.cc> wrote: > >>But that option is not unknown... > > It is, until it actually happens. Before that, anything is a speculation. That's why risk is attached to both "doing nothing" and "raising the limit". Fortunately we have a lower limit in the standard mining policy to see if the skies turn purple when we hit that limit like some people predict. > Various people perceive these risks differently and there is no clear mechanism currently to somehow gauge what the majority wants. So it's tempting to just give up and say: let's do nothing. > > In this situation, doing a "software fork" seems like the only way to actually see how many people/interests are in favor of bigger blocks. But this is NOT a way to see the majority of anything. I can run 1000 nodes, have you heard of sybil attacks? There's simply no decentralized way of voting that works. Otherwise we could vote on each block instead of using proof of work. Miners voting on size is also ridiculous since big miners have an incentive to completely remove the limit and make smaller miners unprofitable. > (Whether the majority has a moral right to dictate the minority is a tough philosophical question, which should probably be left out of this discussion :) No, this is very important. The majority has no right to dictate on the minority. If the majority of bitcoiners wanted demurrage (and we actually had a working method for "measuring majorities"), the minority would still say "these are not the rules we signed up for, go make freicoin as a separate chain". And that is very reasonable. If some people want a more centralized version of Bitcoin they can create an altcoin too. Doesn't dogecoin already have big blocks? ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-28 12:13 ` Jorge Timón @ 2015-06-28 13:51 ` Ivan Brightly 2015-06-28 14:13 ` Eric Lombrozo ` (2 more replies) 2015-06-28 15:28 ` s7r 1 sibling, 3 replies; 61+ messages in thread From: Ivan Brightly @ 2015-06-28 13:51 UTC (permalink / raw) To: Jorge Timón; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 937 bytes --] On Sun, Jun 28, 2015 at 8:13 AM, Jorge Timón <jtimon@jtimon.cc> wrote: > > No, this is very important. The majority has no right to dictate on > the minority. > While an interesting philosophical question, I don't think that this is accurate. First off, bitcoin doesn't imbue any 'rights' on individuals - it provides the choice of participating or not, nothing more. Secondly, from a technical perspective, how is it that the majority (or super-majority) are prevented from imposing their will? The best answer is that they are incentivized to not override a minority group since that reduces the inherent value in the system. However, presuming that the majority calculate that the reward for imposing a change is greater than the value lost in such disruption, I don't see how there would be any stopping this change. The longest chain with the greatest number of users valuing the token on that chain "wins". [-- Attachment #2: Type: text/html, Size: 1292 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-28 13:51 ` Ivan Brightly @ 2015-06-28 14:13 ` Eric Lombrozo 2015-06-28 14:16 ` Eric Lombrozo 2015-06-28 15:05 ` Jorge Timón 2 siblings, 0 replies; 61+ messages in thread From: Eric Lombrozo @ 2015-06-28 14:13 UTC (permalink / raw) To: Ivan Brightly; +Cc: bitcoin-dev [-- Attachment #1.1: Type: text/plain, Size: 1353 bytes --] Either one branch wins overwhelmingly in a relatively short period of time…or both branches lose, I think. - Eric > On Jun 28, 2015, at 6:51 AM, Ivan Brightly <ibrightly@gmail.com> wrote: > > On Sun, Jun 28, 2015 at 8:13 AM, Jorge Timón <jtimon@jtimon.cc <mailto:jtimon@jtimon.cc>> wrote: > > No, this is very important. The majority has no right to dictate on > the minority. > > While an interesting philosophical question, I don't think that this is accurate. First off, bitcoin doesn't imbue any 'rights' on individuals - it provides the choice of participating or not, nothing more. > > Secondly, from a technical perspective, how is it that the majority (or super-majority) are prevented from imposing their will? The best answer is that they are incentivized to not override a minority group since that reduces the inherent value in the system. However, presuming that the majority calculate that the reward for imposing a change is greater than the value lost in such disruption, I don't see how there would be any stopping this change. The longest chain with the greatest number of users valuing the token on that chain "wins". > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #1.2: Type: text/html, Size: 2387 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 842 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-28 13:51 ` Ivan Brightly 2015-06-28 14:13 ` Eric Lombrozo @ 2015-06-28 14:16 ` Eric Lombrozo 2015-06-28 14:22 ` Ivan Brightly 2015-06-28 15:05 ` Jorge Timón 2 siblings, 1 reply; 61+ messages in thread From: Eric Lombrozo @ 2015-06-28 14:16 UTC (permalink / raw) To: Ivan Brightly; +Cc: bitcoin-dev [-- Attachment #1.1: Type: text/plain, Size: 1438 bytes --] Furthermore, the actual way in which the conflict is resolved sets a precedent for how such disagreements are to be “resolved” in the future. So the means are also important to consider. - Eric > On Jun 28, 2015, at 6:51 AM, Ivan Brightly <ibrightly@gmail.com> wrote: > > On Sun, Jun 28, 2015 at 8:13 AM, Jorge Timón <jtimon@jtimon.cc <mailto:jtimon@jtimon.cc>> wrote: > > No, this is very important. The majority has no right to dictate on > the minority. > > While an interesting philosophical question, I don't think that this is accurate. First off, bitcoin doesn't imbue any 'rights' on individuals - it provides the choice of participating or not, nothing more. > > Secondly, from a technical perspective, how is it that the majority (or super-majority) are prevented from imposing their will? The best answer is that they are incentivized to not override a minority group since that reduces the inherent value in the system. However, presuming that the majority calculate that the reward for imposing a change is greater than the value lost in such disruption, I don't see how there would be any stopping this change. The longest chain with the greatest number of users valuing the token on that chain "wins". > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #1.2: Type: text/html, Size: 2521 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 842 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-28 14:16 ` Eric Lombrozo @ 2015-06-28 14:22 ` Ivan Brightly 0 siblings, 0 replies; 61+ messages in thread From: Ivan Brightly @ 2015-06-28 14:22 UTC (permalink / raw) To: Eric Lombrozo; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1840 bytes --] Agreed on both accounts. The main point is that there are no inherent rights built into bitcoin - just aligned economic interests enforced by agreed upon technical rules. The technical rules allow for a majority to dictate, while the economic interests may or may not support such a change. On Sun, Jun 28, 2015 at 10:16 AM, Eric Lombrozo <elombrozo@gmail.com> wrote: > Furthermore, the actual way in which the conflict is resolved sets a > precedent for how such disagreements are to be “resolved” in the future. > > So the means are also important to consider. > > - Eric > > On Jun 28, 2015, at 6:51 AM, Ivan Brightly <ibrightly@gmail.com> wrote: > > On Sun, Jun 28, 2015 at 8:13 AM, Jorge Timón <jtimon@jtimon.cc> wrote: > >> >> No, this is very important. The majority has no right to dictate on >> the minority. >> > > While an interesting philosophical question, I don't think that this is > accurate. First off, bitcoin doesn't imbue any 'rights' on individuals - > it provides the choice of participating or not, nothing more. > > Secondly, from a technical perspective, how is it that the majority (or > super-majority) are prevented from imposing their will? The best answer is > that they are incentivized to not override a minority group since that > reduces the inherent value in the system. However, presuming that the > majority calculate that the reward for imposing a change is greater than > the value lost in such disruption, I don't see how there would be any > stopping this change. The longest chain with the greatest number of users > valuing the token on that chain "wins". > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > [-- Attachment #2: Type: text/html, Size: 2835 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-28 13:51 ` Ivan Brightly 2015-06-28 14:13 ` Eric Lombrozo 2015-06-28 14:16 ` Eric Lombrozo @ 2015-06-28 15:05 ` Jorge Timón 2015-06-28 16:01 ` Ivan Brightly 2 siblings, 1 reply; 61+ messages in thread From: Jorge Timón @ 2015-06-28 15:05 UTC (permalink / raw) To: Ivan Brightly; +Cc: bitcoin-dev On Sun, Jun 28, 2015 at 3:51 PM, Ivan Brightly <ibrightly@gmail.com> wrote: > On Sun, Jun 28, 2015 at 8:13 AM, Jorge Timón <jtimon@jtimon.cc> wrote: >> >> >> No, this is very important. The majority has no right to dictate on >> the minority. > > > While an interesting philosophical question, I don't think that this is > accurate. First off, bitcoin doesn't imbue any 'rights' on individuals - it > provides the choice of participating or not, nothing more. I think you're not contradicting me: ff there's not rights built into the system, the majority has no "right to dictate" anything. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-28 15:05 ` Jorge Timón @ 2015-06-28 16:01 ` Ivan Brightly 0 siblings, 0 replies; 61+ messages in thread From: Ivan Brightly @ 2015-06-28 16:01 UTC (permalink / raw) To: Jorge Timón; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1219 bytes --] I don't think that rights are a pillar of how bitcoin works - rather I would say it's a matter of aligned incentives. The fact is that the majority technically *can* dictate through PoW and acceptance. The only reason that the majority would not chose this path is because there is greater economic value in consensus, whether perceived or realized. If bitcoin were about "doing the right thing" there wouldn't be a need for PoW since no individual would be incentivized to double spend. On Sun, Jun 28, 2015 at 11:05 AM, Jorge Timón <jtimon@jtimon.cc> wrote: > On Sun, Jun 28, 2015 at 3:51 PM, Ivan Brightly <ibrightly@gmail.com> > wrote: > > On Sun, Jun 28, 2015 at 8:13 AM, Jorge Timón <jtimon@jtimon.cc> wrote: > >> > >> > >> No, this is very important. The majority has no right to dictate on > >> the minority. > > > > > > While an interesting philosophical question, I don't think that this is > > accurate. First off, bitcoin doesn't imbue any 'rights' on individuals > - it > > provides the choice of participating or not, nothing more. > > I think you're not contradicting me: ff there's not rights built into > the system, the majority has no "right to dictate" anything. > [-- Attachment #2: Type: text/html, Size: 1695 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-28 12:13 ` Jorge Timón 2015-06-28 13:51 ` Ivan Brightly @ 2015-06-28 15:28 ` s7r 2015-06-28 15:45 ` Jorge Timón 1 sibling, 1 reply; 61+ messages in thread From: s7r @ 2015-06-28 15:28 UTC (permalink / raw) To: Jorge Timón, NxtChg; +Cc: bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 +1 for this Jorge. Agreed the majority should not be able to enforce rules over the minority. But if the majority will just leave and create an altcoin or whatever, this will leave the remaining minority with a less value (or even 0 value) product or service. By enforcing some rules agreed by the majority or supermajority, the minority will be dragged along and even so with rules they haven't signed up for, they will still have a product or service which is worth something. That is why we have to be very careful into deciding this. This debate is good, there are lots of valid points from smart people and I am happy to see there is so much interest in this project, and regardless if the blocksize hard cap will be changed or not I do hope, if a hardfork will happen, it will also include a smart change that will allow future changes (requiring hardforks) simpler, with less headache and risks involved. On 6/28/2015 3:13 PM, Jorge Timón wrote: > On Sat, Jun 27, 2015 at 2:10 PM, NxtChg <nxtchg@hush.com> wrote: >> >> On 6/27/2015 at 2:04 PM, "Jorge Timón" <jtimon@jtimon.cc> wrote: >> >>> But that option is not unknown... >> >> It is, until it actually happens. Before that, anything is a >> speculation. That's why risk is attached to both "doing nothing" >> and "raising the limit". > > Fortunately we have a lower limit in the standard mining policy to > see if the skies turn purple when we hit that limit like some > people predict. > >> Various people perceive these risks differently and there is no >> clear mechanism currently to somehow gauge what the majority >> wants. So it's tempting to just give up and say: let's do >> nothing. >> >> In this situation, doing a "software fork" seems like the only >> way to actually see how many people/interests are in favor of >> bigger blocks. > > But this is NOT a way to see the majority of anything. I can run > 1000 nodes, have you heard of sybil attacks? There's simply no > decentralized way of voting that works. Otherwise we could vote on > each block instead of using proof of work. Miners voting on size is > also ridiculous since big miners have an incentive to completely > remove the limit and make smaller miners unprofitable. > >> (Whether the majority has a moral right to dictate the minority >> is a tough philosophical question, which should probably be left >> out of this discussion :) > > No, this is very important. The majority has no right to dictate > on the minority. If the majority of bitcoiners wanted demurrage > (and we actually had a working method for "measuring majorities"), > the minority would still say "these are not the rules we signed up > for, go make freicoin as a separate chain". And that is very > reasonable. If some people want a more centralized version of > Bitcoin they can create an altcoin too. Doesn't dogecoin already > have big blocks? _______________________________________________ > bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJVkBKpAAoJEIN/pSyBJlsR4FMIAITS10rtx4Uw20WjFPkWZRB3 ucRRPncXkKehQlFd9cY6sgPAUk50rM0FSpm69Ra1KnawNLLxkgpzTGZk1iTHbGe8 JlWoTduLOyvInVXCdM8l71TVWoyt8rDZpg1KAsaMmMi9UvstHZPGZp85XScxhYyC uBHv1Hm7oeszPBkjGsB9B9mF/gH8naCjcNva+XbcgsKNM681xbOeJQ9qW0GOwq+Z j4ocY77G8AENZkhCy2KKiJrz0ZBVDbnJAos06uKrdxhUPBwliVpyJW96aFsRp/sL SNqTkpSmvxgSUBHCrRoWiBf/xo06W9QeoEfoROfgFkSTcUlPWqCJHxqwOLk2VrY= =eUgF -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-28 15:28 ` s7r @ 2015-06-28 15:45 ` Jorge Timón 0 siblings, 0 replies; 61+ messages in thread From: Jorge Timón @ 2015-06-28 15:45 UTC (permalink / raw) To: s7r; +Cc: bitcoin-dev On Sun, Jun 28, 2015 at 5:28 PM, s7r <s7r@sky-ip.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > +1 for this Jorge. > Agreed the majority should not be able to enforce rules over the > minority. But if the majority will just leave and create an altcoin or > whatever, this will leave the remaining minority with a less value (or > even 0 value) product or service. By enforcing some rules agreed by > the majority or supermajority, the minority will be dragged along and > even so with rules they haven't signed up for, they will still have a > product or service which is worth something. If the Schism fork goes wrong (ie 2 chains coexist in parallel for long) the result may as well be that NOBODY will be left any value. Both the majority and the minority can lose simultaneusly. See https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#schism1-hardforks That kind of hardfork is basically like forcing the users to go to war against each other. Really, I don't think civil war is an exaggerated analogy. > That is why we have to be very careful into deciding this. > > This debate is good, there are lots of valid points from smart people > and I am happy to see there is so much interest in this project, and > regardless if the blocksize hard cap will be changed or not I do hope, > if a hardfork will happen, it will also include a smart change that > will allow future changes (requiring hardforks) simpler, with less > headache and risks involved. That sounds great. Do you have any proposal in mind? I really want hardforks to be made, I just don't want to kill the system attempting it. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 9:55 ` NxtChg 2015-06-27 10:04 ` Wladimir J. van der Laan @ 2015-06-27 10:19 ` Venzen Khaosan 2015-06-27 19:55 ` Aaron Voisine 1 sibling, 1 reply; 61+ messages in thread From: Venzen Khaosan @ 2015-06-27 10:19 UTC (permalink / raw) To: NxtChg, bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Advocations of "formalizing the process" may have a good outcome, but that is not the issue in the current dilemma. The present process is good enough. And that's as much as we can hope for. The issue is: does Bitcoin need to scale to business or does business need to scale to Bitcoin. Business is not the Holy Spirit that fills Bitcoin with utility. Bitcoin already has utility and finance capital would like to ride that utility for its own profit motive. Some posters, here in this list, would like to accelerate that process and they justify their argument with the assumption that greater adoption equals greater utility and value (and price). That is a false assumption. Given the increased adoption of Bitcoin by users and businesses during the past year, does the price chart reflect greater value or price? Of course not, the price chart is at terminal lows. Fact not fiction. It is a fiction of common "market wisdom" that greater adoption increases a commodity's value. Speculation plays with commodity value even when underlying fundamental value remains unchanged. China has verifiably been purchasing record amounts of Gold, but there is no effect in the price chart (or on Gold's objective value). Bitcoin's price chart will go up and down many times in the coming years as speculators play their game. It's independent of the underlying censorship resistance, mathematical consensus and transaction security of Bitcoin. Once the decentralization is sacrificed to big business then you can expect the final price chart low. Until then, let's hold our horses and maintain an even keel: Bitcoin is not trying to fit into the manic global economy's race toward the edge of a precipice - Bitcoin is the solution once its all gone wrong - - for ordinary users, not opportunistic bank-based business models such as JPMorgan, Pantera Capital or BTC-China. If you cannot see the inherent centralization problem with most so-called Bitcoin businesses you just haven't done your homework. On 06/27/2015 04:55 PM, NxtChg wrote: > > On 6/27/2015 at 10:43 AM, "Wladimir J. van der Laan" > <laanwj@gmail.com> wrote: > >> It has been disappointing and scary to see political pressure >> tactics being used to change a distributed consensus system. > > That's why some people are advocating formalizing the process. > Political pressure will happen anyway, whether somebody likes it or > not. It's better to deal with it in the open. > > >> They cannot be changed willy-nilly according to needs of some >> groups, much less than lower gravity can be legislated to help >> the airline industry. > > Except the block size is not gravity. It's more like an arbitrary > decision to limit planes' wingspan to the most typical hangar door > of 1940. > > And now we have a "controversy" that we can't have modern planes > out of the fear they won't fit into some of the old hangars. > > And to continue with this nice example, some people are even > arguing that "the demand for flight is, essentially, limitless, so > why bother making larger jets at all?" > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVjnjHAAoJEGwAhlQc8H1m7CMH/273H3C7tnL56jJZ6U9RMbSN dp2dPLusMJAvjWKiM/P5VjbcXnvARFuA3foIkzlxGdt2mvGlddW+b2x9YVZcDAZz k9V/IccOmVVEvIpfaP0Awe6H9H8+Gr1PpFWuaFExcem9T9bF6kVGV4o0g6EGzwVe rGJb0radm2qdWTKvUNvjXAF3kGRtoewFmTZBwyE6R6AxE7tvs/4Zvsf99+EQsD+o 3NZFlXX0gvPmaR7TWK0iOGlgns9MmKMm94xk8lHkESvW0NCMwTw6I0Pz74usPDte U0lWkZBoKFWkEuf6ChVOOoSdSbYFrOwa0uaiJtPWJB+9TiwZdZbDJumW3uqYG5M= =4vVg -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 10:19 ` Venzen Khaosan @ 2015-06-27 19:55 ` Aaron Voisine 2015-06-28 16:37 ` Venzen Khaosan 0 siblings, 1 reply; 61+ messages in thread From: Aaron Voisine @ 2015-06-27 19:55 UTC (permalink / raw) To: venzen; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 543 bytes --] On Sat, Jun 27, 2015 at 3:19 AM, Venzen Khaosan <venzen@mail.bihthai.net> wrote: > > That is a false assumption. Given the increased adoption of Bitcoin by > users and businesses during the past year, does the price chart > reflect greater value or price? Of course not, the price chart is at > terminal lows. Fact not fiction. > You're not taking speculative cycles into account. For most of 2013 the price was in the $100 range. Adoption as a store-of-value is what determines the price over the long term, as with any monetary commodity. [-- Attachment #2: Type: text/html, Size: 875 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 19:55 ` Aaron Voisine @ 2015-06-28 16:37 ` Venzen Khaosan 2015-06-28 20:56 ` Aaron Voisine 0 siblings, 1 reply; 61+ messages in thread From: Venzen Khaosan @ 2015-06-28 16:37 UTC (permalink / raw) To: Aaron Voisine; +Cc: bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/28/2015 02:55 AM, Aaron Voisine wrote: > On Sat, Jun 27, 2015 at 3:19 AM, Venzen Khaosan > <venzen@mail.bihthai.net <mailto:venzen@mail.bihthai.net>> wrote: > > > That is a false assumption. Given the increased adoption of Bitcoin > by users and businesses during the past year, does the price chart > reflect greater value or price? Of course not, the price chart is > at terminal lows. Fact not fiction. > > > You're not taking speculative cycles into account. For most of 2013 > the price was in the $100 range. Adoption as a store-of-value is > what determines the price over the long term, as with any monetary > commodity. Aaron, I am most definitely taking speculative cycles into account - I write Bitcoin market analysis reports on a daily basis. Since discussion is exploring notions of "value" and assumptions about "what increases value" I will post the following. You're correct to point to the speculative influence, since Bitcoin having the fundamentals it does, and being a commodity that floats freely in the market, without centralized control - plus being unregulated - it is a speculator's wildest dream come true. In this case its exchange value (to fiat) is based on social mood and perception and not on underlying (fundamental) value. I think that is what you imply, too. What is specifically relevant to the wider discussion, is your mention of *Commodity Money*, because the term accurately describes a major facet of Bitcoin's function and role. Bitcoin's exchange rate, as a commodity money floating freely in the market, will go up and down according to speculative cycles and we should conceptually separate its valuation in fiat terms, from its fundamental value which is: mathematical consensus, cryptographic transaction security and censorship resistance, etc. These values are critically reliant on Bitcoin's *degree of decentralization* for them to remain true and for Bitcoin to retain its meaning, and, therefore, its value. That is what I point out when I say "greater adoption has not reflected in the price chart". And that may remain the case for evermore because the value is in the protocol, the blockchain and its utility and degree of decentralization, not in the chart or the size of the user base (however, I'm by no means proposing that the user base be limited - only that it be grown with primary reference to the requirements imposed by decentralization). I argue that we already know what the value of Bitcoin is. In its current form Bitcoin most likely fulfills 80% or 90% of its eventual fully evolved value. Increased adoption will not strengthen the fundamentals, so let's proceed with scaling that will safeguard Bitcoin's fundamental value and implement protections that ensure quality of decentralization. Given the start of a new speculative cycle for Bitcoin and the possibility of a global liquidity crisis in the coming months or years, block utilization may increase more rapidly than suggested by current trends. Utilization may ramp up in a spike, so I agree with suggestions made here for starting tests of a larger blocksize (2-8MB), or for speeding up blocktime (whichever is technically preferred). Gavin Andresen has committed (if i recall correctly) to tests of 8MB blocks, so a different size test can be agreed by Core developers. Once test data and fork outcomes can be reviewed then decision making has actual parameters to proceed from. Venzen Khaosan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVkCK8AAoJEGwAhlQc8H1m7c0IAKBjj3QHhBh5cqDKrVDpPsfv GEdmjC4CVC+OCZR5TjJ71fsbx9s/9Yh1sglKPfKmInBbgUFeLuermpTnAC+GAEq9 rTPJgGKIIqax2vU9E8fLYrUC/uNk8wdB7PG50tQG+kOWATZOXWimy3Qi1hxOFLNI bWhRlwIW4tO9HTz6M1WLNyv6T1G7eaUGskW3xODgmr69/ISbG4f/uv7Yy1leEu+r 64hwrswBkvIWeLvPJ3lkuA862HZxbLRkoehEpH3ULTUQ3bDJ1kUkSzi9Z4rwOfHG p02hs69FVrfHckTtV7wQ4owHekiUT8hjob4V/3YrN0/qMGs4JmrxfyerfZ9GQ9o= =hc1s -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-28 16:37 ` Venzen Khaosan @ 2015-06-28 20:56 ` Aaron Voisine 0 siblings, 0 replies; 61+ messages in thread From: Aaron Voisine @ 2015-06-28 20:56 UTC (permalink / raw) To: venzen [-- Attachment #1: Type: text/plain, Size: 2736 bytes --] Moving the list to BCC, since this isn't really a technical discussion. On Sun, Jun 28, 2015 at 9:37 AM, Venzen Khaosan <venzen@mail.bihthai.net> wrote: > > Bitcoin's exchange rate, as a commodity money floating freely in the > market, will go up and down according to speculative cycles and we > should conceptually separate its valuation in fiat terms, from its > fundamental value which is: mathematical consensus, cryptographic > transaction security and censorship resistance, etc. I get the feeling we might be reasoning from different underlying assumptions, but I don't think you can separate value that way. Those fundamental properties were chosen to serve the goal of creating a digital commodity money. They are useful only in as much as they serve ends that people value. Consensus, security, censorship resistance are valuable because they are desirable properties for money to have. If you want to argue that the properties of bitcoin are valuable for other things besides money, that's fine, but those other uses presumably can be accomplished with tiny amounts of bitcoin, so don't appreciably increase demand. > These values are > critically reliant on Bitcoin's *degree of decentralization* for them > to remain true and for Bitcoin to retain its meaning, and, therefore, > its value. That is what I point out when I say "greater adoption has > not reflected in the price chart". And that may remain the case for > evermore because the value is in the protocol, the blockchain and its > utility and degree of decentralization, not in the chart or the size > of the user base > I think it depends on what you mean by "adoption". Adoption as a store-of-value must necessarily increase the market price given the restricted and eventually fixed supply. If we're talking about merchant adoption as a payment system, or increased transaction volume, the yes, these things have no direct impact on the price. They only impact the price indirectly in as much as they encourage further adoption as a store-of-value. > I argue that we already know what the value of Bitcoin is. In its > current form Bitcoin most likely fulfills 80% or 90% of its eventual > fully evolved value. Increased adoption will not strengthen the > fundamentals, so let's proceed with scaling that will safeguard > Bitcoin's fundamental value and implement protections that ensure > quality of decentralization. > Increased adoption does strengthen the fundamentals. The most important fundamental for money is how many other people standardize on the same money, and want to hold it. This drives it's price in terms of other commodities. You want to hold what everyone else wants to hold. Aaron Voisine co-founder and CEO breadwallet.com [-- Attachment #2: Type: text/html, Size: 3790 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 7:43 ` Wladimir J. van der Laan 2015-06-27 9:55 ` NxtChg @ 2015-06-27 10:13 ` Jorge Timón 2015-06-27 12:09 ` Wladimir J. van der Laan 1 sibling, 1 reply; 61+ messages in thread From: Jorge Timón @ 2015-06-27 10:13 UTC (permalink / raw) To: Wladimir J. van der Laan; +Cc: bitcoin-dev On Sat, Jun 27, 2015 at 9:43 AM, Wladimir J. van der Laan <laanwj@gmail.com> wrote: > By expecting a few developers to make controversial decisions you are breaking the expectations, as well as making life dangerous for those developers. I'll jump ship before being forced to merge an even remotely controversial hardfork. Obviously those who claim that you or "committers" or "developers" are in control of the consensus rules are far from understanding this life-threatening part. If you, Gavin or anyone becomes "the president of bitcoin" he will likely get killed, or kidnapped, or get his family kidnapped, or tortured... > The stressful conditions of last weeks have thus made me hostile toward the idea of hardforks. At least to hardforks that make politically loaded changes. I fully agree with what you've said but there's an argument I sympathize with: "hardforks must be possible". Otherwise it seems that the system is "eventually obsolete by design". Provided they're also uncontroversial, they don't need to be that different (in terms of deployment) from softforks. Since they risks are bigger you just need to give more time for users and alternative software to upgrade. I would really like deploying an uncontroversial hardfork to prove nobody wants them to be impossible, as explained in: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html I hear people claiming that "hardforks must be possible" here and there, see this example: http://www.reddit.com/r/Bitcoin/comments/3awomg/how_the_bitcoin_experiment_might_fail/csgonlm > Wladimir > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBCgAGBQJVjlOMAAoJEHSBCwEjRsmmveAH+wWN6j+0LsLibl2XWs3hxs64 > nOT63JMNEIYzSsxZkEkzU4AWsdPG8TWXeaYhaR5rd7pXspFHHFYpPNxyOAWB4nY9 > yS9eI4JRkOLtZY+rulFppkvnpggL82MFcT5rMNom+S1+EKE6C1NFqXl+OzZqatWL > pysza7ZHg/d3hKWkm/JtlfTYTOgrxFIX6INghfQiOl2hEyXE5iZF8+CRnZQA4dG7 > jr/Jn2H4EzkUF8SDYVkIYsX+hPL5ib9mMm12ZXH8M8lFkdwweJCwbA7tVtNoalG3 > dzHb/8rotlqiDTNuLIlB7TE4maivcr2cXVKTfry6HBRJvNf0cD3oP67vCQj6iis= > =pipo > -----END PGP SIGNATURE----- > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 10:13 ` Jorge Timón @ 2015-06-27 12:09 ` Wladimir J. van der Laan 2015-06-27 12:15 ` NxtChg 2015-06-28 12:03 ` Jorge Timón 0 siblings, 2 replies; 61+ messages in thread From: Wladimir J. van der Laan @ 2015-06-27 12:09 UTC (permalink / raw) To: Jorge Timón; +Cc: bitcoin-dev Jorge, > Provided they're also uncontroversial, they don't need to be that > different (in terms of deployment) from softforks. Since they risks > are bigger you just need to give more time for users and alternative > software to upgrade. Sure, most extreme: if secp256k1 or SHA256 starts to show chinks in its armor, or practical quantum computing is getting powerful enough to factor discrete logarithms of those sizes, I don't doubt everyone would go along with a proposal to add new crypto algos. I do expect there are other possible hardforks that are uncontroversial. Either - minor issues (maybe solving the time-warp issue with mining) issues planned on the long term - features that are not politically loaded, on the long term - major emergencies (anything that is clearly an 'exploit' with regard to coin holders or miners) Not sure though. The only way to find out is to propose them and see. Maybe wait a bit until things have cooled down... Note that anything non-critical and non-controversial can be planned and time-locked, say, 5 years ahead, obliviating the need for anyone to quickly upgrade their client. Wladimir ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 12:09 ` Wladimir J. van der Laan @ 2015-06-27 12:15 ` NxtChg 2015-06-27 12:17 ` Greg Sanders 2015-06-27 12:25 ` Wladimir J. van der Laan 2015-06-28 12:03 ` Jorge Timón 1 sibling, 2 replies; 61+ messages in thread From: NxtChg @ 2015-06-27 12:15 UTC (permalink / raw) To: Wladimir J. van der Laan; +Cc: bitcoin-dev On 6/27/2015 at 3:09 PM, "Wladimir J. van der Laan" <laanwj@gmail.com> wrote: >Not sure though. The only way to find out is to propose them and see. Maybe wait a bit until things have cooled down... And then we are again at the mercy of a single "decider" to judge whether something is controversial or not? It was pointed several times before that with enough loud minority you can make any change seem controversial. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 12:15 ` NxtChg @ 2015-06-27 12:17 ` Greg Sanders 2015-06-27 12:25 ` NxtChg 2015-06-27 12:25 ` Wladimir J. van der Laan 1 sibling, 1 reply; 61+ messages in thread From: Greg Sanders @ 2015-06-27 12:17 UTC (permalink / raw) To: NxtChg; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 822 bytes --] https://en.wikipedia.org/wiki/I_know_it_when_I_see_it Can we agree n-1 dev Nacks would be a controversial hard fork? Greg On Sat, Jun 27, 2015 at 8:15 AM, NxtChg <nxtchg@hush.com> wrote: > > On 6/27/2015 at 3:09 PM, "Wladimir J. van der Laan" <laanwj@gmail.com> > wrote: > > >Not sure though. The only way to find out is to propose them and see. > Maybe wait a bit until things have cooled down... > > And then we are again at the mercy of a single "decider" to judge whether > something is controversial or not? > > It was pointed several times before that with enough loud minority you can > make any change seem controversial. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 1618 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 12:17 ` Greg Sanders @ 2015-06-27 12:25 ` NxtChg 2015-06-27 12:35 ` Greg Sanders 0 siblings, 1 reply; 61+ messages in thread From: NxtChg @ 2015-06-27 12:25 UTC (permalink / raw) To: Greg Sanders; +Cc: bitcoin-dev On 6/27/2015 at 3:18 PM, "Greg Sanders" <gsanders87@gmail.com> wrote: >Can we agree n-1 dev Nacks would be a controversial hard fork? That requires an assumption that all developers are perfectly representing the whole community. And no shady lobbying behind the scenes too. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 12:25 ` NxtChg @ 2015-06-27 12:35 ` Greg Sanders 0 siblings, 0 replies; 61+ messages in thread From: Greg Sanders @ 2015-06-27 12:35 UTC (permalink / raw) To: NxtChg; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 664 bytes --] >That requires an assumption that all developers are perfectly representing the whole community. I'll take that as a "no". But it's a strange bar to set: perfect representation of entire community. By that token, nobody can say anything is controversial if a different group is disagreeing. Greg On Sat, Jun 27, 2015 at 8:25 AM, NxtChg <nxtchg@hush.com> wrote: > > On 6/27/2015 at 3:18 PM, "Greg Sanders" <gsanders87@gmail.com> wrote: > > >Can we agree n-1 dev Nacks would be a controversial hard fork? > > That requires an assumption that all developers are perfectly representing > the whole community. > > And no shady lobbying behind the scenes too. > > > [-- Attachment #2: Type: text/html, Size: 1326 bytes --] ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 12:15 ` NxtChg 2015-06-27 12:17 ` Greg Sanders @ 2015-06-27 12:25 ` Wladimir J. van der Laan 2015-06-27 12:50 ` NxtChg 1 sibling, 1 reply; 61+ messages in thread From: Wladimir J. van der Laan @ 2015-06-27 12:25 UTC (permalink / raw) To: NxtChg; +Cc: bitcoin-dev > It was pointed several times before that with enough loud minority you can make any change seem controversial. Yes, absolutely. Pushing something through despite a loud miniority (certainly a well-informed one with valid reasons) is controversial. This is not about miniorities and majorities. The *entire network* needs to agree to switch to your new software. If there are months-long heated discussions on every possible forum that is a clear sign that your change is controversial. As Greg Sanders already says, we know one when we see one... Wladimir ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 12:25 ` Wladimir J. van der Laan @ 2015-06-27 12:50 ` NxtChg 2015-06-27 13:01 ` Wladimir J. van der Laan 0 siblings, 1 reply; 61+ messages in thread From: NxtChg @ 2015-06-27 12:50 UTC (permalink / raw) To: Wladimir J. van der Laan; +Cc: bitcoin-dev Greg, > But it's a strange bar to set: perfect representation of entire community. By that token, nobody can say anything is controversial if a different group is disagreeing. Sorry, for not being clear. I am not talking definitions here, of course you can call it "controversial" when you get N-1 NACK's! I object that it's enough evidence to deny any change (see below). For example, in case the interests of developers became misaligned with the interests of the community (you can't say it can't happen). Wladimir, >The *entire network* needs to agree to switch to your new software. Why the "entire network"? So if, say, 75% of everybody involved want some change and 25% don't, the majority can't have it? Well, I guess we're down to that philosophical question of whether majority can dictate minority or whether minority can be a roadblock to majority :) Probably no reason to discuss it further :) A "software fork" seems like an inevitable resolution for this. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 12:50 ` NxtChg @ 2015-06-27 13:01 ` Wladimir J. van der Laan 0 siblings, 0 replies; 61+ messages in thread From: Wladimir J. van der Laan @ 2015-06-27 13:01 UTC (permalink / raw) To: NxtChg; +Cc: bitcoin-dev On Sat, Jun 27, 2015 at 03:50:09PM +0300, NxtChg wrote: > >The *entire network* needs to agree to switch to your new software. > > Why the "entire network"? So if, say, 75% of everybody involved want some change and 25% don't, the majority can't have it? You can change your client, individually, to anything you want. You can also decide to switch along with a hypothetical percentage of others. Say, 75% of the users wants to confiscate the other 25% their coins. It is not without historical precedent. No matter what the split is, or what it is about, the overall result will be confusion and have much less value than when there was one consensus. It's not quite Mutually Assured Destruction, but it is a very bad position to be in for everyone. So I'd dare say it shouldn't happen. But I'm done arguing about this too. Wladimir ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [bitcoin-dev] The need for larger blocks 2015-06-27 12:09 ` Wladimir J. van der Laan 2015-06-27 12:15 ` NxtChg @ 2015-06-28 12:03 ` Jorge Timón 1 sibling, 0 replies; 61+ messages in thread From: Jorge Timón @ 2015-06-28 12:03 UTC (permalink / raw) To: Wladimir J. van der Laan; +Cc: bitcoin-dev On Sat, Jun 27, 2015 at 2:09 PM, Wladimir J. van der Laan <laanwj@gmail.com> wrote: > - minor issues (maybe solving the time-warp issue with mining) issues planned on the long term This. > Note that anything non-critical and non-controversial can be planned and time-locked, say, 5 years ahead, obliviating the need for anyone to quickly upgrade their client. Yes, I specificalyl say that here https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#code (just with 4 years instead of 5). ^ permalink raw reply [flat|nested] 61+ messages in thread
end of thread, other threads:[~2015-06-28 20:56 UTC | newest] Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-26 14:09 [bitcoin-dev] The need for larger blocks Pieter Wuille 2015-06-26 14:38 ` Venzen Khaosan 2015-06-26 15:22 ` Milly Bitcoin 2015-06-26 15:24 ` Pieter Wuille 2015-06-26 18:05 ` Jeff Garzik 2015-06-26 18:32 ` Milly Bitcoin 2015-06-26 15:38 ` Tom Harding 2015-06-26 16:22 ` Venzen Khaosan 2015-06-26 17:04 ` Tom Harding 2015-06-26 17:55 ` Gavin Andresen 2015-06-26 17:57 ` Jeff Garzik 2015-06-26 18:12 ` Pieter Wuille 2015-06-26 18:23 ` Jeff Garzik 2015-06-26 18:31 ` Mark Friedenbach 2015-06-26 19:05 ` Aaron Voisine 2015-06-26 18:34 ` Pieter Wuille 2015-06-26 19:18 ` Ross Nicoll 2015-06-26 19:36 ` Peter Todd 2015-06-27 6:13 ` Filipe Farinha 2015-06-27 7:14 ` Aaron Voisine 2015-06-27 15:13 ` Peter Todd 2015-06-27 19:40 ` Aaron Voisine 2015-06-26 18:47 ` Patrick Strateman 2015-06-26 19:03 ` Tier Nolan 2015-06-26 19:12 ` Mark Friedenbach 2015-06-26 20:44 ` Owen Gunden 2015-06-27 2:18 ` Eric Lombrozo 2015-06-27 2:54 ` Eric Lombrozo 2015-06-27 8:16 ` Venzen Khaosan 2015-06-26 18:29 ` Alex Morcos 2015-06-27 7:43 ` Wladimir J. van der Laan 2015-06-27 9:55 ` NxtChg 2015-06-27 10:04 ` Wladimir J. van der Laan 2015-06-27 10:29 ` NxtChg 2015-06-27 11:04 ` Jorge Timón 2015-06-27 11:18 ` Eric Lombrozo 2015-06-27 11:43 ` Jorge Timón 2015-06-27 12:10 ` NxtChg 2015-06-28 12:13 ` Jorge Timón 2015-06-28 13:51 ` Ivan Brightly 2015-06-28 14:13 ` Eric Lombrozo 2015-06-28 14:16 ` Eric Lombrozo 2015-06-28 14:22 ` Ivan Brightly 2015-06-28 15:05 ` Jorge Timón 2015-06-28 16:01 ` Ivan Brightly 2015-06-28 15:28 ` s7r 2015-06-28 15:45 ` Jorge Timón 2015-06-27 10:19 ` Venzen Khaosan 2015-06-27 19:55 ` Aaron Voisine 2015-06-28 16:37 ` Venzen Khaosan 2015-06-28 20:56 ` Aaron Voisine 2015-06-27 10:13 ` Jorge Timón 2015-06-27 12:09 ` Wladimir J. van der Laan 2015-06-27 12:15 ` NxtChg 2015-06-27 12:17 ` Greg Sanders 2015-06-27 12:25 ` NxtChg 2015-06-27 12:35 ` Greg Sanders 2015-06-27 12:25 ` Wladimir J. van der Laan 2015-06-27 12:50 ` NxtChg 2015-06-27 13:01 ` Wladimir J. van der Laan 2015-06-28 12:03 ` Jorge Timón
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox