Paul,
There is a difference between replying to an email, and addressing the issues
that were brought up in it.
I did read your reply, and I chose not to respond to it because it did not
address anything I said.
Here's an example:
> It would not be accurate to say that miners have "total" con
On Wed, Jul 12, 2017 at 1:40 AM, Paul Sztorc wrote:
> Separately, and very important to me, is that you feel that there are
> unresolved objections to drivechain's security model, which you decline
> to share with me and/or the list. So I would hope that you instead
> choose to share your thoughts
On Tue, Jul 11, 2017 at 8:40 PM, Paul Sztorc via bitcoin-dev
wrote:
> it, etc. But I am not willing to press the issue. Some of your other
> comments I also find confusing but there is little to be gained in
> clarifying them. )
To me it looked as if I was reading an email that was making a bunch
Greg,
I would summarize your email as stating that: you regret writing the
first email, and regret the fact that it became a roadmap that everyone
signed. And that therefore it is obviously a concept NACK from you.
( That's pretty surprising to me, and I would expect others to find it
surprising
On Monday 10 July 2017 11:50:33 AM Sergio Demian Lerner via bitcoin-dev wrote:
> Regarding the timeline, its certainly rather short, but also is the UASF
> BIP 148 ultimatum.
BIP148 began with 8 months lead time, reduced to 5 months from popular request
and technical considerations. There is noth
On Wed, Jul 12, 2017 at 6:11 AM, Gregory Maxwell via bitcoin-dev
wrote:
> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
> and release process once the basic technology is done; because it's
> only past that point that guarantees can really start being made.
Bitcoin develo
On 7/11/2017 5:31 PM, Gregory Maxwell wrote:
> On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
> wrote:
>> I wrote the roadmap to try to be representative of a Core / developer
>> position.
> A fine intention, but I've checked with many of the top contributors
> and it sounds like the
On 7/11/2017 7:12 PM, Tao Effect wrote:
> Paul,
>
> There is a difference between replying to an email, and addressing the
> issues that were brought up in it.
>
> I did read your reply, and I chose not to respond to it because it did
> not address anything I said.
In that case you should clarify,
On Tue, Jul 11, 2017 at 10:17 PM, Paul Sztorc wrote:
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.
That might be your impression, then you've misunderstood what I
intended-- What I wrote was carefully constructed as a pe
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
I can't help but notice that I have read Greg's email before-- all the
way back in 2016. It would have been impossible for him to write a
reply to Paul's current email back then... but I also notice that Greg
did not indicate that he was copy-pasting until the very end (and even
then his aside at t
On 7/11/2017 6:41 PM, Tao Effect wrote:
> Dear Paul,
>
> Drivechain has several issues that you've acknowledged but have not,
> IMO, adequately (at all really) addressed [1].
I replied to your email at length, at [2]. You should read that email,
and then reply to it with your outstanding objection
On 7/11/2017 5:40 PM, Pieter Wuille wrote:
> On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc wrote:
>> Pieter,
>>
>> I think that you have misrepresented Chris' view by taking it out of
>> context. His complete quote reads "If drivechains are successful they should
>> be viewed as the way we scale --
Dear Paul,
Drivechain has several issues that you've acknowledged but have not, IMO,
adequately (at all really) addressed [1].
I think there are far safer solutions for scaling Bitcoin and integrating it
with other chains than DC, which is again, a serious security risk to the whole
network, a
Hi Greg,
On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
> I think it's great that people want to experiment with things like
> drivechains/sidechains and what not, but their security model is very
> distinct from Bitcoin's and, given the current highly centralized
> mining ecosystem, arguably not v
> I think it's great that people want to experiment with things like
> drivechains/sidechains and what not, but their security model is very
> distinct from Bitcoin’s
Agree that experimentation is great and that it is usually the case that the
security model differs.
Isn’t it also true also that
On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc wrote:
> Pieter,
>
> I think that you have misrepresented Chris' view by taking it out of
> context. His complete quote reads "If drivechains are successful they should
> be viewed as the way we scale -- not hard forking the protocol." Chris is
> compar
On Tue, Jul 11, 2017 at 9:11 PM, Gregory Maxwell wrote:
> which I have included here a private email
> thread on the subject
To make it clear, since I munged the English on this: Most of my post
is just copied straight out of a private thread where I explained my
perspective on 'roadmaps' as they
On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
wrote:
> I wrote the roadmap to try to be representative of a Core / developer
> position.
A fine intention, but I've checked with many of the top contributors
and it sounds like the only regular developer you spoke with was
Luke-Jr. N
I think it's great that people want to experiment with things like
drivechains/sidechains and what not, but their security model is very
distinct from Bitcoin's and, given the current highly centralized
mining ecosystem, arguably not very good. So positioning them as a
major solution for the Bitco
If users can opt-in to another security model, why can't they opt-in to
another scaling model? The mainchain (Bitcoin) does not have to adopt
any of the changes made to a sidechain such as larger blocks for example.
On 07/11/2017 01:01 PM, Pieter Wuille via bitcoin-dev wrote:
> On Jul 11, 2017 09
Separate from scale, there is utility to a hard-fork to fix wish-list
bugs that cant be reasonably fixed via soft-fork. The spoonnet
proposal fixes a good number of interesting bugs. Spoonnet and
several other HF research proposals can be found here
https://bitcoinhardforkresearch.github.io/ Par
Pieter,
I think that you have misrepresented Chris' view by taking it out of
context. His complete quote reads "If drivechains are successful they
should be viewed as the way we scale -- not hard forking the protocol."
Chris is comparing Drivechains/sidechains to a hard fork.
You went on to "disa
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
On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Concept ACK.
If drivechains are successful they should be viewed as the way we scale
I strongly disagree with that statement.
Drivechains, and several earlier sidechains ideas, are not a scal
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! :-)
Also I don't know if I would put a ha
On Mon, Jul 10, 2017 at 1:50 PM, Sergio Demian Lerner via bitcoin-dev
wrote:
> Regarding the timeline, its certainly rather short, but also is the UASF BIP
> 148 ultimatum.
This is correct. If you are trying to imply that makes the short
timeline here right, you are falling for a "tu quoque" fall
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 De
28 matches
Mail list logo
