summaryrefslogtreecommitdiff
path: root/7f/0b42bd89c2572730d062e790404bccbbb84857
blob: 209a9edaf8095f1b398a52f7e4d0de9eef1f773a (plain)
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
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DFFF910E0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 30 Aug 2015 04:13:49 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 96175E2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 30 Aug 2015 04:13:48 +0000 (UTC)
Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx003)
	with ESMTPSA (Nemesis) id 0M4002-1YeU4A1vSU-00rWs4;
	Sun, 30 Aug 2015 06:13:45 +0200
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D2382AC9-B51D-4EEA-B69A-48FCE09E3353"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <CAAS2fgRs5NVM2nHKNXbgMJa51tDq-6ZBc6XfaScyP45UPWTW_g@mail.gmail.com>
Date: Sat, 29 Aug 2015 21:13:43 -0700
Message-Id: <5CC48639-11D0-4682-BF82-443286C8E58D@gmx.com>
References: <CAEgR2PFB3h_8fr=d8HegRSD0XdooimhFKtLR4vKr2QXv+EwBfQ@mail.gmail.com>
	<AD284610-4F40-445C-A074-CC94EDFFCBA8@gmx.com>
	<CAAS2fgRs5NVM2nHKNXbgMJa51tDq-6ZBc6XfaScyP45UPWTW_g@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V03:K0:lkYzyNYjELn3LFzyvKadtmiEnIn1+k470xbBOYqX0oPXGYPiu4A
	LebMmx1tL5qZh89RmjyOEK53k/F7UyGf2EPcqTIb7WdaDdVgLzOGjX2hEZoUGifls5tqUNW
	kTspMrct2scNJ9ai0CwzpnhZCmcoIXILGSY/7Hnoz822eA9ShkBTR+ZW+bKL+yswb7bPE+Z
	IF7ZpyVDCwJrptIkaHVYA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:PMdIymgmSGc=:Ojp+BUuzLcuKoxfcTotPna
	hGUxAe0bd/tF975Os4OqfCmoHF/1Tt0ld4ncrckSKyNlo1uqE78dFDazXHgJ3TPVzAR1AAM+4
	MR91TExsi8onOxtqg6ecyB07dJbZ+FS3+ZyOztnGDIH1WnGrh8L4QClZD1K1UI3AkoRAp+v0U
	liqFOHhuV0/cSi0pG3OeC4R8ajoTrzTW2PgVI0vfXpCRrdRhZ6+Lub3AJM1+9cATvigqwUYdW
	6qAH0lDgWLgXeQhG1S0EVnJb0ex4NRV1tulJTGl5ZIWZv7sgNYPdphchCbWMBvOKTy09+6bRK
	3DfVFULq2jG8PDvv3lMedpltBZBQg9QGQjaGPXcFcLMqIqJ3Yr/j3srbhVNG2eL5rQxOzCh2/
	qMDhf9c08NIhvzIW9HcSMHAL+mnOFbZH1aVGDzbXx/DplorZCuvpWcDfCjmbgd6f6B7fCvKB1
	fQ3l5MoQrlBLQVWtAOJAv3LXGEae7ygMAlloQLM0s/EFFtJK0itsNi8z8SCtSgr2HJlPbcUbN
	2+wnm0JKTaqN+bFgqzGdgntyXMX3R0j3uY1QUDlk5VciynZ4duS+PwbwBHimDpzZTHadxS7PX
	wB6O/L7by5+/7n28nW9GeNVxXcDFswzHFtsI6+7Eq34jK19g/HighjrJsFfCtCuwQE5wX6T+9
	EVV93vl0OquzVqST0zviIvaIGBDj9jPTLEi1qHFY4aUxXBd5wsNjUQYgu0OwdMFWn6KqV9G3P
	euXfEdLyiUnxuNvWnpkXy9fL173pRPcrNMwvrA==
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	HTML_MESSAGE,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
Cc: "bitcoin-dev@lists.linuxfoundation.org Dev"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Your Gmaxwell exchange
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sun, 30 Aug 2015 04:13:50 -0000


