[bitcoin-discuss] Communication Issues

[Anthony Towns]

On Sat, Jan 16, 2016 at 05:50:06PM -0800, Eric Lombrozo via bitcoin-discuss wrote:
> In following all the discussion that’s been taking place the last
> several months, it’s become quite clear this space is suffering from
> a serious communication and misperception problem.

I think that one of the big communication problems is what problem is
trying to be solved. There are a few clear ones (a) how quickly merchants
can accept a payment, (b) how high the fees are users have to pay, (c)
how miners will pay their bills after the halvening, and (d) whether
hard forks are possible and how they actually happen.

But these are all very nitty-gritty, technical questions, and my
impression is that while they matter, the real core of much of the angst
is actually simpler: will bitcoin's growth will continue or stall?

Up until December 2013, you could see Bitcoin growing by looking at
the USD/BTC exchange rate -- with very appealing hockey stick curves
even. And then from between about April 2014 and today, you have a fairly
nice exponential curve in number of transactions per day, growing from
50k tx/day around June 2014 to 100k tx/day around April 2015 and 200k
tx/day around now more or less doubling in 9 months.

I think tx/day (or tx/s) is a very attractive metric, and people are
(rightly) fixated on it. It's easy to understand, is at least a little
correlated with real use, and is easily comparable to other systems
(hi Visa!).

With every block hitting 1MB, and every transaction being fairly small at
~250 bytes, the current system might allow for up to about 576k tx/day,
which is just 1.5 more doublings from now, or just over 12 months of
"growth". But this is *very* optimistic, since while the subsidy is large
relative to fees miners will optimise their own profit by sometimes
issuing empty blocks, so I think it's more realistic to estimate that
bitcoin currently has at most about 80% of that capacity, so perhaps 11
months of growth (ie until about Dec 2016).

The segregated witness soft-fork decreases the number of transactions that
can be packed within the 1MB limit depending on the size of the signature
data per transaction -- more signature, more increase. That variation
makes it hard to translate to an effect on "transactions per day", but
I think the 1.75x or 2x multiplier is fair, giving up to 800k to 920k
tx/day (again taking into account that miners won't fill all blocks),
which is 2 or 2.2 doublings, so rather than 11 months of growth, segwit
alone should provide 18 to 20 months of continued exponential growth at
current rates (ie until Jul/Sep 2017).

But note that July next year isn't really that far away!

At the current growth rates, a hard fork from 1MB to 2MB gives an extra
9 months of sustained exponential growth, as does a hardfork from 2MB
to 4MB. Putting those numbers together gives, I think, something like
the following plan:

 (1) segwit this year (allowing growth until Jul/Sep 2017)

 (2) merge hardfork to 2MB prior to Oct/Dec 2016, activating in
     Apr/Jun 2017 (allowing growth until Apr/Jun 2018)

 (3) merge hardfork to 4MB prior to Jul/Sep 2017, activating in
     Jan/Mar 2018 (allowing growth until Jan/Mar 2019)

Note that with a six-month leadtime on hardforks, even *with* segwit
deployed, a hardfork to 2MB needs to get off the ground this year for
the exponential growth of on-chain tx/day to be sustained.

Note also that segwit (using the 1/4 discount factor for sig data) and
a 2MB hardfork already gives worst case 8MB of block data, which, AIUI,
is already at or beyond the edge of what miners can reasonably cope with.

I think this is a problem in particular for the Bitcoin Classic plan,
which presumably goes something like:

  (1) merge hardfork to 2MB ASAP, activating in Mar 2016 (allowing growth
      until Sep 2017)

  (2) segwit ASAP (allowing growth until Jun 2018)

  (3) merge hardfork to 4MB, activating in Mar 2018 (allowing growth until
      Mar 2019)

The problem is that with 8MB worst case blocks after 2MB and segwit is
deployed, this may delay deployment of segwit, along with the malleability
fixes, script enhancements and so forth that go with it. So rather than
having segwit in April-June 2016, it might need to be delayed until after
IBLT and weak blocks are further developed, so perhaps anywhere from Nov
2016 to March 2017. The other approach would be to deploy it without
providing any scalability benefit (ie a 1-to-1 rating of signature data),
which would then mean the 4MB hardfork would have to be brought forward
to 2017, and an additional 8MB hardfork would be needed in 2018 to keep
growth on track.

One obvious rebuttal is "nobody made a law out of tx/day doubling
every nine months, who cares if it goes slower or stops?". And that's
fair. But without a better metric than "tx/day", that's also simple and
comparable, it's effectively the same as saying "nobody made a law out
of bitcoin having to grow consistently, so who cares if it stops growing
entirely?" and I think it's safe to say a whole bunch of people care
about that, and it's pretty plausible that they might actually be the
economic majority.

One obvious alternative approach would be to say "growth matters, but the
number of on-chain transactions per day isn't what's important", but,
in that case what *is* important, and how do you measure (or estimate)
it? Would coinbase and bitpay and others be willing to reveal (anonymised)
internal data, so the number of off-chain transactions could be accounted
for as some sort of "state of bitcoin" report? Would there be some way
to estimate statistics for lightning usage once lightning starts working?

(Given how low bitcoin's fees are in comparison to the money floating
around in the industry, tx/day seems like a very easy metric to
manipulate as well; but apart from stress tests last year, and the fact
that maintaining exponential growth despite all the controversy over the
past year is remarkably fortunate, I haven't seen anything that strongly
persuades me historical tx/day is anything other than a real reflection
of use)

None of the above attempts to address how high fees will be, or how
miners will get paid, simply whether number of transactions per day will
be able to continue doubling every nine months.

I think that rate of increase will mean fees remain at approximately zero
(ie, at the hardcoded minimums wallets default to), and as far as I've
seen problems with getting confirmations even during stress tests have
all actually been wallet user-interface issues (creating transactions
with dust outputs, and having fixed fees rather than multiplying by tx
size; actually calculating fees dynamically should put you well ahead
of the game) rather than too many people actually paying high fees.

Low fees are a bad thing for miners of course, but even with 4MB blocks
and a massive 20k tx/block, you're looking at 25c/tx and $400/BTC to have
fees for a block match the 12.5 BTC in subsidy. For the fee market to
be a realistic way of funding mining, it seems like blocks would need
to grow to 25MB (10c/tx) to 100MB (2.5c/tx) to me. That's about six
doublings (so segwit, 2MB, 4MB, 8MB, 16MB, 32MB for a total of ~64MB),
and if nine months per doubling is sustained for that long, should hit
around Jul 2020, just in time for the subsidy halving to 6.25BTC/block.

Personally, I think a rough schedule for an increase to 2MB after segwit
is still needed now (though activating it in a month and a half from
now seems insanely risky, and, as above, doing it prior to segwit seems
suboptimal). As above, planning to include it in released code late this
year and activate it first half of next year seems about right to me.
Sticking with 1MB+segwit for this year, hardforking to 2MB in a year or
so then 4MB sometime after that as above is also compatible with what I
understood the core plan for scaling to be, but given there a schedule
hasn't been presented, YMMV obviously.

Perhaps this year's "scaling bitcoin" conferences should seriously
look into finding ways to measure/estimate (and provide metrics on)
off-chain growth, so that companies and advocates can focus on going
super-exponential there, rather than just remaining exponential on-chain.

Hopefully the above is interesting, and not off-topic for -discuss.

Cheers,
aj