Quote from: molecular on June 11, 2015, 08:33:35 PM

"The miner has higher profit choosing S over N": I think this might be dumbfruits point: there might be some other, indirect effects stemming from the increased profit given to the competition influencing the miners profit in the long run. Let's take for a example a rather efficient miner. Let's say he can cover his cost in both cases S and N and let's say his counterpart mines with higher energy cost. Choosing S might push his competition into the profit zone, while choosing N might force the competition to shut down operations. In such a scenario, choosing N would be the more profitable option. Or maybe less crass: by reducing the competitions profit overproportionally to it's own, a miner can maybe slow down their expansion or increase of efficiency and maybe deven drive them out of the game entirely.

Yes this could be another risk and your argument is probably correct, however the impact of this might be small and it actually has characteristics similar to normal mining economics.

Overall, at this point, in my view Menis proposal could be the best suggestion so far, in respect of partially alleviating some of the concerns associated with the block size limit issue.

The potential options we have are outlined below:

1. Increase the max blocksize to 20MB
Advocate: Gavin

2. Do Nothing
Advocate: ?

3. Introduce a variable difficulty based on blocksize
Advocate: Gregg

4. Limit the CoVar of the transaction fees in blocks
Advocate: Sergio

5. Elastic block cap with rollover penalties
Advocate: Meni

6. Dynmaic block size limit based on averages of historic blocks sizes or historic fees
Advocate: ?

7. A less direct solution like Lightning, Sidechains or off chain transactions
Advocate: ?

8. Allow users to choose their own limits, with the 1MB chain confirming transactions in larger chains
Advocate: Adam

9. A compromise between 1MB and 20MB
Advocate: ?

Unlike most of the other proposals, Meni's suggestion appears to have less of an impact on the network if it is not used and has far fewer security risks than the other proposals, in my view. At the same time it can be combined with a variable limit based on historic medians, to produce a more complete solution to the problem. I hope people scrutinize this proposal, and the others, in an objective way and that we eventually implement a solution in a thoughtful and patient manner, based on the best technical solution, with the smallest amount of valid attack vectors.