Your Gmaxwell exchange

Begin forwarded message:

From: Daniele Pinna <daniele.pinna@gmail.com>
Subject: Your Gmaxwell exchange
Date: 29 August, 2015 5:05:33 PM PDT
To: Peter R <peter_r@gmx.com>

Why wouldn't you forward this to me when you've known about me working on extending your work for the past two weeks...

Daniele

---------- Forwarded message ----------
From: "Gregory Maxwell" <gmaxwell@gmail.com>
Date: Aug 29, 2015 10:40 PM
Subject: Fwd: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests
To: "Daniele Pinna" <daniele.pinna@gmail.com>
Cc:


Forwarded conversation
Subject: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests
------------------------

From: Peter R via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Tue, Aug 4, 2015 at 6:40 AM
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>


Dear Bitcoin-Dev Mailing list,

I’d like to share a research paper I’ve recently completed titled “A Transaction Fee Market Exists Without a Block Size Limit.”  In addition to presenting some useful charts such as the cost to produce large spam blocks, I think the paper convincingly demonstrates that, due to the orphaning cost, a block size limit is not necessary to ensure a functioning fee market.

The paper does not argue that a block size limit is unnecessary in general, and in fact brings up questions related to mining cartels and the size of the UTXO set.

It can be downloaded in PDF format here:

https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf

Or viewed with a web-browser here:

https://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit

Abstract.  This paper shows how a rational Bitcoin miner should select transactions from his node’s mempool, when creating a new block, in order to maximize his profit in the absence of a block size limit. To show this, the paper introduces the block space supply curve and the mempool demand curve.  The former describes the cost for a miner to supply block space by accounting for orphaning risk.  The latter represents the fees offered by the transactions in mempool, and is expressed versus the minimum block size required to claim a given portion of the fees.  The paper explains how the supply and demand curves from classical economics are related to the derivatives of these two curves, and proves that producing the quantity of block space indicated by their intersection point maximizes the miner’s profit.  The paper then shows that an unhealthy fee market—where miners are incentivized to produce arbitrarily large blocks—cannot exist since it requires communicating information at an arbitrarily fast rate.  The paper concludes by considering the conditions under which a rational miner would produce big, small or empty blocks, and by estimating the cost of a spam attack.

Best regards,
Peter

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


----------
From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Tue, Aug 4, 2015 at 7:42 AM
To: Peter R <peter_r@gmx.com>


How could you have written at such length and complexity but ignoring
the simple expident miners have of simply centeralizing their
operation around larger pools to lower their costs-- an activity they
previously performed, in practice, not just theory (which was walked
back by handing them more efficient relay mechenisms) and which is
simple, easy, and which reduces those marginal costs to 0 at the limit
(e.g. all miners served off a particular host) --- after I
specifically called you out on this previously?   Doubly so when your
analysis gives provides a framework for analyizing the profitibility
of moving from one point on that income tradeoff graph to another
(e.g. the lost income from failing to centeralize)....
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

----------
From: Peter R <peter_r@gmx.com>
Date: Tue, Aug 4, 2015 at 7:52 AM
To: Gregory Maxwell <gmaxwell@gmail.com>


Hey Greg,

The paper does consider more efficient relaying mechanisms.  This is what I refer to as the "propagation impedance."  Figure 8 shows that the cost of spam blocks decrease considerably with faster block propagation.  The first two simplifying assumptions described in the conclusion (p.13, second paragraph) speak to this further, and the first two "topics for further research" in that same paragraph relate to this as well.

Best regards,
Peter

----------
From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Tue, Aug 4, 2015 at 8:01 AM
To: Peter R <peter_r@gmx.com>


On Tue, Aug 4, 2015 at 7:52 AM, Peter R <peter_r@gmx.com> wrote:
> Hey Greg,
>
> The paper does consider more efficient relaying mechanisms.  This is what I refer to as the "propagation impedance."  Figure 8 shows that the cost of spam blocks decrease considerably with faster block propagation.  The first two simplifying assumptions described in the conclusion (p.13, second paragraph) speak to this further, and the first two "topics for further research" in that same paragraph relate to this as well.

