RE: The DIV Kernel, A weed that has found fertile ground
I was under the belief that 10 votes per day would drain only 20% (hence the account is back to 100% after 24 hours). I don't actually count my votes, but I'm generally not lower than around 80% even after giving out my daily votes (around 10 of them).
Since you know so much about Steem, I was wondering if you knew off hand how the reward pool is generated? Specifically, what I wish to know is: If there is just 1 person posting 1 article per day, is the reward pool the same size as if 100 people posted 100 articles in a day. And, if there is a larger pool for more content, is that reward pool growth linear? Essentially, what I'm after is; Is it harder to earn rewards with more Steemians participating than it was a year ago when there were far less Steemians.
I agree that re-inventing the wheel is a waste of time. Why create totally new software when perfectly good software already exists! The idea is to integrate the various software into a seamless experience for the end user. Ultimately, the end user expects to be able to intuitively begin using a product without the need to read a manual or learn new tricks. This is where Steemit falls down in its clunkyness.
The rewards pool is essentially the daily allocation (or weekly, in this case) refilled on a moment to moment basis that is the supply rate of new steem (or, in this case, to be precise, VESTS, which are allocated into steem, SBD and SP).
So basically, at every block, a witness calculates the rewards to be given out to the pending and due rewards, makes the payouts in the chain, calculates the correct refill (it has to vary up and down in a short time window because of the constant variance of how much rewards are given out in a block). The rewards are based on the sum of the VESTS tied up in SP, divided over the amount of rewards pool in time, which is tracked and kept towards an average.
I think the off the shelf components are servicable, but would not work in the long run, because the design I have in mind goes beyond simple blockchain, and uses new models that you can find examples of in 'Byzantine Fault Tolerant' database systems. In fact, I may end up using one of those, there is about 6 major projects I can dig up that I have read about. The thing is though, the latest stuff from Eric Freeman, which involves using gossip protocols to prevent forking of the chain, is much much much faster than the standart blockchain chatter protocols and confirmations system like you see with bitcoin and also to some extent with Steem and others. This methodology sees zero forks and sub 1 second clearance, and a 1 minute max total time to 100% confirmation.
So, while I will use the more old-strategy replication protocol built into Tendermint, and its basecoin for the ledger, I intend that as quickly as possible we get to implementing these more advanced techniques.
I think that, to build an incentivised self-hosting development platform at the centre, first, enables us to more rapidly find and make use of developmennt talent, and ideally, even, so much so that we are taking from the pool of blockchain type development people because our rewards are better and more motivating than any deal a corporation could offer.
Between what you wrote and what the Whitepaper says, it seems that Steem is growing at 100% per year (based on the original vests held). 90% of that is re-distributed to content creators. So if I am correctly interpreting what I have read, the answer to my question is that if 1 person contributes posts the 1st year and 2 people contribute post in the 2nd year, then the reward pool has grown proportional to the number of contributors and the rewards will be about the same in each year. However, if the number of contributors outstrips the growth rate of Steem, then as the number of contributors grows, the rewards will be proportionately less for each contributor.
Without fully understanding your new ideas, it does sound like you are looking at building a superior system that will take advantage of all the best things available. Have you seen any interest from prospective developers yet?
The whitepaper has not been updated. The interest rate is now about 9.3% (issuance rate).
Yes, this problem of crowding of the pool has been an issue all the way along. This is partly why I have designed into DIV a contrary rate issuance that lowers issuance rate as user activity accelerates beyond a certain point, or in other words, reduces the pay rate when there is too many users to share out evenly, and vice versa, when there is not enough, the rate increases
This is designed to front-run the network utilisation so that where as it does here, in a lagging fashion at first everyone gets less and less when there is too many, and then with the excess tokens dumped on the market, the effective value of the earnings are reduced, after a period of congestion, and then causing a sharp drop-off in users, and this again causing a lagging reaction in the price.
By lowering the rewards as activity accelerates, it naturally will brake the activity before the excess supply hits the market, allowing the price to remain more stable, and vice versa, as activity slows, the rewards are suddenly a lot higher per capita, and this will naturally draw more users to compete for it (which will then slow the rate down). This, combined with zero liquid rewards, and a daily 1% drawdown, should see the outflows of capital dramatically much more stable than with Steem, which will make it much more attractive as an investment.
Without using a stupid hedged instrument, complicating the monetary system like is necessary with Steem, where VESTS have a rate against Steem and a rate against SBD, this will just have 1 token, and a deposit contract with a random interest payout with a transaction volume driven issuance rate for interest on the contract built from necessary change operations (this sounds like a mouthful, but it is based on the property-registry token model called Refractory Token Ledger). Initially, using basecoin it will not operate quite like this, but eventually this token will be phased out once the RTL is implemented, and converted (I haven't cooked up the scheme for this.
I hope that the combination of a monetisation system for peer reviewed code and documentation writing, and the clear advantages of the architecture, all derived from observing the operation of Steem, that indeed, there will be a flood of developers and what took a year for people to build for steem will be done in 3 months.
:)
Gee, it seems you have already put quite a lot of thought into this project. I was going to ask what the timeline was but you already answered that.
Well, it depends on me getting started. I have been contending with health issues, the detox, most recently getting my miners back, and puting out a decent yield of bitcoins, and I am only just now starting to be ready, I will be switching back to running linux shortly (I am only running windows to boost my mining yield a little while I clear up some inadequate balances on nicehash accounts).
Yes, I have been conceiving this design since I first started here with Steem, the design so inspired me. I posted many many many proposals for improvements and absolutely none have been implemented. The HF19 bugfix update v0.19.1rc1 'coincidentally' was released after I made this post:
https://steemit.com/ned/@elfspice/when-are-we-getting-bufgixes-stinc-an-open-letter-to-ned
Not a coincidence, if you ask me. Though others had been baying for this for a time beforehand, I had also commented numerous times since becoming aware of the self-comment-vote problem, that there was serious bugs. about 5 minnows complained of having bandwidth errors unable to post any transactions, transfers, even rewards claims. It did not escape my attention how much time Jesta and other RPC operators nodes were having downtime either.
It has been this incompetence and total, abject disregard for the welfare of the userbase that made me decide that it was time to get serious about building an alternative, and that lead to a lot of thinking through and refinement to what you see now, the DIV Kernel concept.