There is no sneakiness involved. I'm actively soliciting input.  

I think it makes sense to have distinctions based on whether or not algos have been implemented on ASIC's

Also, reducing the CEM look back window returns the emission rate toward the "standard" curve (the one based on just the quartering and halving system) faster than 'remembering' a long ago peak.  1 years seems a bit excessive to me now. In light of the possibility of a large amount of hashrate disappearing through some type of force-majeure, (like an EMP) which is not the decision or fault of any miner, should not be affecting the entire network for so long, IMO. So I suggest reducing 365 day lookback to 120 day, or 127 to be binary and prime, (about 1/3 year)

I do think that some algos should be native-only, if not the majority, at least a third; that is why the least disruptive path to this ideal seems to be to revert 2 of the lesser used ones (no huge parent chains anyway) and introducing a third which has never been mm'd in Bitmark.  

So, first, I propose the non-controversial, non-forking improvements be adopted into a new tag 0.9.7.3; this is the squelching of the excessively sensistive "mining difficulties" warning, any other useful improvements & fixes, as well as  the simple ability to Mark a file via an embedded transaction comment.  (The issue of long-term cloud storage and accesibility of the marked data is left for later).

Then, more than likely, we should go through a vetting & testing phase determines what the next Forking version may look like, and set it to activate as we did with Fork #1, perhaps with a 75% supermajority over 256 blocks, or perhaps 1000. But I think a 95% requirement is a bit much.


For the First Fork, the current v0.9.7.2 @melvincarvalho laid out a good guide document of what should be achieved.

The GitHub wiki has the example: