Not every perceived solution in code is exclusively a solution... sometimes they introduce new problems

I've often been talking lately about many of the problems we are likely to encounter on steemit, and the steem blockchain being situations where we as a community should see if there are community ways to solve it before rushing to hard fork and code as the solution.

I've also written about people that take the "code is law", or "the code allows it so it must be acceptable" approach as not necessarily being completely accurate as well.

This time I want to talk about something I've mentioned before. When we propose a code change that is often a knee jerk reaction to X is bad so let's make it in code so you can't do X. Usually a new exploit or problem can arise. I've been waiting until I had a good example to go over this. I finally thought of one so it is time to give you an example of why we need to be careful in rushing to CODE CHANGES as the default easy button solution.

We know there was an issue post Hardfork 19 with people up voting their own comments excessively. It was not a lot of people but there were enough people with sufficient steem power that it was having a noticeable effect on the reward pool.

This brought the people saying REMOVE SELF VOTING and that will solve the problem.

To which I responded that all a person needs to do is create one or more accounts and they can either delegate power to those accounts and resume up voting themselves, or they can take the slower route of actually moving some of that power around. Power down, send steem to an exchange, from exchange send it to another steem account, power it up, and resume voting for themselves.

Obviously the delegate method takes a lot less effort, and if anything is obvious it is that people really love the EASY path. So this would likely be the most common way to do it.

An interesting idea was to not allow someone to up vote themselves, or any account delegated power by themselves. I mentioned daisy chaining delegation to which they responded just follow the chain. This actually would work though I suspect there would be a performance hit for needing to do this...

That's where I left it. Until today. I thought of an EXPLOIT and new problem.

If delegating power to an account was part of the method of determining whether that account could up vote you then here is a negative attack exploit that comes from that. Let's call it Mega Troll for now just because it is sometimes fun to give hypothetical nasty things names.

Mega troll starts delegating extremely small amounts of his power all over the place. This would effectively block anyone delegated such power from up voting anyone else that they also delegated power to. I don't know if there is a way to refuse delegation of power so simply due to this one well meaning idea to address self up voting it opens a potential for someone to intentionally block massive amounts of people from voting.

So when people rush to CODE SOLUTIONS. Code can often create new exploits.
So the code is not always the answer. Likewise, because we can do a thing does not mean we SHOULD do a thing.

Next time you find yourself thinking "They should just do this..." and talking about code change I hope you will begin to consider that it is not always so simple. We must try to imagine ourselves as the bad guy and think of what new opportunities such a change might present to us. This is one way of deciding if the code idea is actually worth pursuing.

Code is often the way it is simply because the coder/programmer could not think of a better way. That usually doesn't mean they themselves would not welcome other solutions.