* [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 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 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 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: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 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: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 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: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 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 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: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 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-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-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 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-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 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 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: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 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 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: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: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: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: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 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-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 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
* 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 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-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-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
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