You are viewing a single comment's thread from:

RE: HF Proposal: Vote to Reduce Power Down Period to 4 Weeks

in #steemdaolast year (edited)

This isn't a frontend vs chain development problem. It's something that needs a blended approach.

I'm for the change if:

  1. Accounts must opt-in to the 4 week divestment rather than opt-out of it. The 13 week divestment is a security feature that prevents accounts from being instantly cleared out if compromised.
  2. It is treated like an advanced feature and not like a simple click of a button. Frontends should commit ahead of time to provide sufficient information to users who are selecting it.

We have to recognize that while we're aiming to improve our attractiveness to investors we're also reciting "mainstreaming" like a broken record. There's no way to mix advanced and basic. If we try we'll end up with something that doesn't work for anyone.

There are rolling waves of phishing and hacking on Steem. We recently suppressed one such wave. Accounts that are compromised may not know they are compromised as they rely on posting authority through myriad dapps, which does not inform them something is wrong when the hacker changes their keys. It usually takes up to a week for an account to notice they are hacked and their funds are being moved. If they lose a quarter of their powered up STEEM the results to those investors and to the retention of same would be devastating. There's this perception that most phishing victims are new users with no investment. That's false. Most of the victims were active for months if not years and either accumulated or invested their stake. The largest hack (irrecoverable) was about 36k STEEM and the next one down, from an account that then invested and became a whale, was 10k. The opt-in should have a timer of at least 7 days but preferably 30 days, same as other key functions, before the opt-in takes effect. That would add another layer of protection.

Other forms of exploitation that we like to call "abuse" are highly likely to occur but shouldn't preclude implementation. Removal of a capability to halt a potential minor risk isn't the correct response in my opinion. I treat phishing/hacking as a major risk, for the record. Those who haven't been victims yet may disagree but anyone can be next.

At the same time the 4 week schedule holds merit for advanced users who know how to safeguard and monitor their wallets and are active traders. Tying up capital that can be used for trading is pretty stupid. Tying up capital is however necessary to outfit projects and to obviously perform basic functions like curation with any level of enjoyment. Those same advanced users should arguably have the capability to swap their trustee account and recover themselves if compromised.

Whether a divestment schedule change can attract investors is another matter. We're assuming that it will. It's going to take developer hours and a hardfork, both of which are expensive for everyone already invested and involved. Granted it can be bundled with the next planned fork, which would make it more acceptable to the ventures. It's still going to take time from the development team no matter how the code will be approached.

We need to answer the following before we start to the best of our ability:

  1. What quantifiable estimate of value is it projected to add?
  2. How will this change be communicated to new investors?
  3. Will it cause rapid divestment by the current investors?
Sort:  

I don't think we need to baby customers too much, there is inherent hack risk in crypto, bitcoin is way more popular than Steem and has no such safeguards. My ideal implementation would be 4 weeks defacto but have advanced features to increase number of weeks per individual choice, however this will make the code for this HF more complex and we want to keep it light because of SMT complexity already, big risk adding complicated changes to this HF.

I would agree except we are onboarding mainstream users.

I don't think we need to baby customers too much, there is inherent hack risk in crypto, bitcoin is way more popular than Steem and has no such safeguards.

LOL. Because BTC is treated differently than STEEM and people have different expectations from it. I'm using my active key quite actively, because I know that the worst that can happen is maybe 1/13 of my Steem being poof. With 1 week or 4 weeks, the risk of me not seeing when a powerdown happens or when someone has access to my active authority (for whatever reason) is far higher.

however this will make the code for this HF more complex and we want to keep it light because of SMT complexity already, big risk adding complicated changes to this HF.

Keeping it light aka. making it easy is a quick way to add tech debt. If the correct approach is to add a dynamic period, where existing accounts also have to opt-into it, then that is the approach we have to take.

Why should it take developers time to change a number in the code "13" to the number 4, instead. I'm sorry it might be slightly more difficult than that, but not by much. Seems like it could be done in a few days, at most.

Posted using Partiko Android

There are things that can conflict as a result. Although it seems simple its not.