From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DFFF910E0 for ; 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 ; 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 In-Reply-To: Date: Sat, 29 Aug 2015 21:13:43 -0700 Message-Id: <5CC48639-11D0-4682-BF82-443286C8E58D@gmx.com> References: To: Gregory Maxwell 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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.

In short these = were:

* You assume miners do not have the ability to change their = level
centralization.

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

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

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


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

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

(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]). 


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

As would = I.  

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).     =  

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:

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

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.

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

4. [UNRELATED] I also plan to = address Dave Hudson's objections in my
next revision (the "you don't = orphan your own block" point).

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


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