A summary list of all concerns related to not rising the block size

I believe all concerns I've read can be classified in the following groups:

> 1) Potential indirect consequence of rising fees.

- Lowest fee transactions (currently free transactions) will become more unreliable. - People will migrate to competing systems (PoW altcoins) with lower fees.

> 2) Software problem independent of a concrete block size that needs to
> be solved anyway, often specific to Bitcoin Core (ie other
> implementations, say libbitcoin may not necessarily share these
> problems).

- Bitcoin Core's mempool is unbounded in size and can make the program crash by using too much memory. - There's no good way to increase the fee of a transaction that is taking too long to be mined without the "double spending" transaction with the higher fee being blocked by most nodes which follow Bitcoin Core's default policy for conflicting spends replacements (aka "first seen" replacement policy).

I have started with the 3 concerns that I read more often, but please suggest more concerns for these categories and suggest other categories if you think there's more.

Jorge, you say 3 concerns at the end of your message but I only see 1) and 2). Assuming you've got a 3) and will add it, I'll contribute:

4) General, undefined fear that something bad is going to happen when nodes choke up on a backlog of transactions. - - no specific symptoms are pointed at but presumably there is "pre-traumatic stress" at play. - - Bitcoin-based businesses are going to lose money, customers and potentially fail - - people will flee Bitcoin for another cryptocoin and Bitcoin will be left in the corner, collecting dust and memories of it will fade as SuperCoin with its big blocks becomes all things to all people.

5) Specific belief that the exchange rate will decline on network unreliability - - traders and investors will bid the price down, or - - traders/investors will stop speculating all together because even if their speculation is successful, they're not sure they'll be able to get their bitcoin out of exchanges, what with the broken network and all. - - The exchange rate reflects Bitcoin's value and not just speculation guided by a few large players like in other markets.

6) Belief that Bitcoin's "cargo" is about to be delivered by fate: - - see https://en.wikipedia.org/wiki/Cargo_cult - - the cargo is variably presumed to be a range of hoped-for events: an adoption surge, a speculative rally similar to (or bigger than) 2013, or a global financial crisis that sees Bitcoin become the safe haven of choice. - - for the cargo to be delivered, a "runway" must be built - the larger the runway, the larger the cargo delivery. If the current runway is not expanded, then the cargo plane will go to a different island and won't come to Bitcoin Island. - - it is short-sighted and, in a way, ungrateful of the "generals" not to expand the runway - it will be their fault that the cargo doesn't get delivered and all the island's people, no the whole ocean's islands, will suffer because of silly security concerns. - - some people have taken the blueprints of the airbase and are building a large airstrip elsewhere on Bitcoin Island, but nobody is helping them build that long and wide runway. Everybody wants to expand this moderate runway - even the renegades who started Big Blocks Great Success airstrip. - - The sacred site of No-Middle-Zero-Attack-Point is at the start of the current runway. To expand it the site must be destroyed, but some former generals and many people say: It doesn't matter, we want Cargo, not a small attack surface. Just blast it!

On 08/12/2015 04:59 PM, Jorge Timón via bitcoin-dev wrote:

> I believe all concerns I've read can be classified in the following
> groups:
>
>> 1) Potential indirect consequence of rising fees.
>
> - Lowest fee transactions (currently free transactions) will
> become more unreliable. - People will migrate to competing systems
> (PoW altcoins) with lower fees.
>
>> 2) Software problem independent of a concrete block size that
>> needs to be solved anyway, often specific to Bitcoin Core (ie
>> other implementations, say libbitcoin may not necessarily share
>> these problems).
>
> - Bitcoin Core's mempool is unbounded in size and can make the
> program crash by using too much memory. - There's no good way to
> increase the fee of a transaction that is taking too long to be
> mined without the "double spending" transaction with the higher fee
> being blocked by most nodes which follow Bitcoin Core's default
> policy for conflicting spends replacements (aka "first seen"
> replacement policy).
>
> I have started with the 3 concerns that I read more often, but
> please suggest more concerns for these categories and suggest
> other categories if you think there's more.
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

On Wed, Aug 12, 2015 at 2:59 AM, Jorge Timón < bitcoin-dev@lists•linuxfoundation•org> wrote:

> I believe all concerns I've read can be classified in the following groups:
>
> > 1) Potential indirect consequence of rising fees.
>

I'd rephrase this as "Consequences of high fees." It's the level of fees that is the main issue, not their movement. Moving from 0 satoshi to 1 satoshi fees makes no real difference. Moving from $0 to $1 fees makes a huge difference. Some consequences are indirect, but others are not (the first three below are not indirect). Some of the consequences are uncertain, but others we can have very high confidence in (again: the first three) and it's only their effect size that can be reasonably disputed.

