@devteam. There are new feature with POS consisting of delegating stacking power to an address without having coins in. That's a huge security improvement for staking.
One can sign offline the delegation tx to an address and use the created address to stake securely without exposing coins to the network.
Do you see what I feature I'm describing ?
We should have this.
Hello Sardokan,
Thanks for your input.
This is not a new idea. There are quite a few approaches and discussions elsewhere about staking delegation. If you could cite your particular source, we could have a more detail discussion about it.
In any case, this is something that will impair decentralization and we need to think carefully.
Peter
I'll try to find some sources. It's mostly work and discussions around nxt ethereum and peercoin.
The issue with POS in my opinion is to have the private keys controling coins online.
Mi goal would be to have an address controling my coins, in cold storage.
Use it to signe offline a tx granting the weight of my stack in an address that can sign to secure the network but can't move the coins
As long as the coin are still in offline address unmoved. The other address can stake.
The purpose is not to delagate my node to a web wallet. But have offline storage.
I can see the centralisation danger. But if we (big holders) continue to run our nodes and stake. Even if small holders delegate. I think it should be ok for decentralisation and security.
Thank you so much for your comments.
Glad to know that you won't delegate.
However, we can't simply assume all other major holders won't do it.
If your source came from nxt or peercoin discussions, I knew about that already.
While we shouldn't underestimate the centralisation risk, I fully understand why you want offline storage and would like to see a lower-risk approach to address your concern.
Just FYI about the current situcation, in case you may not be aware of, our new v1.5 client does have some security fixes implemented to help reduce the risk of putting coins online.
In particular, our v1.5 client now has timing-attack resistant that can avoid RPC password attacks.
Of course you still need a strong combination of RPC username and RPC password, as always.
Peter
