Tao Effect [ARCHIVE] on Nostr: 📅 Original date posted:2017-07-11 📝 Original message:Dear Paul, Drivechain has ...
📅 Original date posted:2017-07-11
📝 Original message: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, as per [1].
Adopting DC would be an irreversible course of action, and one that in my opinion would unnecessarily damage not only other sidechains, but the main chain as well.
There is no rush, a proper solution is likely to present itself (I even have one that I'm toying with, but it's not quite ready yet for publication). I'm sure others are thinking similar thoughts too.
Kind regards,
Greg Slepak
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html>;
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jul 11, 2017, at 3:17 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> 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 very good. So positioning them as a
>> major solution for the Bitcoin project is the wrong way to go. Instead
>> we should support people trying cool stuff, at their own risk.
>>
>> So, given that although the vast majority of the things in the document
>> are things I've been supporting for months (Please see Note 1 way down
>> at the bottom) I cannot support your document.
> Is this the only reason you do not support the document? If so I would
> be happy to take out the section, if enough people share such a view.
>
> As to your specific complaints, I have addressed both the security model
> and the concept of mining centralization on this list in the recent
> past. I would like to hear your responses to my claims, if you are
> willing to share them. As for positioning DC as a major solution, it is
> a little confusing because Luke-Jr and Adam back seem to feel it is at
> least worth discussing on those terms (and I know of no reason why it
> would not be discussed on those terms). The peer review here on
> [bitcoin-dev] seemed to be moving forward without any serious
> objections. And it seems unsportsmanlike for you to object, for reasons
> which you keep only to yourself.
>
>
>> On a more meta-subject, I think grandly stated "top down" roadmaps
>> in highly collaborative development are of minimal utility at best
> I'm aiming for minimal utility.
>
>> 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.
>>
>> But that isn't what your document does-- it names a lot of things which
>> are still various shades of research at this point
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.
>
>> This was an incredible benefit to our customers, but the only way it was
>> possible was because _features_ were not guaranteed in a release.
> No one is suggesting that features be guaranteed, either ever or in
> releases.
>
>
>> One of the big screwups with segwit handling was people sticking
>> some random unrealistic date on it it which was done AFAIK,
>> by well meaning folks who took some random numbers from people
>> working on it for when they'd be done with the development-- not the
>> testing, not the integration, and certainly not deployment and published
>> it as The Date. Then even though the development was actually done
>> by them, segwit was portrayed as massively delayed, because what
>> matters to the users is deployment-- which we can't control.
> I really don't think they are related. For a start, software is almost
> always delayed. An obvious second is that this entire scaling
> conversation is polarized to the hilt and everyone that can be blamed
> for something has been blamed for something.
>
> No one likes to be held to a certain deadline, but this roadmap is just
> about producing some clarity for people who do not do this 24/7.
>
>> I see you've done this yourself with signature aggregation, sticking Q4 2016
>> right on it, which as far as I can tell is a figure that comes from mars.
> I asked Adam Back for it.
>
>> It's also not really appropriate to ask people to sign onto stuff when they
>> can't even review it. Perhaps the signature aggregation stuff is insecure,
>> patent encumbered, or practically useless... (It won't be but no one could
>> tell that from your post; because it doesn't even exist as a concrete proposal)
> Again, I think you're missing the point. If there is a problem with SA,
> you can just suggest it be removed from the document.
>
>
>> I think people would rightly protest about a number of these things-- especially
>> things like the the agg sigs and tx compaction, "wtf, I've not heard
>> of this. Who
>> are you to insist this goes into Bitcoin?"
> This is a very strange argument. I would consider it a benefit if people
> learned from the document, and discovered things that they had not heard
> of before.
>
> There is no "insisting" of any kind.
>
>
>> [ Note 1: I think it is important to disclose that several of the
>> items in this list appear to be more or less quoted out of my own
>> blockstream-internal descriptions of things we've been working on in
>> Bitcoin.
>> A while back Adam Back asked me to publish something which contained
>> significant chunks of this document more or less verbatim,
> He probably showed you an earlier draft. But I wrote almost all of this
> myself, and I can only recall 2 or 3 phrases (not even complete
> sentences) included from Adam Back. And most of the phrases are
> themselves just boring descriptions that I'm sure anyone could write.
> Some phrases may have simply been taken from bitcoincore.org <http://bitcoincore.org/>; or
> somewhere similar.
>
> I am not exactly sure what you are insinuating but I encourage you to
> clarify it.
>
>> and I
>> declined saying that I personally disagree with some of his points and
>> didn't think that Blockstream attempting to redirect the Bitcoin
>> project (esp towards drivechains) was appropriate-- along with my
>> (above) views on roadmaps (which I have included here a private email
>> thread on the subject). I feel it's important to disclose this, and
>> that the document was not otherwise created with the input of project
>> contributors (except Luke-Jr, apparently). I wasn't previously aware
>> that Adam had been working with Paul on this, had I been I would have
>> also encouraged people to be a little more transparent about it. ]
> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not
> enough experts were asked for feedback on the draft? I'm legitimately
> confused by this part.
>
> As I stated, we can remove the drivechain section. But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as "the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire time?
> One wonders why you haven't said anything until now.
>
> [1] https://bitcoincore.org/en/2015/12/21/capacity-increase/ <https://bitcoincore.org/en/2015/12/21/capacity-increase/>;
>
> In my first email I list the benefits of having a roadmap. One benefit
> is that, without one, it is likely that a large majority of outsiders
> have almost no idea at all what is being worked on, what effect it will
> have, or when it might be ready, or to whom/what they should turn to for
> advice on such matters. Do you have a different way of addressing this
> communication problem?
>
> Paul
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/386bfc83/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/386bfc83/attachment-0001.sig>;
📝 Original message: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, as per [1].
Adopting DC would be an irreversible course of action, and one that in my opinion would unnecessarily damage not only other sidechains, but the main chain as well.
There is no rush, a proper solution is likely to present itself (I even have one that I'm toying with, but it's not quite ready yet for publication). I'm sure others are thinking similar thoughts too.
Kind regards,
Greg Slepak
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html>;
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jul 11, 2017, at 3:17 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> 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 very good. So positioning them as a
>> major solution for the Bitcoin project is the wrong way to go. Instead
>> we should support people trying cool stuff, at their own risk.
>>
>> So, given that although the vast majority of the things in the document
>> are things I've been supporting for months (Please see Note 1 way down
>> at the bottom) I cannot support your document.
> Is this the only reason you do not support the document? If so I would
> be happy to take out the section, if enough people share such a view.
>
> As to your specific complaints, I have addressed both the security model
> and the concept of mining centralization on this list in the recent
> past. I would like to hear your responses to my claims, if you are
> willing to share them. As for positioning DC as a major solution, it is
> a little confusing because Luke-Jr and Adam back seem to feel it is at
> least worth discussing on those terms (and I know of no reason why it
> would not be discussed on those terms). The peer review here on
> [bitcoin-dev] seemed to be moving forward without any serious
> objections. And it seems unsportsmanlike for you to object, for reasons
> which you keep only to yourself.
>
>
>> On a more meta-subject, I think grandly stated "top down" roadmaps
>> in highly collaborative development are of minimal utility at best
> I'm aiming for minimal utility.
>
>> 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.
>>
>> But that isn't what your document does-- it names a lot of things which
>> are still various shades of research at this point
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.
>
>> This was an incredible benefit to our customers, but the only way it was
>> possible was because _features_ were not guaranteed in a release.
> No one is suggesting that features be guaranteed, either ever or in
> releases.
>
>
>> One of the big screwups with segwit handling was people sticking
>> some random unrealistic date on it it which was done AFAIK,
>> by well meaning folks who took some random numbers from people
>> working on it for when they'd be done with the development-- not the
>> testing, not the integration, and certainly not deployment and published
>> it as The Date. Then even though the development was actually done
>> by them, segwit was portrayed as massively delayed, because what
>> matters to the users is deployment-- which we can't control.
> I really don't think they are related. For a start, software is almost
> always delayed. An obvious second is that this entire scaling
> conversation is polarized to the hilt and everyone that can be blamed
> for something has been blamed for something.
>
> No one likes to be held to a certain deadline, but this roadmap is just
> about producing some clarity for people who do not do this 24/7.
>
>> I see you've done this yourself with signature aggregation, sticking Q4 2016
>> right on it, which as far as I can tell is a figure that comes from mars.
> I asked Adam Back for it.
>
>> It's also not really appropriate to ask people to sign onto stuff when they
>> can't even review it. Perhaps the signature aggregation stuff is insecure,
>> patent encumbered, or practically useless... (It won't be but no one could
>> tell that from your post; because it doesn't even exist as a concrete proposal)
> Again, I think you're missing the point. If there is a problem with SA,
> you can just suggest it be removed from the document.
>
>
>> I think people would rightly protest about a number of these things-- especially
>> things like the the agg sigs and tx compaction, "wtf, I've not heard
>> of this. Who
>> are you to insist this goes into Bitcoin?"
> This is a very strange argument. I would consider it a benefit if people
> learned from the document, and discovered things that they had not heard
> of before.
>
> There is no "insisting" of any kind.
>
>
>> [ Note 1: I think it is important to disclose that several of the
>> items in this list appear to be more or less quoted out of my own
>> blockstream-internal descriptions of things we've been working on in
>> Bitcoin.
>> A while back Adam Back asked me to publish something which contained
>> significant chunks of this document more or less verbatim,
> He probably showed you an earlier draft. But I wrote almost all of this
> myself, and I can only recall 2 or 3 phrases (not even complete
> sentences) included from Adam Back. And most of the phrases are
> themselves just boring descriptions that I'm sure anyone could write.
> Some phrases may have simply been taken from bitcoincore.org <http://bitcoincore.org/>; or
> somewhere similar.
>
> I am not exactly sure what you are insinuating but I encourage you to
> clarify it.
>
>> and I
>> declined saying that I personally disagree with some of his points and
>> didn't think that Blockstream attempting to redirect the Bitcoin
>> project (esp towards drivechains) was appropriate-- along with my
>> (above) views on roadmaps (which I have included here a private email
>> thread on the subject). I feel it's important to disclose this, and
>> that the document was not otherwise created with the input of project
>> contributors (except Luke-Jr, apparently). I wasn't previously aware
>> that Adam had been working with Paul on this, had I been I would have
>> also encouraged people to be a little more transparent about it. ]
> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not
> enough experts were asked for feedback on the draft? I'm legitimately
> confused by this part.
>
> As I stated, we can remove the drivechain section. But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as "the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire time?
> One wonders why you haven't said anything until now.
>
> [1] https://bitcoincore.org/en/2015/12/21/capacity-increase/ <https://bitcoincore.org/en/2015/12/21/capacity-increase/>;
>
> In my first email I list the benefits of having a roadmap. One benefit
> is that, without one, it is likely that a large majority of outsiders
> have almost no idea at all what is being worked on, what effect it will
> have, or when it might be ready, or to whom/what they should turn to for
> advice on such matters. Do you have a different way of addressing this
> communication problem?
>
> Paul
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/386bfc83/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/386bfc83/attachment-0001.sig>;