* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-12 9:59 [bitcoin-dev] A summary list of all concerns related to not rising the block size Jorge Timón
@ 2015-08-12 11:21 ` Venzen Khaosan
2015-08-14 22:35 ` Jorge Timón
2015-08-12 19:52 ` Elliot Olds
` (2 subsequent siblings)
3 siblings, 1 reply; 18+ messages in thread
From: Venzen Khaosan @ 2015-08-12 11:21 UTC (permalink / raw)
To: Jorge Timón, Bitcoin Dev
-----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:
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
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVyyxLAAoJEGwAhlQc8H1mEmMH/j6ZAcsHIYT7+8EtOP6T8LTB
0M4njFlkMsT6owruY9sucIP5c+DjNXoTHqFdgdNnWluW2JNQ0L6wnbWSR9NSbo2h
WlwpMKV0o8XdEQIZV3ZH4kltlIH0napvddsjmvMZDiZU2R/2Lp6KVxK0NEPB4IOC
jZ4UM0v/XuYiu1I+zpnvi9MS3X/MTYzf7a5JZ9D6CiCksc+X18GtFLogKJG5uVRn
at58cdHQX/TgIhO/RcYV9PStztT93I6uh92RrQyRmXVMn9u2/bZZXTgk9CL9YkO0
g0Imw7vt0ieZ2E9m0QUlJ8tJQKEESflNI0ccachGPKpOKGTsshqbZ370uDKcDWA=
=v3a1
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-12 11:21 ` Venzen Khaosan
@ 2015-08-14 22:35 ` Jorge Timón
2015-08-14 23:12 ` Jorge Timón
0 siblings, 1 reply; 18+ messages in thread
From: Jorge Timón @ 2015-08-14 22:35 UTC (permalink / raw)
To: venzen; +Cc: Bitcoin Dev
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-14 22:35 ` Jorge Timón
@ 2015-08-14 23:12 ` Jorge Timón
2015-08-14 23:57 ` Jorge Timón
0 siblings, 1 reply; 18+ messages in thread
From: Jorge Timón @ 2015-08-14 23:12 UTC (permalink / raw)
To: venzen; +Cc: Bitcoin Dev
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-14 23:12 ` Jorge Timón
@ 2015-08-14 23:57 ` Jorge Timón
2015-08-20 21:11 ` Elliot Olds
0 siblings, 1 reply; 18+ messages in thread
From: Jorge Timón @ 2015-08-14 23:57 UTC (permalink / raw)
To: venzen; +Cc: 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-14 23:57 ` Jorge Timón
@ 2015-08-20 21:11 ` Elliot Olds
2015-08-20 21:29 ` Ahmed Zsales
0 siblings, 1 reply; 18+ messages in thread
From: Elliot Olds @ 2015-08-20 21:11 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1277 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-20 21:11 ` Elliot Olds
@ 2015-08-20 21:29 ` Ahmed Zsales
0 siblings, 0 replies; 18+ messages in thread
From: Ahmed Zsales @ 2015-08-20 21:29 UTC (permalink / raw)
To: Elliot Olds; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 2371 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-12 9:59 [bitcoin-dev] A summary list of all concerns related to not rising the block size Jorge Timón
2015-08-12 11:21 ` Venzen Khaosan
@ 2015-08-12 19:52 ` Elliot Olds
2015-08-14 22:55 ` Jorge Timón
2015-08-13 9:52 ` Ashley Holman
2015-08-13 22:01 ` Geir Harald Hansen
3 siblings, 1 reply; 18+ messages in thread
From: Elliot Olds @ 2015-08-12 19:52 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2563 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-12 19:52 ` Elliot Olds
@ 2015-08-14 22:55 ` Jorge Timón
2015-08-15 20:36 ` Elliot Olds
0 siblings, 1 reply; 18+ messages in thread
From: Jorge Timón @ 2015-08-14 22:55 UTC (permalink / raw)
To: Elliot Olds; +Cc: Bitcoin Dev
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).
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-14 22:55 ` Jorge Timón
@ 2015-08-15 20:36 ` Elliot Olds
0 siblings, 0 replies; 18+ messages in thread
From: Elliot Olds @ 2015-08-15 20:36 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5526 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 7189 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-12 9:59 [bitcoin-dev] A summary list of all concerns related to not rising the block size Jorge Timón
2015-08-12 11:21 ` Venzen Khaosan
2015-08-12 19:52 ` Elliot Olds
@ 2015-08-13 9:52 ` Ashley Holman
2015-08-13 16:36 ` Jean-Paul Kogelman
2015-08-14 22:57 ` Jorge Timón
2015-08-13 22:01 ` Geir Harald Hansen
3 siblings, 2 replies; 18+ messages in thread
From: Ashley Holman @ 2015-08-13 9:52 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 3043 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-13 9:52 ` Ashley Holman
@ 2015-08-13 16:36 ` Jean-Paul Kogelman
2015-08-14 22:57 ` Jorge Timón
1 sibling, 0 replies; 18+ messages in thread
From: Jean-Paul Kogelman @ 2015-08-13 16:36 UTC (permalink / raw)
To: Ashley Holman; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]
> 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
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-13 9:52 ` Ashley Holman
2015-08-13 16:36 ` Jean-Paul Kogelman
@ 2015-08-14 22:57 ` Jorge Timón
1 sibling, 0 replies; 18+ messages in thread
From: Jorge Timón @ 2015-08-14 22:57 UTC (permalink / raw)
To: Ashley Holman; +Cc: Bitcoin Dev
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-12 9:59 [bitcoin-dev] A summary list of all concerns related to not rising the block size Jorge Timón
` (2 preceding siblings ...)
2015-08-13 9:52 ` Ashley Holman
@ 2015-08-13 22:01 ` Geir Harald Hansen
2015-08-14 2:26 ` Venzen Khaosan
2015-08-14 22:59 ` Jorge Timón
3 siblings, 2 replies; 18+ messages in thread
From: Geir Harald Hansen @ 2015-08-13 22:01 UTC (permalink / raw)
To: 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
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
>
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-13 22:01 ` Geir Harald Hansen
@ 2015-08-14 2:26 ` Venzen Khaosan
2015-08-14 11:35 ` Marcel Jamin
2015-08-14 13:48 ` Thomas Zander
2015-08-14 22:59 ` Jorge Timón
1 sibling, 2 replies; 18+ messages in thread
From: Venzen Khaosan @ 2015-08-14 2:26 UTC (permalink / raw)
To: Geir Harald Hansen, 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?
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-----
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-14 2:26 ` Venzen Khaosan
@ 2015-08-14 11:35 ` Marcel Jamin
2015-08-14 13:48 ` Thomas Zander
1 sibling, 0 replies; 18+ messages in thread
From: Marcel Jamin @ 2015-08-14 11:35 UTC (permalink / raw)
To: venzen; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 6018 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 7537 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-14 2:26 ` Venzen Khaosan
2015-08-14 11:35 ` Marcel Jamin
@ 2015-08-14 13:48 ` Thomas Zander
1 sibling, 0 replies; 18+ messages in thread
From: Thomas Zander @ 2015-08-14 13:48 UTC (permalink / raw)
To: 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.
--
Thomas Zander
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size
2015-08-13 22:01 ` Geir Harald Hansen
2015-08-14 2:26 ` Venzen Khaosan
@ 2015-08-14 22:59 ` Jorge Timón
1 sibling, 0 replies; 18+ messages in thread
From: Jorge Timón @ 2015-08-14 22:59 UTC (permalink / raw)
To: Geir Harald Hansen; +Cc: Bitcoin Dev
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".
^ permalink raw reply [flat|nested] 18+ messages in thread