Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

On Mon, Jul 17, 2017 at 02:49:22PM -0400, Alex Morcos via bitcoin-dev wrote: > "it was ACKed by everyone else that I heard from" - I don't think you > should read into that much. > > I felt like this whole conversation was putting the cart before the horse. > You might very well have some good

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

On 7/17/2017 5:47 PM, David A. Harding wrote: > On Mon, Jul 17, 2017 at 01:13:30PM -0400, Paul Sztorc via bitcoin-dev wrote: >> However, without interest from the maintainers of bitcoincore.org >> (specifically these [3, 4] pages and similar) the document will probably >> be unable to gain

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

"it was ACKed by everyone else that I heard from" - I don't think you should read into that much. I felt like this whole conversation was putting the cart before the horse. You might very well have some good ideas in your roadmap update, to tell you the truth, I didn't even read it. But I don't

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

Hello, Last week I posted about updating the Core Scalability Roadmap. I'm not sure what the future of it is, given that it was concept NACK'ed by Greg Maxwell the author of the original roadmap, who said that he regretted writing the first one. Nonetheless, it was ACKed by everyone else that I

Re: [bitcoin-dev] Updating the Scaling Roadmap

That's a fair point, I confused anyone-can-spend with anyone-can-pay [1]. Isn't it different in the case of P2SH and SegWit, don't full nodes validate the script? In other words, miners don't have complete control over the coins, full nodes keep a check on them. At least that was my

Re: [bitcoin-dev] Updating the Scaling Roadmap

You guys are both right that it is a different security model, with the important distinction that it is opt-in. What I disagree with about what you said is only that we are encouraging more risky behavior by adding consensus rules via softfork. There are additional risks with drivechains, but not

Re: [bitcoin-dev] Updating the Scaling Roadmap

> I think Paul has been pretty upfront about the risks of his model. I think he has been rather misleading in his presentation of the risks. He outlines them in a very technical manner, yes, but then goes on to promote them to lay people as if they're no big deal, which is completely

Re: [bitcoin-dev] Updating the Scaling Roadmap

Hi Greg, The safest way to ensure everyone's protection to make sure *no one can do anything*. Then we will ALL be safe ;). >If so, please leave, you are compromising Bitcoin's security. Ok, let's calm down. >If I design a car that has a button that randomly causes the brakes to give out if

Re: [bitcoin-dev] Updating the Scaling Roadmap

Dear Chris, > I think this is an unfair characterization. You have to opt into using > drivechains. I have heard this nonsense repeated countless times in order to justify adopting Drivechain. This is not how security works. A child can "opt-in" to using a loaded gun, but is it a good idea

Re: [bitcoin-dev] Updating the Scaling Roadmap

Hi Greg, >Here, you admit that the security of the sidechains allows miners to steal bitcoins, something they cannot do currently. If I put my coins in an anyone can spend output, a miner will take them. They can do this today. I suggest you try it if you don't believe me :-). You have to be

Re: [bitcoin-dev] Updating the Scaling Roadmap

On Wednesday, 12 July 2017 03:22:59 CEST Karl Johan Alm via bitcoin-dev wrote: > Bitcoin development differs from Linux kernel development in a number > of obvious ways, such as the fact Bitcoin is being "patched in > flight". I've heard this before and it doesn't make any sense to me. Just like

Re: [bitcoin-dev] Updating the Scaling Roadmap

Just a quick note in favor of an updated roadmap (some may object to that label, but I think it's fine). When you and your friends are planning your weekly movie outing, it's very helpful to have someone who knows the group, knows what films are playing, checks people's preferences, mails around

Re: [bitcoin-dev] Updating the Scaling Roadmap

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"

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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,

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

> 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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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/

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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

Re: [bitcoin-dev] Updating the Scaling Roadmap

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