Author

Topic: Is it way to workaround historic attack to POS valutes? (Read 171 times)

jr. member
Activity: 117
Merit: 4
According to topics https://bitcointalksearch.org/topic/proof-of-stake-bitcoin-2050869 https://bitcointalksearch.org/topic/proof-that-proof-of-stake-is-either-extremely-vulnerable-or-totally-centralised-1382241 I was so interested this problem, but not found (or looked bad?) any workarounds of this type of attack.

It seems most applicable to our reality, especially it is growing interest for proof-of-stake consensus according to mining taxing by governments in near future.

Subj

Let's imagine: evil developer friend has privatekeys of 100% valute at early-early time. It is pure pos valute (like newbie tokyocoin - https://bitcointalksearch.org/topic/annpostokc-tokyocoin-new-pos-algorithm-free-airdrops-2256367), even it was POW phase - we assume, that 100% of coin supply is under control at time of first POS block.

In some bright morning he builds offline chain, that is longer that main chain with no movements, feeds legitimate clients by it and continues to hold 100% of coins as from start. Workaround from this is adding hardcoded checkpoints to client, but there is trusting for evil developer (which holds privatekeys for signing checkpoints too) and unaceptable for us;
If there is any restrictions for reorganization depth, new nodes would be fooded with malicious chain and network growing is stops - it is unaceptable too.
There is a way to build masternode authorities with collateral mechanism, but I think, that it will be needlessly, because it stimulates extra centralization of coin (and gathers 51% stake accumulation), and, as I think, each UTXO in POS is little masternode by all indications. And, in addition, evil developer's chain will also has masternodes and all in-chain ecosystem as he wants in case of global reorganization.

So, we need third trust party for store consenused blockchain fingerprint, but wouldn't trust any human-influenced factor and avoid to hardcoding (keeping in mind, that dev==evil) any keys.

If we write any checkpoints into other blockchain like BTC/LTC/DASH/other_notonlypow_chain (we can write some payload into regular transactions, or even mine blocks and add checkpoints as miner signature - it is tactics), we can explain client to communicate with "trusted" blockchains at initial validation / reorganization time to proof checkpoint.

In this situation there are some problems on the tip:
1) we must reward foreign blockchains in these blockchain's valute (i.e. pay transaction fees) - so we need any funds in theese valutes - but node can implement foreign wallet, can increase reward for donating foreign coins or can parasite with 0-fee transactions - so workaround seems possible, but need advice
2) evil developer can buy checkpoints for malicious chain - but we can use first come - first get principle to ensure, add trust value of network proportional to count of foreign checkpoints and it's confirmations count (but evil may be so rich and can buy checkpoint for every malicious block) - so it needs to be discussed, but seems
implementable
3) foreign blockchain can die - it can be hardforked or leaved by human and stops - then we must use several bearing blockchains and gracefully catch possible dyings, keeping in mind problem 2
4) anything else, that I can't view/misunderstand

Please, advice me, if it is any fundamental mistakes in this post, and sorry for my english Smiley
Jump to: