Quote from: dbkeys on September 10, 2018, 06:26:54 PM

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:

Fork #1 (Current Bitmark Version 0.9.7.2, now in operations) Historical Proposal and Cautionary Notes from Melvin

Maybe you can fool others with this but making some algos native only would obviously benefit those who want to mine and gather Bitmarks easily without much competition, and in the same time reduce supply on exchanges. And then "conveniently" the lookback period is less to give these native miners more rewards. Maybe people don't realize this but blockchains are very unintuitive. There are no real world analogies to blockchains. Details matter. One small detail is the difference between a serious cryptocurrency and a joke. So it's your choice...

In general any change should show support from all 3 parties who have an interest in Bitmark: users, investors, and miners. Users can show support by voting when they make transactions (weighted by fees). Investors can show support by voting with stake (weighted by amount owned). Miners can show support by voting with hashpower. In the end users decide, since investors will follow users, and miners will then follow them since they want the highest market value of the coin they mine. But there should be a guideline written in the wiki that all 3 parties should agree with a strong supermajority (95%) in order to make a change to the protocol. If there is a division, then better just fork into 2 coins.

I already learned not to trust dbkeys, so I will try my best to get an exchange to support my "uncorrupted" vision. Like that if I do a bunch of work on Bitmark, at least there is a chance it can continue being used. But I also need support from people who support my vision.

By the way, I already have a 0.9.7.3 (with technical fixes) released on the bitmark-protocol repository: https://github.com/bitmark-protocol/bitmark/releases/tag/v0.9.7.3
It requires 950 out of the last 1000 blocks to signal it in order to activate. I even have a 0.9.7.4, with stricter block reward requirements, so people can signal for that too.