I'm aware--  But "use the same pool" is a seperate modality from "use
more efficient transmission"; for one because if all miners do so (or
technically just a simple majority plus a preference to mine on their
own blocks even if later) then I believe your model would have an
impediance of zero which has very different behavior.  It also already
exists, e.g. doesn't require new technology.  And for any point on
your demand curve you assume the system is operating at, if the size
of blocks can go up, I believe your model shows miners will increase
income by centeralizing (because absent a limit on the supply, a lower
impedance is more profitable).


A more minor point, perhaps I'm missing it, but you don't seem to
analyize the effect of R/T changing on your model. As you know, in
Bitcoin unless the supply of coins is increased R/T is vanishing and
will geometrically become 0.

----------
From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Tue, Aug 4, 2015 at 8:37 AM
To: Peter R <peter_r@gmx.com>


On Tue, Aug 4, 2015 at 8:01 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Tue, Aug 4, 2015 at 7:52 AM, Peter R <peter_r@gmx.com> wrote:
>> Hey Greg,
>>
>> The paper does consider more efficient relaying mechanisms.  This is what I refer to as the "propagation impedance."  Figure 8 shows that the cost of spam blocks decrease considerably with faster block propagation.  The first two simplifying assumptions described in the conclusion (p.13, second paragraph) speak to this further, and the first two "topics for further research" in that same paragraph relate to this as well.
>
> I'm aware--  But "use the same pool" is a seperate modality from "use
> more efficient transmission"; for one because if all miners do so (or
> technically just a simple majority plus a preference to mine on their
> own blocks even if later) then I believe your model would have an
> impediance of zero which has very different behavior.  It also already

It occurs to me that I'm perhaps being too understated.

"An unhealthy fee market requires a propagation time that grows
asymptotically with block size slower than log Q Using physical
arguments, we can show that this is not possible"

Your physical argument is incorrect on several folds.  First, if we
miners centralize they can achieve a growth of propagation time of 0.
0 is less than log(Q), that condition is trivially possible.

More generally your invocation of shanon-hartley is misapplied because
you are ignoring the entropy of the signal. Even disregarding the
miners ability to optimize communication by centralizing, no
blocksize-proportional information is /necessarily/ transmitted at the
time a block has been received. For example, imagine if miners only
include transactions that were previously committed to by another,
external, consensus system the concent of the blocks would be known in
advance, and not need to be transmitted. As a more concrete example,
the block relay network today communicates far less than one bit per
bit of blocksize to relay a block (e.g. transmitting a 962597 byte
block using 3804 bytes-- I wonder why instead you did not announce
your discovery that the block relay network has beat the Shanon limit!
:) --- after all, by your metric it can transmit X bits of information
over a channel which has _significantly_ less than X capacity).

If miners choose transactions in a way to minimize the transmission
delays there is no physical limit on how small the amount of
information is, and it does not necessarily depend on the blocksize at
all (see e.g. the practice of agreeing on transactions in advance--
e.g. the transmitted transaction proportional data can be the constant
size of 0),

----------
From: Peter R <peter_r@gmx.com>
Date: Tue, Aug 4, 2015 at 9:27 AM
To: Gregory Maxwell <gmaxwell@gmail.com>


Hi Greg,

Thanks for the comments and interest in my paper.

> I'm aware--  But "use the same pool" is a seperate modality from "use
> more efficient transmission"; for one because if all miners do so (or
> technically just a simple majority plus a preference to mine on their
> own blocks even if later) then I believe your model would have an
> impediance of zero which has very different behavior.  It also already
> exists, e.g. doesn't require new technology.  And for any point on
> your demand curve you assume the system is operating at, if the size
> of blocks can go up, I believe your model shows miners will increase
> income by centeralizing (because absent a limit on the supply, a lower
> impedance is more profitable).

I agree that lowering the propagation impedance is a profitable strategy.  I also agree that if the hash power is all pointed to one "super pool" that the impedance would be zero.

> A more minor point, perhaps I'm missing it, but you don't seem to
> analyize the effect of R/T changing on your model. As you know, in
> Bitcoin unless the supply of coins is increased R/T is vanishing and
> will geometrically become 0.

I don't, except briefly in the last paragraph of the conclusion.  The paper was already quite long and I didn't want to open a can of worms about things a quarter of a century away.

> Your physical argument is incorrect on several folds.  First, if we
> miners centralize they can achieve a growth of propagation time of 0.
> 0 is less than log(Q), that condition is trivially possible.

Good point.  I'm implicitly assuming that mining isn't centralized…that information must still be communicated across the network.  I thought that was sort of obvious (because that's the 51% scenario will already know about), but I agree I should have spoken to this point in more detail.

> More generally your invocation of shanon-hartley is misapplied because
> you are ignoring the entropy of the signal.

The "gamma" variable represents the coding gain (the degree to which the blocks can be compressed) and "C" represents the channel capacity.  So the term (gamma * C) represents the effective rate than the uncompressed block's propagate at.  The actual bit rate is just C.

As long as information needs to be communicated across channels, the Shannon-Hartley theorem applies.  To what extent the solutions can be compressed (what gamma value can be obtained) is an open research questions, afaik.

> I wonder why instead you did not announce
> your discovery that the block relay network has beat the Shanon limit!
> :) --- after all, by your metric it can transmit X bits of information
> over a channel which has _significantly_ less than X capacity).

Haha, but I actually do discuss this in two places on page 9.  But I agree now that you point it out that I should have explained how the relay network has a higher "gamma" value than the peer-to-peer network, and that's part of the reason why it's propagation impedance is so much lower.  I will include this in the next version!

Best regards,
Peter

----------
From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Tue, Aug 4, 2015 at 9:43 AM
To: Peter R <peter_r@gmx.com>