--Apple-Mail=_D2382AC9-B51D-4EEA-B69A-48FCE09E3353
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi Greg,

> Unfortunately, your work extensive as it was made at least two
> non-disclosed or poorly-disclosed simplifying assumptions and a =
significant
> system understanding error which, I believe, undermined it completely.
>=20
> In short these were:
>=20
> * You assume miners do not have the ability to change their level
> centralization.
>=20
> -- In fact they do, not just in theory but in pratice have responded
>    to orphaning this way in the past; and it is one of the major
>    concerns in this space.

I agree that miners may change their level of centralization.  This =
neither affects the model nor the results presented in the paper.

> * You assume the supply of bitcoin is infinite (that subsidy never
> declines)
>=20
> -- It declines geometrically, and must if the 21m limit is to be =
upheld.
>    (Though I think this is not equally important as the other =
concerns)

No I don't.  I assume the inflation rate is R/T, where R is a variable. =20=


The last paragraph of the conclusion speaks to the paradox of what =
happens when R -> 0 as an area for future research.=20


> * You argue, incorrectly, that amount of information which must be
> transmitted at the moment a block is discovered is proportional to the
> block's size.
>=20
> -- Instead the same information can be transmitted _in advance_, as
> has been previously proposed, and various techniques can make doing
> so arbitrarily efficient.

I assume, very reasonably, that the block solutions contain information =
about the transactions included in the block.  This is the case today, =
this is the case using the relay network, and this would be the case =
using any compression scheme I can personally imagine actually occurring =
in the future. =20

(I've always agreed that if block solutions can be communicated to all =
of the hash power in such a way that they don't include any information =
about the transactions they contain, then the conditions for a healthy =
fee market would not be met [this would be gamma --> infinity in my =
model]).=20


> [I would encourage anyone who is interested to read the posted =
off-list
> discussion]

As would I. =20

> I contacted you in private as a courtesy in the hope that it would be
> a more productive pathway to improving our collective understanding; =
as well
> as a courtesy to the readers of the list in consideration of traffic =
levels.

I appreciated the discussion we were having and I thought we had come to =
some kind of an understanding.  I acknowledged that when I made the =
other corrections to my paper that I would further clarify the =
assumptions (I agreed that the presentation could be improved).     =20

What was not courteous was that you forwarded the entire private email =
chain to other people without my permission.

> In one sense, this was a success: Our conversation concluded with you
> enumerating a series of corrective actions that you would take:
>=20
> --------
>> 1.  I will make it more clear that the results of the paper hinge on
>> the assumption that block solutions are propagated across channels,
>> and that the quantity of pure information communicated per solution
>> is proportional to the amount of information contained within the =
block.
>>=20
>> 2.  I will add a note [unless you ask me not to] something to the =
effect
>> of "Greg Maxwell challenges the claim that the coding gain cannot
>> be infinite=85" followed by a summary of the scenario you described.
>> I will reference "personal communication."  I will also run the note
>> by you before I make the next revision public.
>>=20
>> 3.  I will point out that if the coding gain can be made =
spectacularly
>> high, that the propagation impedance in my model will become very =
small,
>> and that although a fee market may strictly exist in the asymptotic
>> sense, such a fee market may not be relevant (the phenomena in the =
paper
>> would be negligible compared to the dynamics from some other effect).
>>=20
>> 4. [UNRELATED] I also plan to address Dave Hudson's objections in my
>> next revision (the "you don't orphan your own block" point).
>>=20
>> Lastly, thank you for the note about what might happen when fees >
>> rewards.  I've have indeed been thinking about this.  I believe it is
>> outside the scope of the present paper, although I am doing some work
>> on the topic.  (Perhaps I'll add a bit more discussion on this topic
>> to the present paper to get the reader thinking in this direction).

I stand by all of these four points.  My paper wasn't perfectly =
presented.  Making these clarifications will strengthen the manuscript =
by showing how strong the claim "a healthy transaction fee market exists =
without a block size limit" is. =20


