Oleg Andreev



Software designer with focus on user experience and security.

You may start with my selection of articles on Bitcoin.

Переводы некоторых статей на русский.



Product architect at Chain.

Author of Gitbox version control app.

Author of CoreBitcoin, a Bitcoin toolkit for Objective-C.

Author of BTCRuby, a Bitcoin toolkit for Ruby.

Former lead dev of FunGolf GPS, the best golfer's personal assistant.



I am happy to give you an interview or provide you with a consultation.
I am very interested in innovative ways to secure property and personal interactions: all the way from cryptography to user interfaces. I am not interested in trading, mining or building exchanges.

This blog enlightens people thanks to your generous donations: 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo

Problem with Proof of Stake and “coin voting” in general

The problem with “voting by coins” is that most coins do not vote. This leaves a small fraction of UTXO to actually vote which is not representative and highly volatile since anyone risking to use idle keys to a large stash of coins can dramatically affect the voting outcome.

Most coins are locked up well “under matress” with multisig, time locks and possibly even with HSM-controlled keys. Also, pubkeys to long-term stashes do not want to be exposed from under their hashes in order to be better protected against a QC development in the long term.

In other words, most coins that matter, cannot and will not vote.

This leaves only the least important coins to perform voting. Obviously, the result of such voting will be worthless.

UPDATE: it is possible that people annotate output scripts with a dummy “voting hash” that commits to a separate pubkey, intended only for voting and stored elsewhere. But then security of the voting keys is not equivalent to the security of bitcoin keys which is what we want to begin with: that voters perfectly map to actual bitcoin holders.