__3. Without a block size limit, orphan risk is guaranteed to be large compared to miner's revenue__
*"You state this as fact, yet it is pure speculation"* --

@Peter R
**It is a logical consequence from 1 in itself**, but also the other idea about wallets lowering fees to just over the expected marginal orphan rate cost. Each of these two things on their own are enough to cause the problem.

...

Anyway, this is all based on the assumption of a high level of competition. I look at this problem from the angle of ensuring the network is resilient.

**You seem to say my argument is not a logical consequence of #1, which may be true for some shapes of the marginal cost curve that I have not seen. ** However, we need to ensure the network is resilient for all feasible shapes of the cost curve.

You've said both that #3 is a logical consequence of #1 and then later that that might not be true for some curves (it is

*definitely* not true for some curves--just imagine the case of near zero demand for block space but high demand for the block rewards). So if it is not true for

*some curves*, then it is not true

*in general*, which was my point all along.

With that out of the way, I think you introduced a new idea in your last sentence quoted above. The new idea is a requirement that orphaning risk be small compared to miners revenue for

* all supply and demand curves*. The way I view this, the important metric is for

*PoW* to be big enough to secure the ledger, where

*PoW* = *miners revenue* - *profit* - *orphaning risk*

So yes, I think I agree with you here. But how can the design of the software guarantee this to be true? For example, if the

*miners revenue* is very small (e.g., due to lack of demand for block space or lack of demand for block rewards), then

*PoW* will also be very small and the blockchain will have low security. This is largely independent of orphaning risk. In fact, doesn't this make it clear that what's most important is miners revenue?