Whaleshares Fork - Part 2, Rough
This is the outcome of the previous article. As I explained, it's a bit of a mess, I will spend the next while reworking it into a much smaller and cleaner format, however this is part 2 as promised. I hope it is interesting.
Outline for Initial Fork
Increase Bandwidth - Finish/WIP
Decrease Comment and Post interval, increase base bandwidth by 2x, and decrease post bandwidth weight 2x. Users will be allowed twice as much bandwidth, and the cost to post will be reduced by 50%.
Fix Inflation - Finish/WIP
*Inflation set to initial tokens of 5 million, at a rate of 5%. Should this be 2.5?
Inflation on Creation - FInish
Newly created accounts should generate 45% of the fee paid as new stake balance. 45% generation ensures it is not worth creating new accounts, as 55% of your payment is burnt, and only 45% is returned in a new account. (Payments will need to be spent into devfund, as burning would fight inflation in this manner. Burning can only occur on existing user actions.) I'm going to make a seperate post about this.
Remove self tipping - Finish/Needs Testing
There is no reason to tip yourself that I can imagine.
Create developer votes. - Finished / Needs Testing
Stakeholders should be able to vote for developers just like they do witnesses.
Imply fees for voting witnesses and developers. - Finished/WIP
This will touch on the issue of inflation however lightly. Users love to use their stake, and will not mind burning tokens for a good cause. Supporting a witness or a developer should cost, and not be something a user will do from multiple accounts, or without due consideration.
Bring back deleted and edited content - Not touched, not sure how editing works yet.
Allowing users to delete their content will free up a good deal of space from the blockchain.
Edited content seems to be included previously. Deleted content brings questions, do users' comments get deleted as well? Would like to discuss with community.
- Limit number of accounts creatable daily - Finished
This will ensure a quality community.
- Friends content for friends only
Content posted to “friends”, should not be displayed in the public feeds. How best to operate this?
Modify api requests to allow signature. Requests without signature are only returned public content, signed requesters may view their friends content. Same for blocking. Fetch blocklist, filter, return. No sign, no block no friends
- Spam Handling Finished
Users begin with a daily_posts parameter of 8. Each POST submitted, this count is decreased. When daily claims are made, the parameter is reset to 8. This avoids load on servers, while maintaining a registered limit for all users.
Many social platforms advise you not to post too often, in order to keep decentralisation a possibility we may have to sacrifice and accept some minor limits. Am open to new ideas, but this combined with PROPER user muting is the best solution.
Certain transactions should be payable from stake.
Lower Powerdown, 7 daily payments - Finished/Needs full week test
This should be enough time for large investors to be able to receive proper warning during large dumps, but a low enough time that they are not forced to sit on the currency for months at a time.
Implement secondary reward pools?
Graphical Interface for wallet? Android/PC
Is more than the hive/steem engine software needed? Would it be more valuable to be hardcoded, worth the effort?
- Long Polling
Long Polling capability should be added into the rpc? No should run on a top layer.
- Encrypt User Content to prevent outside viewers.
Is this worthwhile? This only covers outsiders. In a decentralised environment what about a user who wants to harm the system from the inside? One node can never know the full secret, follow incognito, ask around.
Byline/Custom Tip Quotes
Allow users to set a catchy byline for their articles, will be fun and inspire more tips!
Blocking v Muting
Should there be differences, or rename block to mute?
Configurable Block Time
More time in between blocks will reduce storage consumption. Faster block times are beneficial, however can produce quite a load. Even from 3 seconds to 9 seconds, 20 million blocks could be split into 6.6 million, costing each user only an extra 6 seconds. Would users need to wait?? Perhaps this could not app to all kinds of transactions, some could be instant whereas others could be slowed when possible.
- Account creation
If the number of votes is a factor in new consensus, then users will be inspired to create new accounts under their control. Furthermore, each account will be funded with newly minted tokens, which could relieve the number of tokens needed to create an account. Allowing witnesses to set the base creation inflation is also risky here. This all only matters if consensus uses multiple accounts.
Users pay for accounts. Accounts pay for development. This is a plus all things considered. Furthermore stake must be powered up to each “puppet” account. Low supply and validity of userbase ensures this somewhat. A minimum required stake to vote for a witness would also fight this issue, along with the “equal distribution” problem in witness consensus. This is not yet a solution, but this can be combated. Could possibly further require witness votes to be replaced every time period.
- Reputation based muting
As always in a decentralised system, a rogue group of bandits could amass enough stake and go around muting anyone they like. This could be fought by other users in the community, though this is what starts wars. This could also have a limit, reporting users in a time period.
Charge a fee per user, one which is not much for the community to pay as a whole, however one which would be extensive for a single user to abuse. Purely for example, 5 tokens for 1 flag totalling 8% of accounts. If 8% of the system as a whole, decides that this content should be removed, remove it.
Above situation does not work in a low number of users, or an inactive number of users, however activity could be determined by the witnesses. Perhaps the content could be redeemed by the same method. Easy for a community to do, should the content be worth redeeming, hard for a single user to fight alone. This works in favor of the community however.
Open to suggestions for the above problems, and other problems I may have missed
Witness Score could be lowered within a range, by missed blocks. No more than range can be applied. This solves the attack factor there.
Witness Lineup Scheduling
In the new system, the goal is for witnesses to receive more benefit from being an active and committed witness, and not just from owning more stake or having the best friends. In theory many methods were discussed. Currently the methods discussed brought us to a solution of using not only the combined weight of voters stake, but both the total count of voters, along with a bonus or penalty for blocks that are missed.
Several other factors are being considered, reputation the highest amongst them, however attack factors need to be solved before they can be used. DOSing a witness could lower their score, which in turn would bring them lower than other witnesses, so to minify this the score can only provide a minor boost/debuff to the producing witness. This alone should nullify any efforts spent on a dos attempt.
Though several calculations were tried, the best one discovered was (total count of voters * combined stake of voters). The formula can be seen in the below images, both a FAIR, and RIGGED example situation, each including 7 witnesses with varying voters, and weights behind them. The weights were minified for simplicity's sake.
In the above FAIR model, the highest score is seen displayed in ‘w7’, with ‘w4’ following behind, and ‘w3’ in third place. In this model, witnesses with the highest number of voters who hold the highest combined stake come out on top.
In the RIGGED inflation model shown above, it can be seen that w7 is still the top score, with ‘w1’, taking second place and pushing ‘w2’ and ‘w3’ into the next position below. In this case even though w2 has less voters than both ‘w3’ and ‘w4’, the combined voters have enough stake to show the witnesses value and take priority with the witnesses who have more voters but less overall stake.
This model is still in favor of the power over count methodology, which is important in a POS environment, however it places a much larger power than before into the hands of the many.
Block Production Score.
This will need to be deduced after a trial run of the new algorithm mentioned above. A set amount of X, we’ll say 100,000 for now, will be the production bonus that can be applied to a witnesses score. Each block missed will lower a witnesses score by 1000, up to a total of 100 times. Each block hit will raise the witnesses score by 1000, up to a total of 100 times.
(This could alternatively be done with a calculation similar to witness votes, variable*blocks_hit, would benefit more to the users who hit blocks,rather than punish those who miss them, could be gamified?)
This will ensure that all witnesses running at optimum performance will have no priority over another from the block production score, however those who miss blocks will be lowered in rankings until they suss out their situations. This again brings massive responsibility to the witnesses and gives them a campaign to run on, ie. the most dedication and the nicest hardware.
Decentralised Growth Funds (devfunds)
Dev funds grow daily. I can see this done in two ways. Either a user earns “growth points” in some manner, and cashes them in for tokens from the fund, or the user earns the “contributor” title, which entitles them to a portion of the funds created daily, likely determined in a matter similar to witness scheduling.
The latter is of course easier, find developers and distribute automatically, however is left open to abuse in a chain with poor maintenance. However the first option is quite abusable in a state of high power, and unprofitable when the community refuses to support development. The latter choice has been implemented for now.
Would like to hear input on this.
- Are initminers needed? Do they devalue the chain or give value to it?
Further Ideas or Suggestions?
Regarding the four reward pools, only 3 are needed, and the two main could completely exclude private users content from public viewers. This would be a much smaller pool, and the larger pool would incentivize those looking to make more to engage in the public world. Private users only bring so much value in the end.
Celebrity pool can be the top X%, preferably low, a 1 or 2 percentage would be fine here.