This is a summary page for witness candidate arhag.
Hello everyone. I am arhag. I started getting involved in the cryptocurrency space towards the end of 2013. In mid 2014 I started heavily participating in the BitShares community. Over the course of two years time, I think it is fair to say that I have made a good impression to the BitShares community as a valuable member of that community through discussions, proposals, ideas, helping others and more that have mostly occurred on the Bitsharestalk forum.
I have recently joined the Steem community and am an active member in this community as well. I am very excited for the potential provided by a social media platform on a blockchain that financially incentivizes posting/commenting and curation.
In the short time I have joined this community, I have already made many significant contributions to Steem.
Contributions to Steem
I have a very good understanding of the Steem codebase for someone who is not a Steem core dev, so I have been able to accurately answer many detailed questions by people on the Steem slack.
I have and continue to keep thinking about ways to improve what already exists in Steem through various proposals that I have brought up for discussion. Many of these discussions can be found on the #proposals channel of the Steem slack that I started, but some are also posted on Steem itself, such as: figuring out tweaks to comment rewards and an unexploitable way to allow vote updating (still working on the unexploitable vote updating part), suggesting a way to do private/encrypted (group) messages on Steem, requesting MathJax support to allow typsetting of math on steemit.com which can help attract certain communities, and many more to come.
I have reported numerous small bug fixes and UI improvements (almost too many to list) both to Steem blockchain nodes and also the steemit.com GUI client. These bug reports are scattered throughout the #potential-bugs and #steemitwebsite channels of the Steem slack, and, for the more notable ones, on the official GitHub repository.
Some bugs were far more serious that it is worth mentioning separately. I have discovered and proposed fixes for the three following bugs (ordered from least significant to most significant):
Discovering that the curation rewards calculation was not done correctly in the code.
Discovering and reporting a serious bug with the report double sign operation that would have allowed anyone to steal the SP funds of any account that had recently produced a block. (@abit deserves credit for this one as well.) This operation has now been disabled until further review.
The fixes for all three of the above items were activated in the fourth hardfork that occurred on April 30, 2016. For the case of item 2 (the virtual scheduling bug), I also wrote and tested brand new code for the new and more robust witness scheduling algorithm that was merged into the official Steem codebase and is currently running on the live Steem blockchain.
Operating witness nodes
The above is all well and good, but at the end of the day my job as a witness would be to reliably operate the witness with maximum uptime. I have been following good standard practices from the beginning to safely and reliably upgrade witness nodes for hard forks on a live network. So far I have been successfully operating a witness node for the last few days (as of today, April 30, 2016) without any problems and I have maintained a relatively very low missed block count. I have been quick to respond to all the emergency hardforks (we have had 4 hardforks already) that we have been forced to have recently. Also, I am in a position to scale up resources to handle increasing network demand as needed.
I hope to update this post later with other witness-related goodies like a custom price feed (and extra) bot that I am currently writing for Steem.
Voting for a witness is an important task as a stakeholder in a delegate proof of stake blockchain. The stakeholder must do their due diligence to vote for trustworthy people that they believe are unlikely to maliciously cause damage to the network (e.g. by colluding with other witnesses to censor transactions thus causing temporary selective disruptions to the network) and perhaps more importantly have the technical skills to not accidentally cause disruption to the network (e.g. through failure of their witness node and not putting enough redundancy in place, or by messing up a hard fork transition). I hope this post has provided some reassurance that I meet both qualifications.
But being a witness is a competitive position. There are only 19 spots for reliable witness generation, only 30 max votes per account, and so many qualified candidates. So voters must decide for themselves what is the best metric to distinguish viable candidates from each other. I hope my contributions listed above are helpful in guiding you in your decision.
If you do decide to support me as a witness, please vote for me with all of your SP holding accounts using the following command in the CLI:
vote_for_witness youraccount arhag true true