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.