Here are lots of reasons that you're missing. High fees do the following:

-Reduce the utility of people using the network, even if the higher fees don't reduce their amount of transactions. -Make some use cases nonviable, depriving people of Bitcoin's decentralized benefits. -Makes level 2 infrastructure like Lightning less valuable by increasing the minimum value of anchor txns that make sense, and increasing the amount of pain suffered when your counterparty misbehaves. -Discourage experimentation with new Bitcoin use cases, making it more unlikely that such cases are discovered/improved/popular before Bitcoin's security relies on having many users. -Makes Bitcoin more vulnerable to regulation by keeping its user base from growing, meaning regulators face less pressure to keep it unregulated (see: Uber) -Reduce the amount of time we have between now and when tx fees need to pay for a significant portion of Bitcoin's security, by keeping the exchange rate and thus the value of block rewards low ( https://en.wikipedia.org/wiki/Equation_of_exchange) -By slowing usage growth, make it less likely that we have a large enough base of transactions by the time we need to fund network security via tx fees.

A concern I have is about security (hash rate) as a function of block size.

I am assuming that hash rate is correlated with revenue from mining.

Total revenue from fees as a function of block size should be a curve. On one extreme of the curve, if blocks are too big, fee revenue tends towards 0 as there is no competition for block space. At the other extreme, if blocks are too small, fee revenue is limited only to what the most valuable use case(s) can afford. Somewhere in the middle there should be a sweet spot where fee revenue is maximised. It's not a static curve though, it should change as demand for block space changes.

Failing to scale the block size as demand grows might be forfeiting potential miner revenue and hence security.

(I don't think that should be a primary concern though since decentralisation should come first, but I'm just pointing it out as a secondary concern).

On Wed, Aug 12, 2015 at 7:59 PM, Jorge Timón < bitcoin-dev@lists•linuxfoundation•org> wrote:

> I believe all concerns I've read can be classified in the following groups:
>
> > 1) Potential indirect consequence of rising fees.
>
> - Lowest fee transactions (currently free transactions) will become
> more unreliable.
> - People will migrate to competing systems (PoW altcoins) with lower fees.
>
> > 2) Software problem independent of a concrete block size that needs to
> > be solved anyway, often specific to Bitcoin Core (ie other
> > implementations, say libbitcoin may not necessarily share these
> > problems).
>
> - Bitcoin Core's mempool is unbounded in size and can make the program
> crash by using too much memory.
> - There's no good way to increase the fee of a transaction that is
> taking too long to be mined without the "double spending" transaction
> with the higher fee being blocked by most nodes which follow Bitcoin
> Core's default policy for conflicting spends replacements (aka "first
> seen" replacement policy).
>
> I have started with the 3 concerns that I read more often, but please
> suggest more concerns for these categories and suggest other
> categories if you think there's more.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> On Aug 13, 2015, at 2:52 AM, Ashley Holman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> A concern I have is about security (hash rate) as a function of block size.
>
> I am assuming that hash rate is correlated with revenue from mining.
>
> Total revenue from fees as a function of block size should be a curve.  On one extreme of the curve, if blocks are too big, fee revenue tends towards 0 as there is no competition for block space.

This isn’t necessarily true. Every miner has its own mining policy. If they choose to delay including transactions proportional to their fee + first seen, then you create a time based fee market. Want quick confirmation? Pay a high fee. Don’t care that much? Pay a low fee (and anywhere in between). This market would work just fine even if block capacity was unbounded.

jp

3) A few more people begin using bitcoin. Bitcoin buckles and dies.

- Something happens a few months from now causing an influx of new users and more transactions. - Blocks are constantly full. - A backlog of transactions keeps growing indefinitely. - At first people say "bitcoin is slow". After a while they say "bitcoin doesn't work". - Changing the hard limit on block size requires a fork and takes too long. - As bitcoin no longer works people stop using it. - Bitcoin lives out the last of its days in the backwaters of the internet with only 5 users. They keep telling people "we increased the block size now". Unfortunately noone is listening anymore. - People laugh at you and say "I told you that buttcoin thing was doomed to fail. After all it wasn't real money."

If the hard limit had been increased earlier then mining pools would have been able to react quickly by upping their own soft limit. But this was not the case and so ended Bitcoin.

So in summary:

By increasing the block size limit you run the risk of: - The transaction fee market takes a little longer to develop. By not increasing the limit you run the risk of: - Bitcoin dies. The end.

Transaction fees should not be the main topic of this discussion, and probably not even a part of it at all. That seems outright irresponsible to me.

