path: root/7f/0b42bd89c2572730d062e790404bccbbb84857

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--