I'm not sure to understand your logic here.

Yes, nice work.  In my paper I was looking at the Miner's Surplus, which is not in general equal to the Miner's Profit as your graphs illustrate (but they both are maximized at the same value of Q*).  Your graphs show the miner's profit explicitly.  


This chart brings up a very good point.  Like you point out, in such a scenario, the miner can only earn a profit if he can include a sufficient number of fee-paying TXs in his block.  But what happens if the miner before him cleaned out the mempool?  It seems the rational miner will stop hashing¹ entirely until enough new transactions have built up to push his block into the "profitable" zone in your graph (the zone where the supply curve is below the demand curve).  


I'm not sure.  I think the model suggests that the supply curve turns into a horizontal line at M=0 in such a case.  We still need to get around the problem that Eq. (11) suggests the cost to write to the Blockchain falls to zero:



Smooth has brought this up a few times now (and I've been ignoring him because I think this can of worms is best left closed).  Anyways, to really understand what happens when R->0 I think we need to make a new model that takes into account what we just learned from your chart above (that miners won't necessarily be hashing all the time).  

¹Assuming the cost to turn the hardware on and off is small.

That seems to be an interesting point illustrating how the best interest of users and miners incentives could diverge.
For users, an empty block is always better than no block because it adds work to the chain and increases the security of the previous transactions.

note how all the arguments have flipped 180 from what they originally FUD'd about large block attacks here:

https://www.reddit.com/r/Bitcoin/comments/354qbm/bitcoin_devs_do_not_have_consensus_on_blocksize/cr138we?context=3

gmax (italics).  non-italics mine:
>
I'm also mystified by a lot of the large block discussion, much of it
is completely divorced from the technology as deployed; much less what
we-- in industry-- know to be possible. I don't blame you or anyone in
particular on this; it's a new area and we don't yet know what we need
to know to know what we need to know; or to the extent that we do it
hasn't had time to get effectively communicated.

The technical/security implications of larger blocks are related to
other things than propagation time, if you assume people are using the
available efficient relay protocol (or better).

SPV mining is a bit of a misnomer (If I coined the term, I'm sorry).
What these parties are actually doing is blinding mining on top of
other pools' stratum work. You can think of it as sub-pooling with
hopping onto whatever pool has the highest block (I'll call it VFSSP
in this post-- validation free stratum subpooling).  It's very easy to
implement, and there are other considerations.

It was initially deployed at a time when a single pool in Europe has
amassed more than half of the hashrate. This pool had propagation
problems and a very high orphan rate, it may have (perhaps
unintentionally) been performing a selfish mining attack; mining off
their stratum work was an easy fix which massively cut down the orphan
rates for anyone who did it.  This was before the relay network
protocol existed (the fact that all the hashpower was consolidating on
a single pool was a major motivation for creating it).

note how the relay network was an apparent reactionary construct to ghash which had been spv mining to compensate for it's own high orphan rates.  never mind that it self imploded as hashers abandoned the pool for aggregious behavior.  the relay network is less than 1y old.  also note how miners CAN defend themselves quite well to a large block attack and high orphan rates; by spv mining at it's most extreme.  this is a major pt i have been making as to why a block cap is not needed.


>VFSSP also cuts through a number of practical issues miners have had:
Miners that run their own bitcoin nodes in far away colocation
(>100ms) due to local bandwidth or connectivity issues (censored
internet); relay network hubs not being anywhere near by due to
strange internet routing (e.g. japan to china going via the US for ...
reasons...); the CreateNewBlock() function being very slow and
unoptimized, etc.   There are many other things like this-- and VFSSP
avoids them causing delays even when you don't understand them or know
about them. So even when they're easily fixed the VFSSP is a more
general workaround.

see?  i have been saying EXACTLY THIS since the beginning of the debate calling them "defensive blocks".

>Mining operations are also usually operated in a largely fire and
forget manner. There is a long history in (esp pooled) mining where
someone sets up an operation and then hardly maintains it after the
fact... so some of the use of VFSSP appears to just be inertia-- we
have better solutions now, but they they work to deploy and changing
things involves risk (which is heightened by a lack of good
monitoring-- participants learn they are too latent by observing
orphaned blocks at a cost of 25 BTC each).


remember when gmax was "surprised" when he was told by f2pool that they needed to utilize spv blocks as a defense to full blocks as a result the spamming attacks?  i never called him out on this as up to that pt they had been continually using the "large miner large block attack" as a reason to not lift the limit.  in contrast, i had for some time prior to this pointed out that this was obvious based on what Chun had said in his bitcoin-dev post.

>One of the frustrating things about incentives in this space is that
bad outcomes are possible even when they're not necessary. E.g. if a
miner can lower their orphan rate by deploying a new protocol (or
simply fixing some faulty hardware in their infrastructure, like
Bitcoin nodes running on cheap VPSes with remote storage)  OR they can
lower their orphan rate by pointing their hashpower at a free
centeralized pool, they're likely to do the latter because it takes
less effort.


yet another non-technical assessment from gmax based on a misunderstanding of miner incentives.  no, i don't think miners will just take the easy route in pointing their hashrate at a centralized pool.  miners instead have an incentive to keep mining honest by keeping the hashrate decentralized and the system honest as a whole in order not to destroy value:

https://www.youtube.com/watch?v=or65M4Ht4Kk

It's a matter of whether we're talking about the fee per transactions, or the total fees that a miner can claim when he builds a block.  In the case where R->0, you could post a TX with a generous fee¹ but it still won't make sense for a miner to attempt to mine a block just for you.  You'd need to wait until others have broadcast similarly fee paying transactions, in order to push the block size into the "profitable" zone in Mengerian's graph:



¹There would be some fee that you could pay to get your TX mined, but it would be vastly more costly than waiting for other fee-paying transactions to begin re-filling the miners' mempools.

Right, hold back, not kill entirely, because what they have is only dreams and vaporware.

 

Hard fork the network and risk catastrophic consensus failure to "revitalise trust" is a good move!?

You are out of your mind.

oh my, Cripplecoiners in Big Trouble:

https://twitter.com/Datavetaren/status/631080568487342080

Don't forget https://www.reddit.com/r/Bitcoin/comments/3gkp91/blocksize_debate_coinbase_bitpay_chaincom/

Bigger blocks, here we come !

Seems I am on ignore on everyone here