Regards, Geir H. Hansen, Bitminter mining pool

On 12.08.2015 11:59, Jorge Timón via bitcoin-dev wrote:

> I believe all concerns I've read can be classified in the following groups:
>
>> 1) Potential indirect consequence of rising fees.
>
> - Lowest fee transactions (currently free transactions) will become
> more unreliable.
> - People will migrate to competing systems (PoW altcoins) with lower fees.
>
>> 2) Software problem independent of a concrete block size that needs to
>> be solved anyway, often specific to Bitcoin Core (ie other
>> implementations, say libbitcoin may not necessarily share these
>> problems).
>
> - Bitcoin Core's mempool is unbounded in size and can make the program
> crash by using too much memory.
> - There's no good way to increase the fee of a transaction that is
> taking too long to be mined without the "double spending" transaction
> with the higher fee being blocked by most nodes which follow Bitcoin
> Core's default policy for conflicting spends replacements (aka "first
> seen" replacement policy).
>
> I have started with the 3 concerns that I read more often, but please
> suggest more concerns for these categories and suggest other
> categories if you think there's more.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Geir,

In the scenario below, you argue that the current 1MB limit would lead to "constantly full" blocks. If the limit is increased to say 1.6GB then a government or banking group may choose to utilize 1.5GB of the capacity of each block (and pay fees or not) for their settlement network. Then how did upping the blocksize remedy anything? Or is this use-case not plausible?

I would like to ask you, or anyone on the list: when we say that mining secures the network, what does that mean?

On 08/14/2015 05:01 AM, Geir Harald Hansen via bitcoin-dev wrote:

> 3) A few more people begin using bitcoin. Bitcoin buckles and
> dies.
>
> - Something happens a few months from now causing an influx of new
> users and more transactions. - Blocks are constantly full. - A
> backlog of transactions keeps growing indefinitely. - At first
> people say "bitcoin is slow". After a while they say "bitcoin
> doesn't work". - Changing the hard limit on block size requires a
> fork and takes too long. - As bitcoin no longer works people stop
> using it. - Bitcoin lives out the last of its days in the
> backwaters of the internet with only 5 users. They keep telling
> people "we increased the block size now". Unfortunately noone is
> listening anymore. - People laugh at you and say "I told you that
> buttcoin thing was doomed to fail. After all it wasn't real
> money."
>
> If the hard limit had been increased earlier then mining pools
> would have been able to react quickly by upping their own soft
> limit. But this was not the case and so ended Bitcoin.
>
> So in summary:
>
> By increasing the block size limit you run the risk of: - The
> transaction fee market takes a little longer to develop. By not
> increasing the limit you run the risk of: - Bitcoin dies. The end.
>
> Transaction fees should not be the main topic of this discussion,
> and probably not even a part of it at all. That seems outright
> irresponsible to me.
>
> Regards, Geir H. Hansen, Bitminter mining pool
>
> On 12.08.2015 11:59, Jorge Timón via bitcoin-dev wrote:
>> I believe all concerns I've read can be classified in the
>> following groups:
>>
>>> 1) Potential indirect consequence of rising fees.
>>
>> - Lowest fee transactions (currently free transactions) will
>> become more unreliable. - People will migrate to competing
>> systems (PoW altcoins) with lower fees.
>>
>>> 2) Software problem independent of a concrete block size that
>>> needs to be solved anyway, often specific to Bitcoin Core (ie
>>> other implementations, say libbitcoin may not necessarily share
>>> these problems).
>>
>> - Bitcoin Core's mempool is unbounded in size and can make the
>> program crash by using too much memory. - There's no good way to
>> increase the fee of a transaction that is taking too long to be
>> mined without the "double spending" transaction with the higher
>> fee being blocked by most nodes which follow Bitcoin Core's
>> default policy for conflicting spends replacements (aka "first
>> seen" replacement policy).
>>
>> I have started with the 3 concerns that I read more often, but
>> please suggest more concerns for these categories and suggest
>> other categories if you think there's more.
>> _______________________________________________ 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
>

In that case it didn't remedy the problem of constantly full blocks, but got a ton of people on board the bitcoin train in the meanwhile. And with them more interest, investments, research and ideas.

In the case we increase the limit and no government or banking group immediately uses up all the space in blocks, it of course would prevent constantly full blocks for the time being. Bitcoin keeps working reliably, is fast and cheap -- more users on board the bitcoin train. And as long as we do not immediately increase it to 1.6GB (something no one is suggesting), we could still maintain a good level of decentralization, maybe even increase it together with an increase in users.

Eventually we'll have to deal with the fading subsidy, but there's no reason to deal with it at this point in time. What we need today is more users and artifically limiting the blocksize doesn't help with that. At the very least we should try to incorporate technological growth into bitcoin. Keep the 2010 1MB limit, but account for "inflation". If you're arguing that noone can predict the future development of bandwidth, cpu and storage I'd say it doesn't matter if we are too optimistic, because when we start seeing that a future doubling of the limit will cause major issues, it will be easy to find consensus and change the rule accordingly.

2015-08-14 4:26 GMT+02:00 Venzen Khaosan via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Geir,
>
> In the scenario below, you argue that the current 1MB limit would lead
> to "constantly full" blocks. If the limit is increased to say 1.6GB
> then a government or banking group may choose to utilize 1.5GB of the
> capacity of each block (and pay fees or not) for their settlement
> network. Then how did upping the blocksize remedy anything? Or is this
> use-case not plausible?
>
> I would like to ask you, or anyone on the list: when we say that
> mining secures the network, what does that mean?
>
>
>
> On 08/14/2015 05:01 AM, Geir Harald Hansen via bitcoin-dev wrote:
> > 3) A few more people begin using bitcoin. Bitcoin buckles and
> > dies.
> >
> > - Something happens a few months from now causing an influx of new
> > users and more transactions. - Blocks are constantly full. - A
> > backlog of transactions keeps growing indefinitely. - At first
> > people say "bitcoin is slow". After a while they say "bitcoin
> > doesn't work". - Changing the hard limit on block size requires a
> > fork and takes too long. - As bitcoin no longer works people stop
> > using it. - Bitcoin lives out the last of its days in the
> > backwaters of the internet with only 5 users. They keep telling
> > people "we increased the block size now". Unfortunately noone is
> > listening anymore. - People laugh at you and say "I told you that
> > buttcoin thing was doomed to fail. After all it wasn't real
> > money."
> >
> > If the hard limit had been increased earlier then mining pools
> > would have been able to react quickly by upping their own soft
> > limit. But this was not the case and so ended Bitcoin.
> >
> > So in summary:
> >
> > By increasing the block size limit you run the risk of: - The
> > transaction fee market takes a little longer to develop. By not
> > increasing the limit you run the risk of: - Bitcoin dies. The end.
> >
> > Transaction fees should not be the main topic of this discussion,
> > and probably not even a part of it at all. That seems outright
> > irresponsible to me.
> >
> > Regards, Geir H. Hansen, Bitminter mining pool
> >
> > On 12.08.2015 11:59, Jorge Timón via bitcoin-dev wrote:
> >> I believe all concerns I've read can be classified in the
> >> following groups:
> >>
> >>> 1) Potential indirect consequence of rising fees.
> >>
> >> - Lowest fee transactions (currently free transactions) will
> >> become more unreliable. - People will migrate to competing
> >> systems (PoW altcoins) with lower fees.
> >>
> >>> 2) Software problem independent of a concrete block size that
> >>> needs to be solved anyway, often specific to Bitcoin Core (ie
> >>> other implementations, say libbitcoin may not necessarily share
> >>> these problems).
> >>
> >> - Bitcoin Core's mempool is unbounded in size and can make the
> >> program crash by using too much memory. - There's no good way to
> >> increase the fee of a transaction that is taking too long to be
> >> mined without the "double spending" transaction with the higher
> >> fee being blocked by most nodes which follow Bitcoin Core's
> >> default policy for conflicting spends replacements (aka "first
> >> seen" replacement policy).
> >>
> >> I have started with the 3 concerns that I read more often, but
> >> please suggest more concerns for these categories and suggest
> >> other categories if you think there's more.
> >> _______________________________________________ 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
>
> iQEcBAEBAgAGBQJVzVHWAAoJEGwAhlQc8H1myaoH+QFo+eTqPqMps/h/Lt5P4Ker
> UIyCbouatdrRnKqJlpa+dy70+nK+nkz6fizXLC8fuWFDLPQ2uk1cUnp7FPcJ+f6L
> LdGiUktcF/osbA5DW/Xt1DQnClnfbR04oH3+l5ouwhTG2FL8018RQKTAZXYaQafE
> /GUzXBZt+dxpENE2ZE0YDORcm62cysFB8KiqS7NmrNC3sig/Bnw0k8x8y745LcSO
> j/icLJ/zlSVhtceb8AnSg5bC2xhKXrTsGQBfr4foDh78n0+xcbEQO/6xc29rydeB
> l8VwzqCwyFZScM/4lhgYHgEB2KE3MecGNy0vh7jKVqh9lQUMlWtpHRy/Nony5mA=
> =MEzL
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

On Friday 14. August 2015 09.26.33 Venzen Khaosan via bitcoin-dev wrote:

> In the scenario below, you argue that the current 1MB limit would lead
> to "constantly full" blocks. If the limit is increased to say 1.6GB
> then a government or banking group may choose to utilize 1.5GB of the
> capacity of each block (and pay fees or not) for their settlement
> network. Then how did upping the blocksize remedy anything? Or is this
> use-case not plausible?

Your usecase only makes sense if we assume that blocks are community property.

This is provably not the case, it has been proven with the recent spam attack, people could just continue sending their payments without issues by just increasing the fee a bit.

As such, the bigger blocks don't immediately get filled, it makes more space for everyone. People abusing it will also have to spend a lot more money (that goes to benefit the network as a whole) to disrupt it.

On Wed, Aug 12, 2015 at 1:21 PM, Venzen Khaosan <venzen@mail•bihthai•net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jorge, you say 3 concerns at the end of your message but I only see 1)
> and 2). Assuming you've got a 3) and will add it, I'll contribute:

No, sorry it's 2 concerns/risks with 2 sub-concerns/risks each:

1) Potential indirect consequence of rising fees.

1.1) Lowest fee transactions (currently free transactions) will become more unreliable. 1.2) People will migrate to competing systems (PoW altcoins) with lower fees.

2) Software problem independent of a concrete block size that needs to be solved anyway, often specific to Bitcoin Core (ie other implementations, say libbitcoin may not necessarily share these problems).

2.1) Bitcoin Core's mempool is unbounded in size and can make the program crash by using too much memory.

2.2) There's no good way to increase the fee of a transaction that is taking too long to be mined without the "double spending" transaction with the higher fee being blocked by most nodes which follow Bitcoin Core's default policy for conflicting spends replacements (aka "first seen" replacement policy).

> 4) General, undefined fear that something bad is going to happen when
> nodes choke up on a backlog of transactions.
> - - no specific symptoms are pointed at but presumably there is
> "pre-traumatic stress" at play.
> - - Bitcoin-based businesses are going to lose money, customers and
> potentially fail
> - - people will flee Bitcoin for another cryptocoin and Bitcoin will be
> left in the corner, collecting dust and memories of it will fade as
> SuperCoin with its big blocks becomes all things to all people.

I believe thisbelongs in 2, not really sure if 2.1 or 2.2 since it's related to both.

> 5) Specific belief that the exchange rate will decline on network
> unreliability
> - - traders and investors will bid the price down, or
> - - traders/investors will stop speculating all together because even if
> their speculation is successful, they're not sure they'll be able to
> get their bitcoin out of exchanges, what with the broken network and all.
> - - The exchange rate reflects Bitcoin's value and not just speculation
> guided by a few large players like in other markets.

I believe "fear of exchange rate declining" can probably be added to any concern/risk "leaf", so we should probably leave that for the end or just omit it.

> 6) Belief that Bitcoin's "cargo" is about to be delivered by fate:
> - - see https://en.wikipedia.org/wiki/Cargo_cult
> - - the cargo is variably presumed to be a range of hoped-for events: an
> adoption surge, a speculative rally similar to (or bigger than) 2013,
> or a global financial crisis that sees Bitcoin become the safe haven
> of choice.
> - - for the cargo to be delivered, a "runway" must be built - the larger
> the runway, the larger the cargo delivery. If the current runway is
> not expanded, then the cargo plane will go to a different island and
> won't come to Bitcoin Island.
> - - it is short-sighted and, in a way, ungrateful of the "generals" not
> to expand the runway - it will be their fault that the cargo doesn't
> get delivered and all the island's people, no the whole ocean's
> islands, will suffer because of silly security concerns.
> - - some people have taken the blueprints of the airbase and are
> building a large airstrip elsewhere on Bitcoin Island, but nobody is
> helping them build that long and wide runway. Everybody wants to
> expand this moderate runway - even the renegades who started Big
> Blocks Great Success airstrip.
> - - The sacred site of No-Middle-Zero-Attack-Point is at the start of
> the current runway. To expand it the site must be destroyed, but some
> former generals and many people say: It doesn't matter, we want Cargo,
> not a small attack surface. Just blast it!

I'm not sure I understood this but seems related to the exchange rate.

On Wed, Aug 12, 2015 at 9:52 PM, Elliot Olds <elliot.olds@gmail•com> wrote:

> On Wed, Aug 12, 2015 at 2:59 AM, Jorge Timón
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>> I believe all concerns I've read can be classified in the following
>> groups:
>>
>> > 1) Potential indirect consequence of rising fees.
>
>
> I'd rephrase this as "Consequences of high fees." It's the level of fees
> that is the main issue, not their movement.

I think potential is more general since it allows us to list uncertain consequences (aren't all consequences just projections and thus uncertain anyway?).

> Moving from 0 satoshi to 1 satoshi fees makes no real difference.

It is a big difference to me (it may mean policy code has improved a lot in the process). Anyway, I'm heppy to hear again that this is not a concern, at some point I thought this was the ONLY concern, so I was clearly misinterpreting people's arguments.

> Moving from $0 to $1 fees makes a
> huge difference. Some consequences are indirect, but others are not (the
> first three below are not indirect). Some of the consequences are uncertain,
> but others we can have very high confidence in (again: the first three) and
> it's only their effect size that can be reasonably disputed.

Let's list them all first and then identify which are more worrying in the short term.

> Here are lots of reasons that you're missing. High fees do the following:
>
> -Reduce the utility of people using the network, even if the higher fees
> don't reduce their amount of transactions.

"Utility" like "value" is always subjective and very vague. I prefer to identify more concrete ways in which "utility is reduced".

> -Make some use cases nonviable, depriving people of Bitcoin's decentralized
> benefits.

It is clear that not all use cases fit the blockchain, but it's still unclear which ones don't fit yet. But the amount of use cases supported is not a valid metric for decentralization. In any case, it would be interesting if we could list some concrete cases that would be lost.

> -Makes level 2 infrastructure like Lightning less valuable by increasing the
> minimum value of anchor txns that make sense, and increasing the amount of
> pain suffered when your counterparty misbehaves.

This is correct. Layer 2 can become more expensive in total as well (it doesn't mean layer 2 doesn't scale though). I wil add it as 1.3

> -Discourage experimentation with new Bitcoin use cases, making it more
> unlikely that such cases are discovered/improved/popular before Bitcoin's
> security relies on having many users.

Experimentation can be done with worthless testchains. I'm not sure I'm following on this one.

> -Makes Bitcoin more vulnerable to regulation by keeping its user base from
> growing, meaning regulators face less pressure to keep it unregulated (see:
> Uber)

Added:

1.4) Less users than we could have had with a bigger size 1.4.1) More regulation pressure

> -Reduce the amount of time we have between now and when tx fees need to pay
> for a significant portion of Bitcoin's security, by keeping the exchange
> rate and thus the value of block rewards low
> (https://en.wikipedia.org/wiki/Equation_of_exchange)

Related to exchange rate.

> -By slowing usage growth, make it less likely that we have a large enough
> base of transactions by the time we need to fund network security via tx
> fees.

Added:

1.4.2) Not enough fees when subsidy is lower

Resulting list:

1) Potential indirect consequence of rising fees.

1.1) Lowest fee transactions (currently free transactions) will become more unreliable. 1.2) People will migrate to competing systems (PoW altcoins) with lower fees. 1.3) Layer 2 settlements become more expensive 1.4) Less users than we could have had with a bigger size 1.4.1) More regulation pressure 1.4.2) Not enough fees when subsidy is lower

2) Software problem independent of a concrete block size that needs to be solved anyway, often specific to Bitcoin Core (ie other implementations, say libbitcoin may not necessarily share these problems).

2.1) Bitcoin Core's mempool is unbounded in size and can make the program crash by using too much memory.

2.2) There's no good way to increase the fee of a transaction that is taking too long to be mined without the "double spending" transaction with the higher fee being blocked by most nodes which follow Bitcoin Core's default policy for conflicting spends replacements (aka "first seen" replacement policy).

On Thu, Aug 13, 2015 at 11:52 AM, Ashley Holman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

> A concern I have is about security (hash rate) as a function of block size.
>
> I am assuming that hash rate is correlated with revenue from mining.
>
> Total revenue from fees as a function of block size should be a curve.  On
> one extreme of the curve, if blocks are too big, fee revenue tends towards 0
> as there is no competition for block space.  At the other extreme, if blocks
> are too small, fee revenue is limited only to what the most valuable use
> case(s) can afford.  Somewhere in the middle there should be a sweet spot
> where fee revenue is maximised.  It's not a static curve though, it should
> change as demand for block space changes.
>
> Failing to scale the block size as demand grows might be forfeiting
> potential miner revenue and hence security.
>
> (I don't think that should be a primary concern though since
> decentralisation should come first, but I'm just pointing it out as a
> secondary concern).

I believe your concerns are included in:

1) Potential indirect consequence of rising fees. [...] 1.4) Less users than we could have had with a bigger size 1.4.2) Not enough fees when subsidy is lower

