Hi Chris,

On 7/11/2017 12:03 PM, Chris Stewart wrote:
Concept ACK.

I think you are overstating the readiness of drivechains though. I think the optimistic estimate for drivechains to be ready for bitcoin core is a year out from today. More likely the date should be early 2018. Still a lot of work to be done! :-)
It depends on interest, I think. What remains to be done is more easily parallelized, and in some cases (eg smartphone wallets) there are incentives for private individuals and businesses to hustle their part out (merely for reasons of competitiveness).

Also I don't know if I would put a hard fork suggestion in the scaling map. If drivechains are successful they should be viewed as the way we scale -- not hard forking the protocol. Do you still have capacity concerns if drivechains are successful?

I wrote the roadmap to try to be representative of a Core / developer position. I am philosophically against hard forks, but HFs were in the end of the previous roadmap so I felt it should stay. And, I felt that if I decided to unilaterally remove it, it would be perceived as excessive campaigning for Drivechain. And I also felt that to remove it, when so many industry members recently put their weight behind a fast hard fork, would be perceived as a reaction to that attempt, and would then overwhelm the document with political polarization, for really no benefit.

Paul


-Chris

On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Summary
=========

In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
crucial ways. One success was that it synchronized the entire Bitcoin
community, helping to bring finality to the (endless) conversations of
that time, and get everyone back to work. However, I feel that the Dec
7, 2015 roadmap is simply too old to serve this function any longer. We
should revise it: remove what has been accomplished, introduce new