On Tue, Aug 4, 2015 at 9:27 AM, Peter R <peter_r@gmx.com> wrote:
> Good point.  I'm implicitly assuming that mining isn't centralized…that information must still be communicated across the network.  I thought that was sort of obvious (because that's the 51% scenario will already know about), but I agree I should have spoken to this point in more detail.

Thats orthorgonal--  in that yes, if mining is not decenteralized less
infomration must be communicated (in fact it's a progression, not a
threshold-- the more centeralized the network the less information
will be transmitted even by a naieve system)... but even with complete
decenteralization no information needs to be transmitted at the time a
block is found.

> To what extent the solutions can be compressed (what gamma value can be obtained) is an open research questions, afaik.

Consider the following scheme (which, we've proposed deploying
previously in varrious forms):

Miners volutarily participate in a fast consensus mechenism which
commits to transactions-- it could be a merged mined blockchain (like
the P2Pool chain, which commits to transactions) or something entirely
different.  No reward is given for participation in this scheme.  In
their Bitcoin blocks miners only include transactions which are at
least 6 blocks deep in that chain, moreover they include all
transactions which are in it, in a determinstic order.

Now when they find a block, all the participants will know exactly
which transactions they included, in exactly which order. No matter
how many there were.  _No_ information proportal to the transaction
count needs to be communicated to trasmit the block.

-
----------
From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Wed, Aug 5, 2015 at 8:50 PM
To: Peter R <peter_r@gmx.com>


Peter,  It's been over 24 hours since my last message to you-- and I'm
greatly confused by the correspondance which I see you posting on
reddit.

I believe in my discussion with you I conveyed a total break of your
paper: I believe demonstrated that your premises were incorrect and do
not support your some of your strongest conclusions.

I've been expecting you to come back with a response that you would be
retracting or seriously revising your paper and its conclusions.  And
yet I see you continuing to communicate with the public in messages
which suggest you are unaware of these considerations.
(e.g. https://www.reddit.com/r/Bitcoin/comments/3fuz2s/peter_todd_against_gavin_on_the_bitcoindev/cts983w
).

I don't think Peter Todd's response to you was approiate at the
time... but it would be helpful if you didn't demonstrate that he was
actually correct.

----------
From: Peter R <peter_r@gmx.com>
Date: Wed, Aug 5, 2015 at 9:43 PM
To: Gregory Maxwell <gmaxwell@gmail.com>


Hi Greg,

Peter,  It's been over 24 hours since my last message to you-- and I'm
greatly confused by the correspondance which I see you posting on
reddit.

Sorry for the delay.  It was my last day in Annecy and we were swimming and today I was on the train to the Paris airport.

On Tue, Aug 4, 2015 at 9:27 AM, Peter R <peter_r@gmx.com> wrote:
Good point.  I'm implicitly assuming that mining isn't centralized…that information must still be communicated across the network.  I thought that was sort of obvious (because that's the 51% scenario will already know about), but I agree I should have spoken to this point in more detail.

Thats orthorgonal--  in that yes, if mining is not decenteralized less
infomration must be communicated (in fact it's a progression, not a
threshold-- the more centeralized the network the less information
will be transmitted even by a naieve system)... but even with complete
decenteralization no information needs to be transmitted at the time a
block is found.

I'm not following your logic here.  At some point information needs to be transmitted to the miner's peers.  This takes a non-zero amount of time according to the Shannon-Hartley theorem.  This time has a cost associated with it.  What do you disagree with here?

To what extent the solutions can be compressed (what gamma value can be obtained) is an open research questions, afaik.

Consider the following scheme (which, we've proposed deploying
previously in varrious forms):

Miners volutarily participate in a fast consensus mechenism which
commits to transactions-- it could be a merged mined blockchain (like
the P2Pool chain, which commits to transactions) or something entirely
different.  No reward is given for participation in this scheme.  In
their Bitcoin blocks miners only include transactions which are at
least 6 blocks deep in that chain, moreover they include all
transactions which are in it, in a determinstic order.

Now when they find a block, all the participants will know exactly
which transactions they included, in exactly which order. No matter
how many there were.  _No_ information proportal to the transaction
count needs to be communicated to trasmit the block.

If zero information related to the transactions needs to be transmitted between peers, then the peers aren't making decisions of their own volition related to the transactions included in a block.  If they're not making decisions related to transactions then they're not really "peers" in my opinion.  I see this as another example of how a single entity who controls a lot of hash power can do various nasty stuff.

What is your definition of a peer?  To me, a peer needs to get information from his other peers from which he makes his own independent decisions.  This information takes time to communicate.  If there's more transactions, there's more information to communicate.  The only way this isn't true if I'm not mistaken is if there's no information to communicate related to the transactions in the block.  But like I said earlier, in this case then the miner's aren't peers--they're just slaves--and the system is already centralized.

I believe in my discussion with you I conveyed a total break of your
paper: I believe demonstrated that your premises were incorrect and do
not support your some of your strongest conclusions.

The only objection I've heard that makes sense to me is Dave Hudson's.  Can you explain exactly a what point in my paper you disagree with the math, the logic, or the assumptions?  How should the math change to make it correct in your opinion?

I've been expecting you to come back with a response that you would be
retracting or seriously revising your paper and its conclusions.  And
yet I see you continuing to communicate with the public in messages
which suggest you are unaware of these considerations.
(e.g. https://www.reddit.com/r/Bitcoin/comments/3fuz2s/peter_todd_against_gavin_on_the_bitcoindev/cts983w
).

I don't think Peter Todd's response to you was approiate at the
time... but it would be helpful if you didn't demonstrate that he was
actually correct.

Dave Hudson made what I feel was a valid objection regarding the "you-don't-orphan-your-own-blocks" idea.  I agree that my paper doesn't address his objection, but I believe it can be modified to do so without changing the results of the paper (that a healthy fee market exists).  Peter Todd echoed something agreeing with Dave, no?

Best regards,
Peter






----------
From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Wed, Aug 5, 2015 at 10:29 PM
To: Peter R <peter_r@gmx.com>


On Wed, Aug 5, 2015 at 9:43 PM, Peter R <peter_r@gmx.com> wrote:
> I'm not following your logic here.  At some point information needs to be
> transmitted to the miner's peers.  This takes a non-zero amount of time
> according to the Shannon-Hartley theorem.  This time has a cost associated
> with it.  What do you disagree with here?

Hm. I thought I gave a sufficiently concrete example. No information
needs to be conveyed at the time a block is found (beyond the fact of
the block, e.g. it's extranonce, which is all constant size); because
the information can have been sent in advance, unboundadly far in
advance is possible in fact.

> If zero information related to the transactions needs to be transmitted
> between peers, then the peers aren't making decisions of their own volition
> related to the transactions included in a block.  If they're not making
> decisions related to transactions then they're not really "peers" in my
> opinion.  I see this as another example of how a single entity who controls
> a lot of hash power can do various nasty stuff.

Thats not the example I'm making.

(Though the centeralization pressure you're talking about is a
consideration you should have gone into too! -- but I think it's
mostly mooted by the bigger issue I'm raising)


> What is your definition of a peer?  To me, a peer needs to get information
> from his other peers from which he makes his own independent decisions.
> This information takes time to communicate.  If there's more transactions,
> there's more information to communicate.  The only way this isn't true if
> I'm not mistaken is if there's no information to communicate related to the
> transactions in the block.  But like I said earlier, in this case then the
> miner's aren't peers--they're just slaves--and the system is already
> centralized.

I think you're stuck thinking in a particular model and I'm not sure
how to break you out of it.

For example, I'm about to communicate the whole 40 some gigabytes of
the Bitcoin blockchain to you:

00000000000000001454fdecfdb2b18cc07bf759f759ce4d8cac3301dc98f478

As you can see, I was able to do that by communicating only 32bytes--
and amount that I sent you here had no real dependence on the size of
the blockchain.

This was possible because our computers had already agreed on the
content of the blockchain before my communication to you happened.

Yes, communication did occur-- but not at the time of my transmission,
it happened arbritarily before.  This is devistating for your analysis
because you are working exclusively with the increased delay in
transmission as a function of the blocksize as a mechenism for
increasing orphaning resulting in an equlibrium profit maximizing
size.  Data which they sent earlier may have some costs to them, but
it does not have a cost in terms of increasing their orphan rate.

In that case I used data I didn't choose (the blockchain), but this
works just as well for data I did choose: I could send you a gigabyte
of data right now, then later send you an extranonce to append that
makes the result have a low hash.

There are many ways to use this fundimental result, and the relay
network protocol currently uses it in the simplest possible way.
Ultimately, it means that its possible to construct schemes where
miners retain choice but transmit a constant amount of information at
the time of block announcement.

----------
From: Peter R <peter_r@gmx.com>
Date: Wed, Aug 5, 2015 at 10:49 PM
To: Gregory Maxwell <gmaxwell@gmail.com>


Hi Greg,

OK I think I understand what you're saying.  I need to think more about it though.  One point already: wouldn't this strongly affect the miner's ability to include very recent transactions in a block?  A miner receives a transaction with a juicy fee, includes it, and then 1 second later solves the block.  New information needs to be communicated to his peers. The more recent TXs included, the more information.  Also, I can imagine how your scheme works if everyone agrees ahead of time exactly how they'll build blocks, but I don't see that it works if miner's are free to build blocks how they choose.

Off to bed...

Best regards,
Peter

----------
From: Tom Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Wed, Aug 5, 2015 at 11:45 PM
To: bitcoin-dev@lists.linuxfoundation.org


On 8/5/2015 3:44 PM, Dave Hudson via bitcoin-dev wrote:
I do suspect that if we were to model this more accurately we might be able to infer the "typical" propagation characteristics by measuring the deviation from the expected distribution.

The paper models propagation using a single time value that is a function of block size.  Modeling the propagation distribution (which is totally separate from the poisson model of block production) would add a lot of complexity and my guess is the outcome would be little changed.


On 5 Aug 2015, at 15:15, Peter R <peter_r@gmx.com> wrote:
Although a miner may not orphan his own block, by building on his own block he may now orphan two blocks in a row.  At some point, his solution or solutions must be communicated to his peers.

Why complicate the analysis by assuming that a miner who finds two blocks sequentially does not publish the first, or that other miners would orphan miner's first block unless both were very quick?  In general you don't consider anything beyond 1 block in the future, which seems fine.


I suspect this may well change some of the conclusions as larger block makers will definitely be able to create larger blocks than their smaller counterparts.
It will be interesting to see.  I suspect that the main result that "a healthy fee market exists" will still hold (assuming of course that a single miner with >50% of the hash power isn't acting maliciously).  Whether miners with larger value of h/H have a profit advantage, I'm not sure (but that was outside the scope of the paper anyways).

Correcting for non-orphaning of one's own blocks could be as simple as adding a factor (1 - h/H) to equation 4, which it appears would leave hashpower as an independent variable in the results.  But at worst, the discussion can be considered to apply directly only to low-hashpower miners right now.

Overall, the paper does not predict big changes to per/kb fees or spam costs for the kinds of block sizes being discussed for the immediate future (8MB).  But it does conclude that these fees will rise, not fall, with bigger blocks.

Also it is welcome that this paper actually mentions the bitcoin exchange rate as a factor in relation to block size (it points out that a spam attack is much more expensive in fiat terms today than it was years ago).

----------
From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Wed, Aug 5, 2015 at 11:50 PM
To: Peter R <peter_r@gmx.com>


On Wed, Aug 5, 2015 at 10:49 PM, Peter R <peter_r@gmx.com> wrote:
> OK I think I understand what you're saying.  I need to think more about it though.

Understood.  Enjoy your travels. (I should have said in my last
message: sorry to nag about response times, I certantly understand.)

> One point already: wouldn't this strongly affect the miner's ability to include very recent transactions in a block?

It would. Though with the high varience in block finding (e.g. 10
minutes expected but 1 hour blocks happen quite a few times a week) I
don't think e.g. effectively having a second or two delay would be
noticed by users at all. (actually there are already a bunch of delays
in transaction handling that no one seems to care about-- e.g. until
fairly recently each hop added up to 200ms delay just from sleeps in
the networking code; thats part of why decker's propagation numbers
are so high).

> A miner receives a transaction with a juicy fee, includes it, and then 1 second later solves the block.  New information needs to be communicated to his peers. The more recent TXs included, the more information.

Yes, new information needs to be conveyed in that case. At a cost;
although: by using forward error correction we can make it so that the
miner can convey information only proportional to the amount of
missing data they're correcting, without actually knowing which data
is specifically missing..  But all that gets you is a bound on how
many __very__ (e.g.within seconds) new transactions a miner can
profitably include... it's not relevant if the fees are fairly uniform
and there is a backlog.

Speaking of backlog, if you're looking for other avenues your work
didn't consider.  Think about the incentives of a miner once fees are
larger than subsidy (which is something that could reasonably happen
in just a few years) absent a block size limit. Instead of moving the
chain forward, why doesn't he instead orphan the tip, take all its
transactions and add the new ones that has come in since?    It's not
hard to setup a situation where the chain only makes progress when a
miner gets multiple blocks in a row (multiple depending on how much
larger than subsidy the fees are).

> Also, I can imagine how your scheme works if everyone agrees ahead of time exactly how they'll build blocks, but I don't see that it works if miner's are free to build blocks how they choose.

I was giving a simplified example to make it easier to follow.  For
example, even without agreeing on anything except the past history,
each miner can announce their intent to all the other miners (using
hashcash to prevent DOS), the communication overhead for this depends
on how efficient the communication is (e.g. just differential with the
intents of other miners?) but doesn't impact orphaning... if your
intent is taking a long time to communicate you have some penalty how
recent a transaction you can include without a marginal orphaning cost
for that transaction.

----------
From: Peter R <peter_r@gmx.com>
Date: Thu, Aug 6, 2015 at 7:34 AM
To: Gregory Maxwell <gmaxwell@gmail.com>


Hi Greg,

Thank you for your response.  I think you bring up some interesting points that readers should be made aware of.  Transforming your concerns to the language of my paper, I think you're challenging the claim that "gamma" [the coding gain with which block solutions are transmitted] can not be infinite (cf. Section 7).  Indeed, if gamma is infinite then the analysis breaks down.

I propose the following changes:

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

Best regards,
Peter

----------
From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Sat, Aug 29, 2015 at 8:32 PM
To: Peter R <peter_r@gmx.com>


https://www.reddit.com/r/Bitcoin/comments/3iuz3r/on_the_nature_of_miner_advantages_in_uncapped/cujz46a

Again, I am disappointed find you posting on reddit without correcting
factual statements which I know you know to be wrong.

E.g. in dpinna's paper, "PeterR has recently proven that unhealthy
fee markets where a miner’s surplus continuously grows with block
space are impossible. This is guarateed by the fact that while the fee
demand curve is asymptotically linear for largeblock sizes (see (3)),"

You know that your "proof" of this problematic-- outright false under
the discussion we had, or at least likely of little pratical relevance
under reasonable, pratical assumptions.  But you respond to dpinna
agreeing with him and not cautioning him on relying on these
assumptions.