Well we had another diff drop today after nearly 5 weeks... A quick feeding frenzy at 488 diff and back to 1953. Wait another 5 weeks, rinse and repeat. It's great for restricting the supply of BTM but surely this cycle is not healthy in the long run.
I'm holding a considerable amount of BTM so the fewer coins the better for me, but I'm trying to look past that and consider the long term health of the coin. It's nothing for whales to stop mining LTC for a few hours and pick up some easy BTM when the diff drops and then return to what they were doing earlier.
Seriously, BTM needs to do *something* to better manage it's hashrate. I would be willing to put money into renting hash to regulate/pump the average hash if enough of us pooled together to make it worthwhile. Short term pain for long term gain. You can't go on forever having 1gh/s for 5 weeks and over 70gh/s for 5 hours and expect people to hang around.
No miners = no perceived value = no real value.. I sometimes feel that as good a job as the dev team is doing, they are too involved with the future plans for BTM and not looking closely enough at the nuts and bolts of actually producing a viable coin that is attractive to both miners and end users. After all, if not enough people are willing to mine the coin to give it value, it has no value.
Agree ... achieving the block generation rate which is specified is very important, because, like you say, its a "nuts & bolts" aspect of a coin. If BTM is to gain wider traction and adoption, it has to be reliable and perform as advertised to gain the trust of users.
What hash rate is on the network should not have such dramatic impacts on the transaction confirmation delay times; after all, that is a big point of having a difficulty number: it regulates the block generation rate in the face of whatever hash power is there. Bitmark
charter post states it should be about 2 minutes, IMO, this should be regardless of the hash-mojo miners are putting on the network.
Transaction confirmation delay has been conflated with coin production/emission. This is necessarily so when blocks carry a fixed reward which doesn't change over a long period of time. (i.e., bitcoin's 4 year halving, or bitmark's somewhat more sophisticated formula, which halves every 3 years, with intermediate decreases every 18 months).
For transactions to process expediently, blocks
have to be produced by network consensus at a rate which is not too slow, which is why most ( or all?) alt-coins have aimed for lower confirmation times = higher block-generation rates. As long as the difficulty is matched to a given network hash power, blocks will be generated at close to the target rate and so transactions confirmed without unexpected delay.
Hash power of the network varies for many reasons. Primarily because miners seek higher profits and move their hash power around different coins as market prices vary, but also for many other trivial reasons, such as power outages, new hardware, etc. From the point of view of a single coin network which seeks to serve its users consistently and expediently, responding and adapting dynamically to network hash power changes and achieving control of the block generation rate / transaction confirmation delay times ought to be a high priority.
The aspect of regulating coin emission rate (CER) could be separate from transaction confirmation time (TCT) by a more dynamic block reward formula. Think about the blocks as trains on a commuter line. A train should arrive every 2 minutes, like clockwork (thus satisfying the users with reliable 'transportation' = expedient transaction confirmations). But how many new coins the train brings could be variable, being revised periodically; (most likely based on coin demand as measured by network hash-power). This part clearly needs further thought and elaboration, as to
how much and
how often to vary the block reward and satisfy the overall absolute limit on emission and other economic supply-demand laws, but my main point is that TCT should not be dependent on CER policies.