Introducing The Wisper Project
Below is a workup of all changes included in the blockchain I am working on. There may be some things I missed, will edit as needed. If you would like to help out with the project, or simply stay updated on it's progress, don't be afraid to let me know below!
What is Wisper?
Wisper is a graphene blockchain, forked from the Whaleshares Project. Wisper is a blockchain powered social media platform which enables its users to engage socially, create blogs and form communities, and even reaches so far as to allow businesses to be built and operated over/within the network.
Why was Wisper created?
Wisper was created for several reasons. The most important of which, is to have a truly decentralised network. I’ve witnessed many of these chains come and go, and none have yet been implemented in the way that I imagined. It is my belief that a blockchain such as Wisper should be able to be hosted and accessed by any human with a voice to share.
As often these platforms are marketed as “free speech”, this will not be our focal point. Another goal for The Wisper Project is to allow anonymous users to partake and enjoy the social media experience.
Finally, another big element to this blockchain is the fact that all work will be done by third parties. The development funds created for the Whaleshares blockchain have been modified so that any user who wishes can contribute to and earn rewards from the blockchain, with the only central authority being the community behind it.
What does the future hold for Wisper?
Honestly, I have no answer to this question. A small, hopeful part of me sees this as a lengthy success, however I must be honest with you all, a blockchain cannot be run by one person. Should not at least. If this project does not receive the support I hope it does, it will die out.
I wonder if that is information better kept private, easy to attack know you know, but I really hope that the people reading about this don’t want to harm the project, and would like to contribute to see what a dedicated group of people can build together.
When can I use the Wisper blockchain?
The Wisper Blockchain is being tested right now by live beta testers, and will continue this process for the next week at the minimum. Many new features still need to be integrated into front ends, and services need finalisation.
I’d say within 2 weeks we will have a live, finalised blockchain that you can register with.
What exchanges will support Wisper?
I will be focusing on hive engine to start, that is one thing I can do by myself. Perhaps bittrex in the future, but I don’t want to make promises I can’t keep. The hive or steem engine sounds like something I can assure us, and I would expect this within the first two weeks of release.
What problems are expected in developing Wisper?
Thankfully, much groundwork was laid out by Whaleshares development team, and this means that even if it takes a while for things to pick up, the chain is running pretty well on it’s own, especially with the new changes.
One problem that everyone should be aware of… this is my first time in programming a blockchain, and though full of confidence, I am sure there are going to be bumps along the road. There are just things that I don’t know.
The more developers with experience we can get on the team, the less issues I expect we will face, and the safer a bet this project becomes.
Whisper Initial Fork
- Increase Bandwidth
Bandwidth distribution has been increased, and redistributed to pay more respect to lower members, while providing a maximum to higher levels.
Current stake-bandwidth ratios:
More than 1 Billion WLS - 1024kb Daily Bandwidth More than 100 Million WLS - 512kb Daily Bandwidth More than 10 Million WLS - 256kb Daily Bandwidth More than 1 Million WLS - 128kb Daily Bandwidth More than 100,000 WLS - 64kb Daily Bandwidth More than 10,000 WLS - 32kb Daily Bandwidth More than 1,000 WLS - 16kb Daily Bandwidth More than 100 WLS - 8kb Daily Bandwidth More than 10 WLS - 4kb Daily Bandwidth More than 1 WLS - 2kb Daily Bandwidth Less than 1 WLS - 1kb Daily Bandwidth
New Bandwidth Ratios:
More than 1 Billion WISPS - 8192kb Daily Bandwidth More than 100 Million WISPS - 8192kb Daily Bandwidth More than 10 Million WISPS - 8192kb Daily Bandwidth More than 1 Million WISPS - 8192kb Daily Bandwidth More than 100,000 WISPS - 3584kb Daily Bandwidth More than 10,000 WISPS - 768kb Daily Bandwidth More than 1,000 WISPS - 320kb Daily Bandwidth More than 100 WISPS - 128kb Daily Bandwidth More than 10 WISPS - 48kb Daily Bandwidth More than 1 WISPS - 16kb Daily Bandwidth Less than 1 WISPS - 2kb Daily Bandwidth
- Fix Inflation
Inflation has been set to an initial supply of 5 Million tokens, and 5% inflation. This may be substituted before release for a 10 and 2.5 ratio.
Total Supply = 5,000,000 Tokens Max Inflation = 5%
- Inflation on Creation
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.)
- Remove self tipping
There is no reason to tip yourself that I can imagine.
- Decentralize Development Funds
A role similar to “Witness” has been created, known as a “contributor”. Contributors earn 1/65th the amount of a witness, but can be run without any required hardware. These roles should be managed by the community, ensuring that contributing members receive due rewards for their efforts.
Any member may become a contributor. The available number of contributor positions is 199. There is no cost associated with contribution, and the only responsibility is to earn the favor of the community. This role is designed to support ALL types of contributors, from chain developers, to 3rd party developers, to simple social media promoters and influencers.
- Imply fees for voting witnesses and developers.
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.
Cost to vote for witness: 1 Token Cost to vote for contributor: 0.1 Token.
- Limit number of accounts a user can create per season
This will ensure a quality community. Each user will only be able to create a limited number of accounts per season, refreshing 4 times per year.
Cost to create account: 5 tokens. Created account receives: 1 token Dev funds receive: 4 tokens How many accounts can a user create per year? 20 accounts per user per year, totalling 5 per quarter.
- Friends content for friends only
Content posted to “friends”, should not be displayed in the public feeds. How best to operate this?
API has been modified to accept a signed transaction. Registered users should ALWAYS include a signed transaction to api queries. Queries with no signature will not receive private data in any way.
Blocking has also been implemented, if the signed transaction is included, friends content and blocked content will be parsed prior to delivery.
- Spam Handling
Users begin with a daily_posts parameter of 7. Each POST submitted, this count is decreased. When daily claims are made, the parameter is reset to 7. 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.
- Account recovery
Account recovery has been implemented using the same methods from the steem blockchain. A user has 30 days to recover his account after it has been stolen or lost. It should be noted however, that with new powerdown restrictions, an account can be drained of funds within one full week.
Either account protection services should be built for paying investors, or a savings account of some sort with longer lockup times should be allowed.
- Likes & Reactions
An index for liked content has been integrated, along with a schematic to follow for reactions. Reactions should be handled by top services, but will ideally follow the schematics laid in code.
- Mention Notifications
Users will receive notification when they are mentioned in content. No more than 100 users can be mentioned in one article, and blocking will affect this for users who aim to abuse.
- Lower Powerdown, 7 daily payments
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?
- Cooperative flagging feature?
- Allow tips to be transferred to stake or liquid?
List Items ending with a '?' are not yet implemented in code.
New 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.