> so once Ethereum finishes its switch over to proof-of-stake
Isn't there a lot of uncertainty as to how well proof-of-stake will work?
Isn't there a lot of uncertainty as to how well proof-of-stake will work?
It seems like Python 2 is still pretty prevalent, with over 40% of new downloads taking place as of last year. And people forget Python 3 was originally introduced in 2008. So the transition is taking decades, not years.
The last place I worked was still using Python 2 as of last year, and they were a startup without all the bureaucracy of a big company. They also had plenty of money and engineers. Python 2 is still the default for everybody I know.
Anyone using Python 2 at this point are either supporting legacy software, getting their runtimes/packages from distros rather than PyPI, or otherwise completely checked out of the modern Python ecosystem.
https://transactionfee.info/charts/payments-spending-segwit/
Starting with January, python 2 was officially EOL, and many packages dropped support for it. Right now developing for Python 2 is kind of tough, because most dependencies won't work.
I mean if you don't touch your code it will continue to work but if you have to maintain it, you quickly realize that a lot of your dependencies will refuse to work.
It might be easy to fix them to work again, but with time it will be more and more work to do.
But there's no political reason to believe that they won't just push it out again. It's just a ceremony at this point.
Proof-of-stake is vulnerable to various miner collusion attacks that Bitcoin is not vulnerable to. The gist of it is that casting multiple conflicting votes (sometimes way after you cast your original vote) doesn't require any additional resources in a proof-of-stake system, whereas casting additional votes in a proof-of-work system is very expensive.
Each node picks a random value, and publishes the hash of it to the blockchain, then, when the network has reached finality on what all the hashes are, the nodes publish the random values themselves, and the network takes the XOR of all of them.
The protocol could even increase the stake needed to be one of these random value providing nodes, every time such a failure occurred, to make such an attack more and more expensive.
That's probably true in general, but I was assuming that the random number generation would be decoupled from the process of actually building the consensus.
As long as the loss of stake can happen and be finalised as part of the transaction history, then eventually the attackers will run out of money and the random number generation process can catch up and start generating more entropy.
It's a hard thing to get right.