Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C4376A74 for ; Tue, 11 Jul 2017 23:28:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 85D7A1ED for ; Tue, 11 Jul 2017 23:28:48 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1dV4aD-0007Ma-7k; Wed, 12 Jul 2017 09:28:46 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Wed, 12 Jul 2017 09:28:39 +1000 Date: Wed, 12 Jul 2017 09:28:39 +1000 From: Anthony Towns To: Paul Sztorc , Bitcoin Protocol Discussion Message-ID: <20170711232839.GA5424@erisian.com.au> References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 11 Jul 2017 23:37:52 +0000 Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 23:28:49 -0000 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