[bitcoin-dev] A summary list of all concerns related to not rising the block size

[Jorge Timón via bitcoin-dev]

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.

[Venzen Khaosan via bitcoin-dev]

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!

Post by Jorge Timón via bitcoin-dev

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Jorge Timón via bitcoin-dev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jorge, you say 3 concerns at the end of your message but I only see 1)

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.

- - 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.

[Jorge Timón via bitcoin-dev]

Post by Jorge Timón via bitcoin-dev

Post by Venzen Khaosan via bitcoin-dev
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

[Jorge Timón via bitcoin-dev]

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

[Elliot Olds via bitcoin-dev]

On Fri, Aug 14, 2015 at 4:57 PM, Jorge Timón <

Post by Jorge Timón via bitcoin-dev
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.
[...]
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.

[Ahmed Zsales via bitcoin-dev]

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 <

Post by Elliot Olds via bitcoin-dev
On Fri, Aug 14, 2015 at 4:57 PM, Jorge Timón <

Post by Jorge Timón via bitcoin-dev
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.
[...]
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Elliot Olds via bitcoin-dev]

On Wed, Aug 12, 2015 at 2:59 AM, Jorge Timón <

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.

[Jorge Timón via bitcoin-dev]

On Wed, Aug 12, 2015 at 2:59 AM, Jorge Timón

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.

-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
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).

[Elliot Olds via bitcoin-dev]

Post by Elliot Olds via bitcoin-dev
-Reduce the utility of people using the network, even if the higher fees

Post by Elliot Olds via bitcoin-dev
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.

Post by Elliot Olds via bitcoin-dev

Post by Elliot Olds via bitcoin-dev
-Make some use cases nonviable, depriving people of Bitcoin's

decentralized

Post by Elliot Olds via bitcoin-dev
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).

Post by Elliot Olds via bitcoin-dev
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.

Post by Elliot Olds via bitcoin-dev

Post by Elliot Olds via bitcoin-dev
-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.

Post by Elliot Olds via bitcoin-dev
-Reduce the amount of time we have between now and when tx fees need to pay

Post by Elliot Olds via bitcoin-dev
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.

[Ashley Holman via bitcoin-dev]

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 <

Post by Jorge Timón via bitcoin-dev

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Jean-Paul Kogelman via bitcoin-dev]

Post by Ashley Holman via bitcoin-dev
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

[Jorge Timón via bitcoin-dev]

On Thu, Aug 13, 2015 at 11:52 AM, Ashley Holman via bitcoin-dev

Post by Ashley Holman via bitcoin-dev
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

[Geir Harald Hansen via bitcoin-dev]

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

Post by Jorge Timón via bitcoin-dev

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Venzen Khaosan via 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?

Post by Geir Harald Hansen via bitcoin-dev
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.
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

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

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________ bitcoin-dev mailing
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Marcel Jamin via 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 <

-----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?

Post by Geir Harald Hansen via bitcoin-dev
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.
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

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

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________ bitcoin-dev mailing
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Thomas Zander via bitcoin-dev]

Post by Venzen Khaosan via bitcoin-dev
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.

[Jorge Timón via bitcoin-dev]

On Fri, Aug 14, 2015 at 12:01 AM, Geir Harald Hansen via bitcoin-dev

Post by Geir Harald Hansen via bitcoin-dev
- Bitcoin dies. The end.

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