> To the best of my knowledge, you've taken none of these corrective
> actions in the nearly month that has passed.  I certainly understand =
being
> backlogged, but you've also continued to make public comments about =
your
> work seemingly (to me) in contradiction with the above corrective =
actions.

My public comments have been factual.  I've even gone out of my way in =
several public threads to point out your objection that the coding gain =
could be zero (even though I think it is flawed "black-and-white =
thinking" about an academic scenario that will never unfold and might =
actually be physically impossible without Bitcoin already being =
centralized).

I'll end by saying that I am the one describing things as the presently =
are.  You are talking about a hypothetical future that may or may not =
exist (and may not even be possible).  The results of my paper logically =
follow from the assumptions made. You think the assumption that "block =
solutions contain information about the transactions included in the =
block" will not hold in the future.  Can you show:

(a) Under what assumptions/requirements your communication scheme is =
physically possible.

(b) That such a configuration is not equivalent to a single entity[1] =
controlling >50% of the hash power.

(c) That the network moving into such a configuration is plausible.

Best regards,
Peter





--Apple-Mail=_D2382AC9-B51D-4EEA-B69A-48FCE09E3353
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>Hi Greg,</div><div><br><blockquote type=3D"cite">Unfortunately, =
your work extensive as it was made at least two<br>non-disclosed or =
poorly-disclosed simplifying assumptions and a significant<br>system =
understanding error which, I believe, undermined it =
completely.</blockquote><blockquote type=3D"cite"><br>In short these =
were:<br><br>* You assume miners do not have the ability to change their =
level<br>centralization.<br><br> -- In fact they do, not just in theory =
but in pratice have responded<br> &nbsp;&nbsp;&nbsp;to orphaning this =
way in the past; and it is one of the major<br> =
&nbsp;&nbsp;&nbsp;concerns in this =
space.<br></blockquote><div><br></div>I agree that miners may change =
their level of centralization. &nbsp;This neither affects the model nor =
the results presented in the paper.</div><div><br><blockquote =
type=3D"cite">* You assume the supply of bitcoin is infinite (that =
subsidy never<br>declines)<br><br> -- It declines geometrically, and =
must if the 21m limit is to be upheld.<br> &nbsp;&nbsp;&nbsp;(Though I =
think this is not equally important as the other =
concerns)<br></blockquote><div><br></div><div>No I don't. &nbsp;I assume =
the inflation rate is R/T, where R is a variable. =
&nbsp;</div><div><br></div><div>The last paragraph of the conclusion =
speaks to the paradox of what happens when R -&gt; 0 as an area for =
future research.&nbsp;</div><div><br></div><div><br></div><blockquote =
type=3D"cite">* You argue, incorrectly, that amount of information which =
must be<br>transmitted at the moment a block is discovered is =
proportional to the<br>block's size.<br><br> -- Instead the same =
information can be transmitted _in advance_, as<br> has been previously =
proposed, and various techniques can make doing<br> so arbitrarily =
efficient.<br></blockquote><div><br></div><div>I assume, very =
reasonably, that the block solutions contain information about the =
transactions included in the block. &nbsp;This <i>is</i> the case today, =
this <i>is</i> the case using the relay network, and this would be the =
case using any compression scheme I can personally imagine actually =
occurring in the future. &nbsp;</div><div><br></div><div>(I've =
<i>always</i> agreed that if block solutions can be communicated to all =
of the hash power in such a way that they don't include any information =
about the transactions they contain, then the conditions for a healthy =
fee market would not be met [this would be gamma --&gt; infinity in my =
model]).&nbsp;</div><div><br></div><div><br></div><blockquote =
type=3D"cite">[I would encourage anyone who is interested to read the =
posted off-list<br>discussion]<br></blockquote><div><br></div>As would =
I. &nbsp;</div><div><br><blockquote type=3D"cite">I contacted you in =
private as a courtesy in the hope that it would be<br>a more productive =
pathway to improving our collective understanding; as well<br>as a =
courtesy to the readers of the list in consideration of traffic =
levels.<br></blockquote><div><br></div><div>I appreciated the discussion =
we were having and I thought we had come to some kind of an =
understanding. &nbsp;I acknowledged that when I made the other =
corrections to my paper that I would further clarify the assumptions (I =
agreed that the presentation could be improved). &nbsp; &nbsp; =
&nbsp;</div><div><br></div><div><b>What was not courteous was that you =
forwarded the entire private email chain to other people without my =
permission.</b></div><div><br></div><blockquote type=3D"cite">In one =
sense, this was a success: Our conversation concluded with =
you<br>enumerating a series of corrective actions that you would =
take:<br><br>--------<br><blockquote type=3D"cite">1. &nbsp;I will make =
it more clear that the results of the paper hinge on<br>the assumption =
that block solutions are propagated across channels,<br>and that the =
quantity of pure information communicated per solution<br>is =
proportional to the amount of information contained within the =
block.<br><br>2. &nbsp;I will add a note [unless you ask me not to] =
something to the effect<br>of "Greg Maxwell challenges the claim that =
the coding gain cannot<br>be infinite=85" followed by a summary of the =
scenario you described.<br>I will reference "personal communication." =
&nbsp;I will also run the note<br>by you before I make the next revision =
public.<br><br>3. &nbsp;I will point out that if the coding gain can be =
made spectacularly<br>high, that the propagation impedance in my model =
will become very small,<br>and that although a fee market may strictly =
exist in the asymptotic<br>sense, such a fee market may not be relevant =
(the phenomena in the paper<br>would be negligible compared to the =
dynamics from some other effect).<br><br>4. [UNRELATED] I also plan to =
address Dave Hudson's objections in my<br>next revision (the "you don't =
orphan your own block" point).<br><br>Lastly, thank you for the note =
about what might happen when fees &gt;<br>rewards. &nbsp;I've have =
indeed been thinking about this. &nbsp;I believe it is<br>outside the =
scope of the present paper, although I am doing some work<br>on the =
topic. &nbsp;(Perhaps I'll add a bit more discussion on this topic<br>to =
the present paper to get the reader thinking in this =
direction).<br></blockquote></blockquote><div><br></div><div>I stand by =
all of these four points. &nbsp;My paper wasn't perfectly presented. =
&nbsp;Making these clarifications will strengthen the manuscript by =
showing how strong the claim "a healthy transaction fee market exists =
without a block size limit" is. =
&nbsp;</div><div><br></div><div><br></div><blockquote type=3D"cite">To =
the best of my knowledge, you've taken none of these =
corrective<br>actions in the nearly month that has passed. &nbsp;I =
certainly understand being<br>backlogged, but you've also continued to =
make public comments about your<br>work seemingly (to me) in =
contradiction with the above corrective =
actions.<br></blockquote></div><br><div>My public comments have been =
factual. &nbsp;I've even gone out of my way in several public threads to =
point out your objection that the coding gain could be zero (even though =
I think it is flawed "black-and-white thinking" about an academic =
scenario that will never unfold and might actually be physically =
impossible without Bitcoin already being =
centralized).</div><div><br></div><div>I'll end by saying that I am the =
one describing things as the <i>presently are</i>. &nbsp;You are talking =
about a hypothetical future that may or may not exist (and may not even =
be possible). &nbsp;The results of my paper logically follow from the =
assumptions made.&nbsp;You think the assumption that "block solutions =
contain information about the transactions included in the block" will =
not hold in the future. &nbsp;Can you =
show:</div><div><div><br></div><div>(a) Under what =
assumptions/requirements your communication scheme is physically =
possible.</div><div><br></div><div>(b) That such a configuration is not =
equivalent to a single entity[1] controlling &gt;50% of the hash =
power.</div><div><br></div><div>(c) That the network moving into such a =
configuration is plausible.</div></div><div><br></div><div>Best =
regards,</div><div>Peter</div><div><br></div><div><br></div><div><br></div=
><div><br></div></body></html>=

--Apple-Mail=_D2382AC9-B51D-4EEA-B69A-48FCE09E3353--