I would like to steer the conversation towards fork talk if I could. I want to first off make it absolutely clear that in my opinion, HyperStake could stay in the same state forever and be a perfectly fine coin that works well and stakes well as it does now. But it might also be a bit of fun to add something new, and also put it on a more sustainable long term path.
I would like to propose 3 things for consideration of the community, and ask for well reasoned feedback.
1 -
Increase block time. My primary reasoning for this is the growth of the blockchain size over time and the resources it takes to run the chain and to sync it from scratch. The smaller the chain the better. As you all know I have taken over
RateCoin and forked it to be something I found to be sustainable and attractive long term. I forked the block target from the very ugly 30 second target to 3 minute. This puts XRA at 480 blocks per day. But that also means only 480 stakes per day network wide. I could see something like this working for HYP, but I would lean towards perhaps 2-2:30 minute blocks, which would yield 575-720 blocks per day instead of the current 960 per day. One thing to keep in mind is that although we want high difficulty, we want new comers to have a reasonable experience staking HYP.
2 -
Increase the maximum stake age (really the max age that weight grows larger) to allow smaller inputs to have greater opportunity to stake. I don't have a hard number in my head for what is the best max age, but I do think we need a max age. I think there is room to double the current maximum from 32 up to 64, and maybe even up to 100. Lots of old outputs laying around wanting to stake. This also lets a patient small holder have a greater opportunity to stake without buying a large sum.
3 -
A bonus weight advantage and stake reward for compounded blocks. If the block was created via coinstake not via transaction, then I propose to give an additional stake weight to it (maybe 5-10% extra) and an increased reward (maybe 1100 HYP instead of 1000 max). This would encourage compound staking, but would also discourage resizing your outputs ("blocks") too often. I would need to do quite a bit of testnetting with this feature, but I think it could prove unique and fun.
Any thoughts?
I think that a coin shouldn't adapt to changing conditions by changing its code, i.e. by extending or cutting some parameters. Because it's only temporary solution, you will need to do it again and again. Instead conditions should be modeled initially and coin design should be made adaptable by itself. Moreover, crypto currencies do not only transmit value, they also store value, and the cutting of a parameter can be seen by a user as the cutting of his gold bars in a bank safe deposit box to save some space. A great approach in this case would be to implement some incentive features on top of the basic functionality layer.
1. I'm against block time tweaking. The chain size isn't a problem ATM, imho, and I have a strong belief it won't be in the future due to an exponential growth of a technology level, but even if we reduce its bloating by, for example, 25%, we will get the same size, just a little bit later. One of the workarounds of this problem to simplify the life of newcomers could be a thin client. As to sustainability, I think that the supply level in our case is not an issue as it keeps shrinking (relatively). I have made a
page that calculates the yearly supply gain starting from this moment, and it can be seen with the naked eye how it's permanently dropping down. Adding an incentive for a long term holding can boost the psychological effect, making people tend to be hoarders rather than dumpers.
Here are also some disadvantages of this tweak. 90 seconds is a comfortable block time that makes this coin super fast, which is a part of our positioning. A lot of people rely on their return estimates, some of them could have taken out loans to buy HYP, some of them can have family budgets based on HYP returns, or just simply some special strategy. It wouldn't be fair to cut down the supply abruptly. Instead it makes a lot of sense to work on the demand as not only supply (that is already shrinking) is responsible for sustainability.
2. This feature definitely should be adaptive, otherwise it is subjected to a permanent manual tweaking as the diff keeps growing. Which, in addition, can be a security threat. I have some ideas, but they should be elaborated first.
3. Great idea
