RE: Proposed changes, copied from Calibrae Team Project Board
that's efficient, miles wide in improvements. First of all the space, the chain will be light and easy to update with the hashes and with the scrapping of the SBD, I for one don't quite like it but for efficiency it's maybe 1/5 or 1/3 improvement and simplification.
You are also turning into a wallet, hopefully a lightweight app can be made, one that doesn't have t sync in all the posts and everything, so it would sync for maybe an hour, but you said downloadable image, so you could even torrent it (p2p download)
Number five quickly gets out of my math and logic skills, but seeing reputation have some stronger effect is nice.
Six I also don't get
Seven is logical, an easy way to solve self votes, buuuut I'm not quite sure, sybil attacks are still possible, it would be harder and it sounds like the chain will have stronger "defensive" measures, even if it could be negative, since people can abuse flags to attack accounts. So wars would have a real effect, well a stronger one, than just reputation and lowering of payout, since one transaction per day is well little.
a quick question curation split would mean bigger cuation rewards?
I'm not sure what shimmer refers to, but I think I get the idea, I could help you with the namings I suppose.
And to ask about point 8 could you draw all your stake in 100 days or will it never really be able to draw, meaning if you have 50 you would get .5 per day or just the first one then .495 then ...
Unlike most other blockchains, a steem wallet is always a light wallet, it queries a full node for the current state.
I don't know what can be done to prevent the necessity for RPC nodes to replay, I would think that will take a substantial change, that is, graphene would have to be removed, replaced with a better engine like Dgraph and maybe some kind of large blob specialist data store for the forum, and then, without constant changes in the format of the shared_memory, it could be possible to use a bittorrent protocol to propagate snapshots to quickly sync new nodes.
The reputation calculation will be easy to determine, it just requires tracking the highest reputation score account and then performing a calculation against the account to generate its resultant vote weight.
Number 6 means that when you activate a witness, your normal witness votes are not counted, and instead just a single vote for your own witness replaces it in the calculation. When the witness deactivates, your witness votes are again added to the calculation for the others. Obviously this implies you can't vote on other witnesses when you are running a witness. This is to stop collusion and blackmail between witnesses, when there is witnesses with high reputation and stake. And yes, reputation will also limit the witness vote weight calculation.
Stopping indirect self votes will be possible to do on a community level, where people can investigate links between two suspected sybils, and when these links are substantial, people can then smack down the both accounts and counter their misbehaviour.
The curation split will mean bigger rewards, but remember, every post will be by default self-voted, so, in accordance with your reputation score, you will always have the first share of curation reward that will add to your author reward. They are all going to be only in stake, but stake withdrawal proceeds as a 1% conversion of remaining Stake per day, which makes your account more liquid and eliminates weekly peaks in powerdown cycles (it will become intraday, which is by its nature going to be less volatility).
Shimmer is the name of the fork of the Steemit web interface, that you are probably using right now. Shimmer refers to the way that hummingbirds move so fast you can't see their wings properly, and how fast they can move left and right, like a mirage.
To calculate how quickly you can draw down your account, take the number 0.99, and put it to the power of the number of days, basically, it simply cannot be completely drawn down. After 365 days, there will still be about 2.5% of the account balance of Stake remaining. To illustrate this, here is how much will remain after some number of days:
after 7 days 93.2%
after 28 days 75.47%
after 90 days 40.47%
after half a year (132 days) 26.53%
after 365 days 2.55%
Essentially, this would function to enforce minimum balances, without making them a limit that leads to an account being unable to transact. It's kinda dumb to be able to draw down an account until it can't be used! I think in theory you could have it do that, or, more logically, the consensus could say that if the next payout from drawing down your Stake, that it will disable the power down, if it would take it under the minimum.
Not handling boundary conditions in a user friendly way is not the way I write code. This is one of many clear examples of not handling boundary conditions you can find in the Steem code. HF19.1 included a fix that was causing witnesses to waste time calculating interest on SBD when it was set to zero! The proper algorithm should first check 'is interest nonzero?' which is a very simple and quick test that saves calculations. This is called 'lazy evaluation'. The code does nothing, if there is no reason to do anything, instead of multiplying things by zero to get the amazing answer of zero.