[bitcoin-dev] Updating the Scaling Roadmap

[Anthony Towns]

On Mon, Jul 10, 2017 at 12:50:21PM -0400, Paul Sztorc via bitcoin-dev wrote:
> We should revise [the roadmap]: remove what has been accomplished, 
> introduce new innovations and approaches, and update deadlines 
> and projections.

Timelines have good and bad points (in this context, I'd generally call
projections good, deadlines bad :); people have interpreted the lack of
any clear timeline for a hardmark on the 2015 roadmap as no plan for a
hard fork at all; meanwhile the overly optimistic timeline for segwit
being "ready" in April or July last year has been interpreted as "ready
for use" and treated as a failure, when it didn't work out that way.

I think it would be helpful for the development community to have some
way of talking about timelines, for instance to be able to say "the
*minimum* timeline for a reasonable hard fork is 6 months for proposal
review, speculative analysis and initial coding, 3 months for concrete
proposal review and thorough testing, 3-6 months for consensus to develop
on whether to lock the proposed changes in as the new consensus, and
a further 6-24 months for wide scale deployment to occur before any
behavioural change to take actual effect".

Those numbers give a lead time of 18 to 38 months of engagement with the
developer community before it takes effect, as compared to the six month
timeline of the New York agreement. 18 months implies that a block size
increase would be *available* today if people wanting larger blocks had
engaged with the development community from January 2016 in the same
way that segwit was developed, rather than working in their own sandboxes.

That could have happened: the proposals in 

  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011995.html

from Dec 2015 could have been engaged with, and, optimistically, we could
have a non-controversial deployment of SpoonNet already if they had been.

It might be a good idea to actually engage with investors and businesses
on this: the point of the timelines above isn't to slow things down for
its own sake, it's that you need to take time in order to think through
the potential consequences of changes, and avoid unintended bad outcomes.
That seems like something that investors and businesses can understand,
and endorse up front -- and they could meaningfully do so simply by saying
"any hard-fork that does not go through each of the stages for at least
the minimum time will be treated as an altcoin rather than an upgrade
of bitcoin". But the process has to be "here is what it takes from a
technical POV to avoid fucking up bitcoin; does your company endorse
being responsible with other people's money despite the costs of doing
so?" If you're in a move-fast-and-break-things mode, the answer might
legitimately be "no", of course.

>  ==== Beginning of New ("July 2017") Roadmap Draft ====

I'd suggest dividing the activities into phases more clearly; maybe:

 - Already available to users:
     * version bits
     * compact block relay
     * FIBRE
     * CSV
     * better fee estimation

 - Awaiting consensus:
     * segregated witness

 - Active development / concrete specifications:
     * lightning network
     * light client mode for bitcoin core (PR#10794)

 - Draft proposals at experimental stage:
     * transaction compression? (or is this the already deployed stuff?)
     * schnorr sig aggregation
     * drivechain
     * spoonnet
     * mimblewimble
     * block size increases

 - Ideas that aren't even experiments yet
     * asicboost prevention

> There is
> currently no consensus on a hard fork date, but there is a rough
> consensus that one would require at least 6 months to coordinate
> effectively, which would place it in the year 2018 at earliest.

As above, it seems to me that 18 months of engagement is likely a bare
minimum amount of time for a robustly implemented hard fork (6 months is
almost exactly segwit2x's total timeline, from proposal in late May as
the New York Agreement to the new rules being available in mid-November,
and it doesn't look at all robust to me).  

Possibly if the existing features of spoonnet are already adequate,
you could cut that down by a few months. But realistically, that says
to me early 2019 at the absolute earliest, and if engagement with the
development process doesn't start tomorrow, later than that.

FWIW, here's a longer form draft of what I think hard fork guidelines
maybe could look like:

  https://gist.github.com/ajtowns/914cf2309822bff357cda4ab3f48a966

It's obviously blatantly contradictory with support of the NYA/segwit2x,
but at this point I think that's true of any process that's not just
a rephrasing of "move fast and break things".

> Google Doc (if you're into that kind of thing):
> https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing

Publishing something like this as an informational BIP every year or
two seems like a good idea to me.

Instead of a "roadmap" (with the implication that there's a schedule
people might rely on and developers have to meet), maybe just have it as
a list of the current high impact scaling features being worked on --
where the purpose of publishing the list is to let people understand
how far various ideas have progressed currently, and focus attention on:

  - wider adoption of already deployed features, by users, exchanges,
    wallets, etc; eg segwit doesn't scale anything if no one uses it
  - achieving activation of implemented features
  - encouraging R&D on approaches that are currently still experimental
    in order to make them actually usable

In that case, there's no actual need for guessing at future dates;
just the current status is sufficient.

Documenting current roadblocks might also be valuable (eg, lightning and
signature aggregation and drivechains etc are kind-of stalled waiting
on segwit's activation, I think; for a brief point, segwit was stalled
waiting on compact blocks, etc). Might not be worthwhile updating the doc
regularly to keep track of what's a roadblock though.

(I think you could usefully generalise beyond scaling to just "high
impact features" really)

Cheers,
aj