Paul Sztorc [ARCHIVE] on Nostr: 📅 Original date posted:2017-07-11 📝 Original message:Hi Chris, On 7/11/2017 ...
📅 Original date posted:2017-07-11
📝 Original message: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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/6b8452e0/attachment.html>;
📝 Original message: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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/6b8452e0/attachment.html>;