On Fri, Aug 14, 2015 at 12:01 AM, Geir Harald Hansen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

> So in summary:
> - Bitcoin dies. The end.

I believe this is included in "btc exchange rate may fall".

On Sat, Aug 15, 2015 at 12:35 AM, Jorge Timón <jtimon@jtimon•cc> wrote:

> On Wed, Aug 12, 2015 at 1:21 PM, Venzen Khaosan <venzen@mail•bihthai•net> wrote:
>> 4) General, undefined fear that something bad is going to happen when
>> nodes choke up on a backlog of transactions.
>> - - no specific symptoms are pointed at but presumably there is
>> "pre-traumatic stress" at play.
>> - - Bitcoin-based businesses are going to lose money, customers and
>> potentially fail
>> - - people will flee Bitcoin for another cryptocoin and Bitcoin will be
>> left in the corner, collecting dust and memories of it will fade as
>> SuperCoin with its big blocks becomes all things to all people.
>
> I believe thisbelongs in 2, not really sure if 2.1 or 2.2 since it's
> related to both.

I was tempted to add it as a sub-sub-risk in both, since both things need to be solved before that stop being a concern. But they may be more things to do to solve that so I'm listing it as a separate sub-risk in 2:

2.3) Big list of valid unconfirmed transactions

resulting list:

1) Potential indirect consequence of rising fees.

1.1) Lowest fee transactions (currently free transactions) will become more unreliable. 1.2) People will migrate to competing systems (PoW altcoins) with lower fees. 1.3) Layer 2 settlements become more expensive 1.4) Less usage than we could have had with a bigger size 1.4.1) More regulation pressure 1.4.2) Not enough fees when subsidy is lower

2) Software problem independent of a concrete block size that needs to be solved anyway, often specific to Bitcoin Core (ie other implementations, say libbitcoin may not necessarily share these problems).

2.1) Bitcoin Core's mempool is unbounded in size and can make the program crash by using too much memory.

2.2) There's no good way to increase the fee of a transaction that is taking too long to be mined without the "double spending" transaction with the higher fee being blocked by most nodes which follow Bitcoin Core's default policy for conflicting spends replacements (aka "first seen" replacement policy).

2.3) Big list of valid unconfirmed transactions

To be clear, these two are just my personal lists of arguments on "each side" to clear my mind and try to be perfectly objective. The resulting lists may not have any practical value but I'm going to maintain them locally nonetheless. If that's is not useful for the participants they can just leave the thread. I'm not going to be impartial: I will only add to my lists the arguments that I consider reasonable and, more importantly, I understand.

The lists are in the public domain and everybody is free to use it and modify it in any way, feel free to fork the threads with other criteria different from "whatever jtimon thinks is reasonable", but if you want to participate, face it, it's what these 2 threads are about.

Here's the updated both-thread lists:

http://0bin.net/paste/igHZMgeoIbYjCJd9#ovaOUlSAKvQYT2p3VXuIuUmNk2XyLH-GnjR5NZMZgFb

On Fri, Aug 14, 2015 at 3:55 PM, Jorge Timón <jtimon@jtimon•cc> wrote:

> On Wed, Aug 12, 2015 at 9:52 PM, Elliot Olds <elliot.olds@gmail•com>
> wrote:
>
> -Reduce the utility of people using the network, even if the higher fees
> > don't reduce their amount of transactions.
>
> "Utility" like "value" is always subjective and very vague. I prefer
> to identify more concrete ways in which "utility is reduced".

Change 'utility' to 'money.' I'm just saying that paying more money for the same thing is worse for users. If I'm a user who is used to making txns for 1 cent each and suddenly all my txns cost 1 dollar each. then the benefit I get for each of my transactions that I still make is reduced by 99 cents per tx. This is as concrete a negative effect as I can imagine. It might seem obvious that this is a cost, but it seems to be ignored by a lot of participants.

> > -Make some use cases nonviable, depriving people of Bitcoin's
> decentralized
> > benefits.
>
> It is clear that not all use cases fit the blockchain, but it's still
> unclear which ones don't fit yet.
> But the amount of use cases supported is not a valid metric for
> decentralization.
>

Not sure what you mean by "valid metric for decentralization." I thought the goal here was to list all negative consequences of high fees. Not just consequences to decentralization. We're trying to figure out how to trade off risks to decentralization against these other things we're listing which aren't necessarily about decentralization (such as reduced use cases).

> In any case, it would be interesting if we could list some concrete
> cases that would be lost.
>

