From: Elliot Olds <elliot.olds@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Cc: timon@jtimon•cc
Subject: Re: [bitcoin-dev] Block size following technological growth
Date: Mon, 10 Aug 2015 22:48:17 -0700 [thread overview]
Message-ID: <CA+BnGuG8MJtd0PmHBqvad=Ni8U9VNu083U8K2+obzqngjPTEaw@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDpGVpb+ZYF-Cg_dFM5aoCM5mADvM5dUqKBmGX_1P6=76A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 12000 bytes --]
On Mon, Aug 10, 2015 at 12:28 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
> I would just like that there was an attempt to automatically
> estimate those risks before taking those risks.
>
I agree.
> My main point about fees is that minimum mining fees rising above zero
> (theri current level) is not necessarily a bad thing or an urgent
> concern.
>
Yes, it only gets bad when fees become "high."
I'll skip over the discussion of the pros/cons I listed since that mostly
appeared for illustrative purposes and I don't have a strong disagreement
with anything you said.
> Great. I don't think that minimum mining fees will rise above 1 usd
> cent/tx anytime soon even if we maintain the limit of 1MB.
> Maybe that's why I'm not worried at all about "hitting the limit".
>
My sense is that the people arguing for a hard fork now tend to envision
"hitting the limit" as tx fees being fairly high, and those arguing against
a hard fork envision tx fees staying low when 1 MB blocks start to get
full. Which of those occurs depends on how quickly and in what manner
Bitcoin gains popularity. Even if I thought there's an 95% chance that
there would be no sudden jump in Bitcoin tx demand, I would want to have
some rough plan in place for that other 5% when some previously difficult
use case becomes viable and demand spikes. Do those arguing for the "wait
and see" approach not think that a quick increase in demand is even likely
enough to warrant discussing what we'd do in that case? Greg Maxwell
mentioned doubling the max block size if there was ever a standing backlog (
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007880.html
-- I think fee level is a better metric than size of tx backlog), but I
haven't seen other devs comment on it.
> But I'm sorry, I don't have those concrete numbers because it is a
> trade-off I don't think we've studied in enough detail.
>
The question is about what you'd do in the absence of those details that
you don't have. Imagine that fees spiked to $5/tx tomorrow. You have some
model of the situation that allows you to say that 1.01 MB is something
you'd support, and that's the model that I'm trying to understand. The
answers I gave are not ones I'm confident about. I'm sure if I studied this
for a week they'd change. I sense that devs are reluctant to answer this
question because it could be taken out of context or held against them
later. Or maybe they just don't like saying things that they don't have a
high level of confidence about on principle. IMO this reluctance
contributes to a lack of understanding of each other's positions. We all
have these imperfect models in our heads that we're basing our
disagreements on, but we won't show each other these models.
> > 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).
>
> That would be interesting to read and I have totally missed it.
> Do you have a link?
Sorry, I see how what I wrote was misleading. You've seen the email I'm
referring to. I was talking about when he defined the criteria he used
qualitatively and suggested that's how he arrived at 20 MB:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009971.html.
I think he talks about it in a little more detail elsewhere. I inferred
from that that he wouldn't support 40 MB or 80 MB, but that may be wrong.
I should also have given credit to Pieter, as he even more explicitly
specified a level where he'd turn into a hard fork advocate, via his own
hard fork proposal. Neither of these statements specifies exactly where the
switch-over point is, but they're the closest I've seen.
> > 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.
>
> And for any size something similar could happen with some use case.
> But this is a great example of a situation where I would understand
> people panicking and clamoring to change the consensus rule as soon as
> possible.
> Even with much lower fees, say 1 usd/tx.
> I think it would be a great problem to have and admittedly I'm not
> worried about having it in the short term.
> And if it happened overnight we could always deploy an emergency hardfork.
>
Don't you think the devs should have some rough plan that they discuss
ahead of time about what to do in the situation of high fees? Even if it
happened gradually -- suppose fees crept to 20 cents, then 50 cents, then
75 over the next year -- I don't think I've ever seen a discussion of how
that should be handled, and what sort of fees people regard as high enough
to justify considering a hard fork.
I think it would prevent many people from supporting an urgent hard fork if
they knew how the core devs would handle that situation (assuming there was
some willingness to increase the block size if fees got too high).
> > 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.
>
> [...]
> Also, yes, there is something special about this market: it is
> supposed to pay for most of the global hashrate in the not-so-far
> future.
> If we take too long to start moving away from total seigniorage
> subsidy dependence, it may be too late when we do.
>
I see that 'special' feature of this market as more strongly supporting the
need to encourage fast adoption.
Let's say block rewards are $7000 per block, and we think this gives a good
level of security (as Bitcoin grows, we'll probably want a lot more).
Suppose a 1MB block can hold 2000 txns. Then to pay for the same level of
security we have right now with only tx fees, assuming 1 MB blocks, the
average tx fee would have to be $3.50. Now suppose blocks are 100 MB in the
future. The average tx fee is then only 3.5 cents. I think the former
situation will not actually work, and the only way that Bitcoin can survive
is to eventually get into something more like the later situation. Let me
know if you want me to delve into why. I'll just note that even Lightning
doesn't work well when tx fees are that high, because channels need to be
opened and closed pretty often and if my counterparty is uncooperative, his
making me pay $3.50 starts to actually hurt.
So if we accept that, we need to end up in a situation where we eventually
have lots of people making on-blockchain txns, and paying relatively small
fees. Encouraging lots of use and experimentation of Bitcoin between now
and then seems pretty important for reaching that goal.
We're in a race with the block reward halving schedule, to see if we can
get usage high enough to pay for security (while maintaining enough
decentralization) before all of the security burden falls on transactions.
If there aren't enough transactions at that time, the burden will be too
high (or security will be too low) and people will find other solutions.
We seem to disagree about how hard it'll be to change wallet and node
software to cope with a fee market. As I've said I don't see very small
nonzero fees (for instance one tenth of a cent) as a problem though. So if
a solution that traded off usage and decentralization in a way that I
agreed with could be modified to ensure a fee market developed soon with
very low fees, I'd still support it.
>
> > 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.
>
> I think you are underestimating the software costs.
> And you not only have to adapt the software that we have now, but also
> the software that hasn't been written yet and will be written assuming
> free transactions and an underdeveloped market.
> Also you are over-estimating the costs: you could hit the limit but
> then rise the block size maximum as soon as you reach, say 0.00001
> usd/tx.
> Even if minimum fees go again to zero after rising the block size
> maximum, the software improvements will remain there.
>
> > 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.
>
> And when do you think "Bitcoin will need to rely heavily on txn fees
> for security"?
> How many more halvings is that?
>
> > 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.
>
> That's not what I've been arguing, I've just being saying that I would
> be completely ok with minimum fees rising above zero (say, to 1
> satoshi/tx) tomorrow.
> I don't think that's necessarily a bad thing (in fact, it has some
> advantages) and certainly not something we should fear to the point of
> rushing hardforks to avoid it.
>
[-- Attachment #2: Type: text/html, Size: 14427 bytes --]
next prev parent reply other threads:[~2015-08-11 5:48 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
2015-08-10 19:28 ` Jorge Timón
2015-08-11 5:48 ` Elliot Olds [this message]
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+BnGuG8MJtd0PmHBqvad=Ni8U9VNu083U8K2+obzqngjPTEaw@mail.gmail.com' \
--to=elliot.olds@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=timon@jtimon$(echo .)cc \
/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