From: Elliot Olds <elliot.olds@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
Date: Thu, 6 Aug 2015 16:09:49 -0700 [thread overview]
Message-ID: <CA+BnGuE1bcFaL70+dvsRgtZib2t+Ogku3rfPSwV-2qjRAVdEcA@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDoNbhc1=kgc0F+wSm33hTmRmmptk-XcaZxsm=6iJkWu=w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 12964 bytes --]
On Wed, Aug 5, 2015 at 6:26 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
>
>
> Given that for any non-absurdly-big size some transactions will
> eventually be priced out, and that the consensus rule serves for
> limiting mining centralization (and more indirectly centralization in
> general) and not about trying to set a given average transaction fee,
> I think the current level of mining centralization will always be more
> relevant than the current fee level when discussing any change to the
> consensus rule to limit centralization (at any point in time).
> In other words, the question "can we change this without important
> risks of destroying the decentralized properties of the system in the
> short or long run?" should be always more important than "is there a
> concerning rise in fees to motivate this change at all?".
>
I agree with you that decentralization is the most important feature of
Bitcoin, but I also think we need to think probabilistically and concretely
about when risks to decentralization are worthwhile.
Decentralization is not infinitely valuable in relation to low fees, just
like being alive is not infinitely valuable in relation to having money.
For instance, people will generally not accept a 100% probability of death
in exchange for any amount of money. However anyone who understands
probability and has the preferences of a normal person would play a game
where they accept a one in a billion chance of instant death to win one
billion dollars if they don't die.
Similarly we shouldn't accept a 100% probability of Bitcoin being
controlled by a single entity for any guarantee of cheap tx fees no matter
how low they are, but there should be some minuscule risk of
decentralization that we'd be willing to accept (like raising the block
size to 1.01 MB) if it somehow allowed us to dramatically increase
usability. (Imagine something like the Lightning Network but even better
was developed, but it could only work with 1.01 MB blocks).
> > Jorge, if a fee equilibrium developed at 1MB of $5/tx, and you somehow
> knew
> > with certainty that increasing to 4MB would result in a 20 cent/tx
> > equilibrium that would last for a year (otherwise fees would stay around
> $5
> > for that year), would you be in favor of an increase to 4MB?
>
> As said, I would always consider the centralization risks first: I'd
> rather have a $5/tx decentralized Bitcoin than a Bitcoin with free
> transactions but effectively validated (when they validate blocks they
> mine on top of) by around 10 miners, specially if only 3 of them could
> easily collude to censor transactions [orphaning any block that
> doesn't censor in the same manner]. Sadly I have no choice, the later
> is what we have right now. And reducing the block size can't guarantee
> that the situation will get better or even that fees could rise to
> $5/tx (we just don't have that demand, not that it is a goal for
> anyone). All I know is that increasing the block size *could*
> (conditional, not necessarily, I don't know in which cases, I don't
> think anybody does) make things even worse.
>
I agree that we don't have good data about what exactly a 4 MB increase
would do. It sounds like you think the risks are too great / uncertain to
move from 1 MB to 4 MB blocks in the situation I described. I'm not clear
though on which specific risks you'd be most worried about at 4 MB, and if
there are any risks that you think don't matter at 4 MB but that you would
be worried about at higher block size levels. I also don't know if we have
similar ideas about the benefits of low tx fees. If we discussed exactly
how we were evaluating this scenario, maybe we'd discover that something I
thought was a huge benefit of low tx fees is actually not that compelling,
or maybe we'd discover that our entire disagreement boiled down to our
estimate of one specific risk.
For the record, I think these are the main harms of $5 tx fees, along with
the main risks I see from moving to 4 MB:
Fees of $5/tx would:
(a) Prevent a lot of people who could otherwise benefit from Bitcoin's
decentralization from having an opportunity to reap those benefits.
Especially people in poor countries with corrupt governments who could get
immediate benefit from it now.
(b) Prevent developers from experimenting with new Bitcoin use-cases, which
might eventually lead to helpful services.
(c) Prevent regular people from using Bitcoin and experimenting with it and
getting involved, because they think it's unusable for txns under many
hundreds of dollars in value, so it doesn't interest them. Not having the
public on our side could make us more vulnerable to regulators.
Changing the block size to 4 MB would:
(1) Probably reduce the number of full nodes by around 5%. Most of the drop
in full nodes over the past few years is probably due to Bitcoin Core being
used by fewer regular users for convenience reasons, but the extra HD space
required and extra bandwidth would probably make some existing people
running full nodes stop.
(2) Not hinder low bandwidth miners significantly, because of the relay
network.
(3) Not introduce any tx verification issues, because processors are fast
and tx processing is ridiculously cheap and we'd need way more than 4 MB of
txs for it to be a bottleneck.
So (1) is the only risk that gives me any significant concern, but I don't
think that the number of full nodes now is at a dangerous level.
Anyway, the point isn't for you and I to actually discuss this particular
hypothetical in more detail (although I would be curious to see similar
lists from you). I haven't studied the risks enough to actually put this
forth to the list as a good argument for what to do in this situation. My
main point is that being very specific and concrete both about our thought
process and about the hypothetical situation results in much better
discussions.
There's one more piece of information that I can give you which will help
you understand my position much better, and also force me to think really
carefully about this. It's the point at which I would switch to the other
side of the argument (either by varying the tx fee, or the block size). If
tx fees would only rise to 60 cents or lower if we stayed at 1 MB, then I
would be against a move to 4 MB. Or, keeping the hypothetical 1 MB fee at
$5, I think moving to 12 MB or higher is the point at which I'd switch over
to being a 1 MB advocate. Getting that same info from you tells me exactly
how you weigh the risks in a way that just listing the factors can't. In
this specific hypothetical scenario, what is the lowest block size increase
that you'd accept? It can be extremely low, like 1.01 MB. If you tell me
that you'd rather have $5 tx fees for the next year instead of changing the
block size to 1.01 MB, I would be really surprised.
Gavin is the only other person who I've seen who has defined at what block
size he'd switch to the other side (maybe not with a concrete number, but
with a rough range: the block size such that a normal person with a pretty
good connection couldn't run a full node).
> On the other hand, I could understand people getting worried if fees
> where as high as $5/tx or even 20 cent/tx but we're very far away from
> that case. How can low subsidies (a certainty) be "too far in the
> future to worry about it" but $5/tx, 20 cent/tx or even 5 cent/tx an
> urgent concern?
I would say that in this case we know high tx fees could happen very soon
because there is a clear mechanism. Bitcoin just needs to become more
popular quickly for any number of reasons. Suppose the infrastructure for
remittances starts falling into place within the next two months, and
suddenly immigrants are clamoring to use Bitcoin to send money back to
their home countries. This could result in $5 tx fees very soon (not that I
think it's likely). Many of these immigrants would still use Bitcoin
because it's still better than the alternative for remittances, which would
price out a lot of people currently using Bitcoin for other reasons. As far
as I know, there is no plausible way that subsidies could plummet in
anywhere near that time frame, aside from the price of Bitcoin completely
collapsing. But if that happens in the near term (specifically, with very
low tx volume) a fee market won't help.
> For all I know, 5 cent/tx may not happen in the next
> 25 years: it may never happen. And if it happens, to me it will be a
> symptom of Bitcoin success, even for others it means that Bitcoin has
> become a "high value settlement network".
>
I would be extremely happy if Bitcoin could somehow sustain itself in the
long run with 5 cent tx fees. I'm optimistic about Lightning to handle the
cases where people need even cheaper txns.
> I'm still missing an answer from the "big blocks size side" to the
> following question (which I have insistently repeated with various
> permutations):
>
> If "not now" when will it be a good time to let fees rise above zero?
> After the next subsidy halving? After 4 more subsidy halvings (ie
> about 13 years from now, subsidy = 1.5625 btc/block )? After your
> grandmother abandons her national currency and uses Bitcoin for
> everything? Never?
>
> ANY answer (maybe with the exception of the last one) would be less
> worrying than silence.
>
Before I answer, here's my reasoning about why we don't need to worry about
a fee market now:
There is nothing particularly special about a fee market in Bitcoin. We
know how markets work, and we have no reason to suspect a fee market in
Bitcoin will have any new properties of markets that we can't foresee. When
demand becomes higher, there will be some equilibrium level of fee that
people have to pay to give a certain probability of inclusion within a
certain number of blocks. There will likely be some level of fee where if
you don't pay it, your tx will never be confirmed.
We have seen something like this working at various points in Bitcoin's
history. Look at the recent "stress tests." To get your tx confirmed in a
reasonable time frame, you had to bump your fee a little higher than the
txns from whoever was flooding the network. If you did, everything worked
fine. If you didn't, your tx didn't confirm (until the test ended, maybe?).
So there's nothing complicated here. It doesn't require a decade long
preparation to prove to ourselves that a fee market will work.
Unless in the future mining is funded mostly by charity (I think there's
only a 25% chance of that happening), we will need a fee market eventually.
I'd be fine if one developed now. I think 10 cents per txn right now
wouldn't be too bad, aside from the following reason. What concerns me
about insisting on a fee market right now is that usage is so small and the
block size is so limited that if demand increases just a little bit, fees
could skyrocket. It's not the 10 cent fees that would worry me, but what
they say about the potential for a huge spike. Fees could become $10 per tx
or higher very quickly. Yes, that would show that big organizations find
Bitcoin useful which is nice, but it'd also put decentralized money out of
reach of many other people. While Bitcoin still has a lot of growth ahead
of it, it's better to not set up roadblocks (for reasons other than
preserving decentralization) in front of that growth which will make things
very painful if that growth happens more suddenly than we expect.
I think the best argument for having a fee market right now is that if we
move to such a market suddenly in the future, wallets won't have time to
make the user experience good, and full nodes might not be written in such
a way that they gracefully handle a bunch of txns that might never confirm.
I don't think the required software changes are that complex though, so it
seems unnecessary to start adding friction for users now for something that
might be an issue in 10+ years.
So to answer your question: about two years before we think Bitcoin will
need to rely heavily on txn fees for security, I'd be in favor of adjusting
block size so that it resulted in enough total fees / security. Until that
point, we should care a lot about Bitcoin being widely used so that when we
do need a fee market, it's more like lots of people paying 5 cents per tx
instead of fewer people paying $10/tx. I think the former situation is much
more likely to sustainable, and we're more likely to get there if we
encourage low fee use cases now.
You've been arguing that 0 fee transactions will have to disappear someday,
but this isn't necessarily true. As long as enough people care about having
their txns confirm relatively quickly, there's no reason to make sure that
people who pay 0 fees never have their txns confirmed.
[-- Attachment #2: Type: text/html, Size: 14639 bytes --]
next prev parent reply other threads:[~2015-08-06 23:09 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 14:25 Pieter Wuille
2015-07-30 15:04 ` Greg Sanders
2015-07-30 15:12 ` Jorge Timón
2015-07-30 16:23 ` Jameson Lopp
2015-07-30 16:36 ` Bryan Bishop
2015-07-30 16:43 ` Jameson Lopp
2015-07-30 16:36 ` Venzen Khaosan
2015-07-30 17:51 ` Jorge Timón
2015-07-30 18:00 ` Jorge Timón
2015-07-30 16:56 ` Gary Mulder
2015-07-30 17:13 ` Mark Friedenbach
2015-07-30 16:20 ` Gavin Andresen
2015-07-30 16:41 ` Suhas Daftuar
2015-07-30 16:48 ` Adam Back
2015-07-30 16:49 ` Pieter Wuille
2015-07-31 10:16 ` Mike Hearn
2015-07-31 11:43 ` Venzen Khaosan
2015-07-31 11:51 ` Jorge Timón
2015-07-31 12:15 ` Mike Hearn
2015-07-31 13:07 ` Marcel Jamin
2015-07-31 14:33 ` Jorge Timón
2015-07-31 14:58 ` Mike Hearn
2015-07-31 15:28 ` Venzen Khaosan
2015-07-31 20:09 ` Elliot Olds
2015-08-04 10:35 ` Jorge Timón
2015-08-04 11:04 ` Hector Chu
2015-08-04 11:27 ` Pieter Wuille
2015-08-04 11:34 ` Hector Chu
2015-08-04 12:10 ` Venzen Khaosan
2015-08-04 13:13 ` Jorge Timón
2015-08-04 13:28 ` Hector Chu
2015-08-04 13:42 ` Venzen Khaosan
2015-08-04 17:59 ` Jorge Timón
2015-08-04 13:12 ` Gavin Andresen
2015-08-04 13:54 ` Pieter Wuille
2015-08-04 14:30 ` Venzen Khaosan
2015-08-04 14:43 ` [bitcoin-dev] Fwd: " Venzen Khaosan
2015-08-04 14:45 ` [bitcoin-dev] " Alex Morcos
2015-08-05 8:14 ` Gareth Williams
2015-08-04 11:59 ` Jorge Timón
2015-08-04 12:19 ` Hector Chu
2015-08-04 13:34 ` Venzen Khaosan
2015-08-04 13:37 ` Jorge Timón
2015-08-05 7:29 ` Elliot Olds
2015-08-06 1:26 ` Jorge Timón
2015-08-06 13:40 ` Gavin Andresen
2015-08-06 14:06 ` Pieter Wuille
2015-08-06 14:21 ` Gavin Andresen
2015-08-06 14:53 ` Pieter Wuille
[not found] ` <CABsx9T0B2bZrFHxYR_QNwBmxskQx31zt=QE5BJAYjcOo7wbo3A@mail.gmail.com>
2015-08-06 15:24 ` [bitcoin-dev] Fwd: " Gavin Andresen
2015-08-06 15:26 ` Pieter Wuille
2015-08-06 18:43 ` Michael Naber
2015-08-06 18:52 ` Pieter Wuille
2015-08-07 16:06 ` Thomas Zander
2015-08-07 16:30 ` Pieter Wuille
2015-08-07 17:00 ` Thomas Zander
2015-08-07 17:09 ` Pieter Wuille
2015-08-07 21:35 ` Thomas Zander
2015-08-07 22:53 ` Adam Back
2015-08-08 16:54 ` Dave Scotese
2015-08-07 17:50 ` Gavin Andresen
2015-08-07 18:05 ` Jameson Lopp
2015-08-07 18:10 ` Pieter Wuille
2015-08-07 21:43 ` Thomas Zander
2015-08-07 22:00 ` Thomas Zander
2015-08-06 16:19 ` [bitcoin-dev] " Tom Harding
2015-08-06 21:56 ` Peter Todd
2015-08-06 15:25 ` Jorge Timón
2015-08-06 16:03 ` Gavin Andresen
2015-08-06 16:11 ` Mike Hearn
2015-08-06 17:15 ` Jorge Timón
2015-08-06 19:42 ` Gavin Andresen
2015-08-06 20:01 ` Pieter Wuille
2015-08-06 21:51 ` Jorge Timón
2015-08-06 23:09 ` Elliot Olds [this message]
2015-08-10 19:28 ` Jorge Timón
2015-08-11 5:48 ` Elliot Olds
2015-08-09 18:46 ` [bitcoin-dev] What Lightning Is Tom Harding
2015-08-09 18:54 ` Mark Friedenbach
2015-08-09 20:14 ` Hector Chu
[not found] ` <CAOG=w-s9KsaPwveSpgdvsVTWUDV77YY7Em7NZGyxSQMMCccYSg@mail.gmail.com>
2015-08-09 20:48 ` Hector Chu
2015-08-10 4:48 ` Joseph Poon
2015-08-10 17:03 ` odinn
2015-08-10 17:14 ` Pieter Wuille
2015-08-10 17:45 ` odinn
2015-08-09 21:27 ` Tom Harding
2015-08-09 21:40 ` Chris Pacia
2015-08-09 21:45 ` Hector Chu
2015-08-09 21:57 ` Patrick Strateman
2015-08-09 22:03 ` Hector Chu
2015-08-09 22:36 ` Patrick Strateman
2015-08-10 1:52 ` Tom Harding
2015-08-10 3:31 ` Patrick Strateman
2015-08-09 22:06 ` Patrick Strateman
2015-08-09 22:09 ` Hector Chu
2015-08-09 22:27 ` Patrick Strateman
2015-08-09 22:30 ` Hector Chu
2015-08-09 22:44 ` Gavin Andresen
2015-08-09 22:51 ` Btc Drak
2015-08-10 8:27 ` Thomas Zander
2015-08-10 8:36 ` Patrick Strateman
2015-08-10 4:39 ` Joseph Poon
2015-08-10 21:02 ` Anthony Towns
2015-08-10 21:19 ` Anthony Towns
2015-08-10 21:43 ` Adam Back
2015-08-11 9:01 ` Hector Chu
2015-08-11 17:17 ` Simon Liu
2015-07-31 14:52 ` [bitcoin-dev] Block size following technological growth Bryan Bishop
2015-07-30 17:46 ` Jorge Timón
2015-08-02 22:35 ` Anthony Towns
2015-07-30 20:20 ` Thomas Zander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+BnGuE1bcFaL70+dvsRgtZib2t+Ogku3rfPSwV-2qjRAVdEcA@mail.gmail.com \
--to=elliot.olds@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox