maaku
commented
4 years ago Worth mentioning: I don't think there's any reason we have to do double-SHA256 merge mining as the new proof-of-work. We could pick anything. But as forward blocks will eventually make the subsidy on the compatibility chain go to zero, it would make sense to have merge-mining. And if we're going to merge-mine, we might has well use the algo with the largest set of miners out there.
Forward Blocks may not be necessary to change proof-of-work in a soft-fork way on Tradecraft. As a result, perhaps we should replace bitcoin-competitive solo dSHA256 with bitcoin-compatible merge-mined dSHA256 as the proof-of-work in the near term, prior to the deployment of full forward blocks? This suggested improvement comes with trade-offs, and would need the acceptance of the entire Tradecraft community.
The invention of Forward Blocks happened as a result of musing over how to change Freicoin/Tradecraft's proof-of-work function as a soft-fork. The notion of forward blocks (as specified in the proposal) and the compatibility chain achieves this goal in the general sense. However it has come to my attention that it might be possible to use a simpler construction just to change the proof-of-work that does not require any of the forward blocks development effort. This only really works on Tradecraft because of our unique situation of our PoW competing with an economically larger chain (bitcoin) and the details of our difficulty adjustment algorithm.
The construct is this: require valid, merge mined PoW headers for block templates. Then when mining the assembled block, all that can change is the nonce, extranonce, a few version bits (for AsicBoost), the difficulty bits, coinbase string field, etc. A copy of these for merge mined validation is placed in a miner-generated commitment.
This is not a new idea. It was in fact the starting off point for development of forward blocks, which fixes the issues this approach has to changing the proof-of-work. The main issue is: proof-of-work is no longer progress-free. You have to first find a block using merged mining, and then find a block using the native proof-of-work (or vice-versa). This greatly magnifies the effectiveness of block withholding / selfish-mining, and can have a huge centralizing effect. However the problem would mostly go away if the difficulty of the original PoW could be dropped to a trivial range... which describes Freicoin presently. And thanks to how our difficulty adjustment algorithm works, it can be clamped to that range as well.
It's possible to bias the difficulty adjustment filter to make the adjustment algorithm think the hashrate is continuously dropping by a small amount. Since with the added secondary proof of work would be driving the block rate independent of the original difficulty, the original difficulty will drop slowly over time until it reaches a truly trivial range (e.g. 1 to 256) and the bias is no longer enforced. A block of that difficulty can be found by an ASIC miner or the mining pool sub-second time.
To implement this, the consensus code changes to Tradecraft to support merged mining are actually quite trivial. Although not required, it would be a good opportunity to test and deploy a new difficulty adjustment algorithm (see #3) and see how it works in production before we have a chance to change it again with Forward Blocks. Getting this to work with bitcoin mining pools would be a bit more complicated, but a basic implementation would work for initial deployment.
If this were adopted by even a small bitcoin mining pool, it would mean that solo mining is out of reach for all of the existing miners on the Tradecraft network. It is therefore absolutely essential that the ramifications of this are explained well, and the proposal have near-unanimous consensus of the entire community. I would suggest a 95% activation threshold, with cancellation on timeout, and have signalling for it NOT be the default.