cypherdoc said: i was one of them. that's b/c i feel that miners should know that if they produce a valid block, esp if it's a bigger block than has ever been seen on the network before, it should be validated and relayed by nodes, no questions asked. this keeps the blocksize decision making at the transport layer, as we advertise in the Articles. orphaning simply depends on latency from too big a block being created. allowing individual node operators to bring it back up into a consensus layer creates doubt in the minds of miners, esp if they can't get accurate stats on what the avg size block is being accepted on the network. Click to expand...

The orphaning risk can be made negligible by fast relay technologies (such as extreme thinblocks) that ensure that most of the validation work has been accomplished by nodes already when the block is actually broadcast. Because of this we cannot trust that the orphaning risk is enough to drive fee market, instead we'll have the tragedy of the commons. In other words, we need limits, the question is just who sets them. Will that be a privilege of a select group like devs, or miners? Or will it emerge through negotiation in which entire ecosystem takes part?I think the work that we have already done points to the way forward. The advertising of individual settings in the user-agent string and the xthinblock protocol both empower full nodes. In particular, with further optimization of the relay protocol, the full nodes, distributed around the globe can form a relay network that serves as a replacement for Corallo's network, and so full nodes can become relevant to miners in a way that they currently are not. Beyond this, we would need to find some more "magic ingredients" to give incentive for miners to stay with the full nodes (and not form a separate relay system).The idea in the opening post does not empower the nodes in any way AFAICS. It effectively negates everything we have done so far, and then anything goes. I agree with @solex in every point; the next logical step is to make the excessiveblock settings to reflect the node's actual computing resources. Then we should be thinking how to make the publishing of settings stronger and more sybil-resistant.As for the removal of mining code: I actually haven't checked the GUI lately but I think the "generate Bitcoins" button has been long gone? The setgenerate function however is eminently useful when doing regression testing, where we have to create test blockchain from scratch. So when we switch to using continous integration server for builds, we absolutely need to have the mining capability in the client. And I kind of like the idea of users being capable of using the testnet and mining test coins and learning how things work in general.