1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
|
Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 741993EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 22:17:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com
[209.85.216.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 831C2FE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 22:17:18 +0000 (UTC)
Received: by mail-qt0-f179.google.com with SMTP id 32so5150711qtv.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Jul 2017 15:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding:content-language;
bh=rNAN+BDQEU5w66j6UFC5Epdo8eUZ2yBXAeCJKxZt3Ys=;
b=FGN96ky0G7TN/js8mi6Cgb6kEhjqiw3nYTrpdTsDvx0iRWMfMz/I5HZEGaEL1eiVqq
WyirctohMXtKuzbVyt0KTbk+i9r3MHOTcgf3HjtxqpiMuM0+QgneG+sWN+GSXu8zvTAq
2Qj3KZA55mJcQQENwwHUOMkCSFayg3YaAuUrdW1I29gZv9sS2/yHwH2mAtZL63iCPKFq
quA2y5Dx/Zz4Juh3LTJw5SWiGjDyKW7LOqcqkHSpgdyRoy1JJaxnBERabEefSCgKU/xp
/oIZq23iZJTstJLFCQ0AB31aTEZOpiisXsgt0RakcK9oPnAJE/IXhFqznriF2CTj5Id6
WLjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding
:content-language;
bh=rNAN+BDQEU5w66j6UFC5Epdo8eUZ2yBXAeCJKxZt3Ys=;
b=T120j/OPJ9Tvj+1cmEt3Br3rQNpSoQImOGN9U7y1kS5P2vUkugotXRcRI+aMjVAVI9
ctClAmgNmlEcOz4CFcUIBT5ZvzORo40DvcQbR+wIz6Vg2AkgTujNHNe+ws3tSHQNk4GM
RFb22GDaV1/QWimQbgZ16m8PKlM/SX5JwvutAa6WDAXxh4/xlK76As+MTQoTtdnGuCMs
DLr7YkiLuuF5xpgd5I51IgUgNC/qrJB4wTuwWR+lxhaOgCWKLdbhZUHeU4Ic+2zCGVkR
o83lbnCl4R7tn1uUSVLK892EufKnYO0lFdb9E88zQ1uprnWU8mnjtvr+MC5ZCXE4Z5/E
NwaQ==
X-Gm-Message-State: AIVw113CdLHN0HsEm40NrnUU90QgGp+BSkXFXK1P/y3pC4BJD13F98Ce
nx4cpOta5yOKmFwV
X-Received: by 10.237.47.39 with SMTP id l36mr2813233qtd.181.1499811437212;
Tue, 11 Jul 2017 15:17:17 -0700 (PDT)
Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net.
[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
d14sm433600qtc.58.2017.07.11.15.17.15
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 11 Jul 2017 15:17:15 -0700 (PDT)
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
Date: Tue, 11 Jul 2017 18:17:19 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 11 Jul 2017 22:29:43 +0000
Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jul 2017 22:17:19 -0000
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=20
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 wa=
s
> 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 publishe=
d
> 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 mar=
s.
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 insec=
ure,
> patent encumbered, or practically useless... (It won't be but no one co=
uld
> tell that from your post; because it doesn't even exist as a concrete p=
roposal)
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-- e=
specially
> 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,=20
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 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/
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
|
