Re: [bitcoin-dev] Your Gmaxwell exchange

[Peter R <peter_r@gmx.com>]

[-- Attachment #1: Type: text/plain, Size: 6099 bytes --]

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





[-- Attachment #2: Type: text/html, Size: 7360 bytes --]