If tx fees rise to $1, then I'll stop making on-blockchain purchases of less than about $100, meaning pretty much all retail purchases are eliminated. It's hard to list a lot of use cases that will be lost because Bitcoin usage is very low right now. I assume most of us believe that there are lots of interesting use cases that have not developed yet. Just because they don't exist now doesn't mean we should ignore the fact that high fees might make them nonviable.

Some examples of stuff that doesn't exist now but might be prevented or significantly harmed by high fees: small international remittances, machine to machine payments, decentralized prediction markets (maybe people like making lots of small bets). Just take any potential use case you can think of: if the per-tx benefit to the person is less than $1, then $1 tx fees will prevent it. See below for another example.

> > -Discourage experimentation with new Bitcoin use cases, making it more
> > unlikely that such cases are discovered/improved/popular before Bitcoin's
> > security relies on having many users.
>
> Experimentation can be done with worthless testchains. I'm not sure
> I'm following on this one.
>

I think this is one of the most important costs to worry about. So much of experimentation can't be done on a testchain, because most experiments that are being done by early stage companies are about product market fit, and which services are valuable to users.

Let's say that you and I start a company that allows people to charge money to people who want to email/message them. There are so many things that we need to figure out that can't be figured out without participating in the actual market, with real people, who are really trying to use our service. It might take us years of making little tweaks to the product before we hit on some solution that people finally like enough to use in large numbers.

Let's say that right now tx fees are $1, and imagine that the highest amount that most people are willing to pay to email people is 25 cents. If we are experimenting in a market with $1 tx fees, perhaps our company will just die and we'll never figure out how to bring people this service that they want. Perhaps there are a lot of other innovations relating to 'pay to message' that would have otherwise been developed (maybe celebrities like doing AMAs via pay-to-message and devote the funds to charities. Maybe this becomes a huge source of charitable giving in the future), but because Bitcoin's high fee environment didn't allow us to explore these ideas, this whole service category goes undeveloped for many years.

> -Reduce the amount of time we have between now and when tx fees need to
> pay
> > for a significant portion of Bitcoin's security, by keeping the exchange
> > rate and thus the value of block rewards low
> > (https://en.wikipedia.org/wiki/Equation_of_exchange)
>
> Related to exchange rate.
>

Elsewhere you write "I believe 'fear of exchange rate declining' can probably be added to any concern/risk 'leaf', so we should probably leave that for the end or just omit it."

It's true that you could tell some indirect story about how pretty much anything could affect the exchange rate, but separate from all the hypothetical stories there is a strong theoretical reason to believe that the exchange rate will be higher the more value is transacted in the Bitcoin ecosystem. See the wiki link on the equation of exchange. More people using Bitcoin for transactions will drive up the price, all else being equal. Perhaps many people care about the price for irrelevant reasons (they just want to be rich), but as long as Bitcoin's security is tied to the exchange rate via block rewards, it's also an important consideration for security.

On Fri, Aug 14, 2015 at 4:57 PM, Jorge Timón < bitcoin-dev@lists•linuxfoundation•org> wrote:

> To be clear, these two are just my personal lists of arguments on
> "each side" to clear my mind and try to be perfectly objective.
> [...]
> Here's the updated both-thread lists:
>
>
> http://0bin.net/paste/igHZMgeoIbYjCJd9#ovaOUlSAKvQYT2p3VXuIuUmNk2XyLH-GnjR5NZMZgFb

I thought this was a good idea, so I turned my personal notes into a site attempting to list all the strongest arguments and counterarguments on the block size debate. I made mine a bit more detailed.

Here's the site: https://sites.google.com/site/bitcoinblocksizedebate/

Feedback welcome.

Add:

For - If everyone agrees an increase is required at some point, The longer you leave it the greater the numbers who have to upgrade

Against - Insufficient testing before moving to production ready releases sets a bad precedent

On Thu, Aug 20, 2015 at 10:11 PM, Elliot Olds via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> On Fri, Aug 14, 2015 at 4:57 PM, Jorge Timón <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> To be clear, these two are just my personal lists of arguments on
>> "each side" to clear my mind and try to be perfectly objective.
>> [...]
>> Here's the updated both-thread lists:
>>
>>
>> http://0bin.net/paste/igHZMgeoIbYjCJd9#ovaOUlSAKvQYT2p3VXuIuUmNk2XyLH-GnjR5NZMZgFb
>
>
> I thought this was a good idea, so I turned my personal notes into a site
> attempting to list all the strongest arguments and counterarguments on the
> block size debate. I made mine a bit more detailed.
>
> Here's the site: https://sites.google.com/site/bitcoinblocksizedebate/
>
> Feedback welcome.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>