PoW power consumption is what makes bitcoin secure. IMO there is no problem to solve here. There is big propaganda made by altcoins criticizing bitcoin TPS and energy consumption...
You are basically staking energy, which is something from outside the blockchain, something valuable in our world and society as we know it. This is one thing that gives value to bitcoin. (the opposite of staking coins, which you are staking something from within the blockchain itself)
Bitcoin is not wasting energy to generate blocks, it is using energy to create value and utility.
Miners also mine in places where energy is cheap, and those places are usually where the generation of eletric energy is bigger than the consumption.
I saw just now this
video from Antonopoulos where he explains that it is easy to bash bitcoin energy consumption, because it is transparent. But you cannot see how much energy banks consome (with buildings, bureaucracy, security, guards, etc)
I would contend that the security comes from sheer computing power/hashrate rather than how much energy is used to run the computing power..
It’s “the next 500 supercomputers in the world can’t compete”, not “the next 500 power plants in the world can’t compete”..
(Probably much more than 500 since this saying was a thing, and it’s never been about how much electricity it would take)
If the NSA wanted to 51 Bitcoin, do you really think they would care how much electricity it took?
Neh, they can make plenty of energy.. They have the energy, what they don’t have is the hashrate/processing power..
It would only take about 1 day to 51 Bitcoin, and they could use an entire nuclear power plant, or 10..
The cost of burning that energy for one day is nothing compared to the cost of burning that energy 24/7 to KEEP it secure..
Energy doesn’t matter, it’s the hashrate that keeps Bitcoin secure, because they don’t have the hashrate to compete no matter how much energy they have/use..
Bitcoin could keep the same hashrate and use less energy, by only hashing in bursts, thus allowing miners to buy even MORE hashrate with their savings, and even put all of the old currently inefficient miners hashrate back online to increase hashrate, because it would be profitable again..
Might even make CPU mining profitable again until hashrate grew to make it a competition of efficiency again..
Would incentivize a massive amount more hashrate and INCREASE DECENTRALIZATION to higher energy cost areas..
Mining on almost anything would become profitable until hashrate atleast tripled..
Hashrate would go through the roof.. And thus also security..
You don't need to generate random numbers or anything crazy like that, it can be done by changing how next target is computed by using different number of previous blocks to get the time. For example "If last block was mined in 2 minutes, reduce difficulty by 80%; Else set difficulty as it should be based on past 2016 blocks". Roughly similar to what we are doing in testnet but only when the time between blocks are 20 minutes.
Here are two major problems with the idea:
1. As it was mentioned above, there is no universal clock in the decentralized network that determines "what time it is". Your node may say it is 14:05, my node says it is 14:30 and another can say it is 15:00. That's why we take the average of all times we get from the peers.
2. When you reduce the difficulty, the hashrate doesn't go away. It is still there and when the difficulty is reduced by 80% that massive hashrate can find the next block in an instance. Now we are facing an easy to perform 51% attack.
If you want blocks/solutions found in 2 minutes you adjust difficulty so on average a block/solution would be found in 2 minutes with full current hashrate right?
It’s hashrate vs hashrate..
I don’t see how reducing the block time to find a hash faster would somehow give a minority hashrate(pool/attacker) any advantage.. They would still need 51%..
Ok, average of node clocks having passed 8 minutes of idle time before the 2 minute hashing session begins (with difficulty set to take an average of 2 minutes for X hashrate to solve a block solution)
I think you would still need a random number published after the 8 minute idle time hashed into the next block to PROVE that the miners only starter hashing after the 8 minute idle time is up, or they would just mine the entire time and hold the solved block until after the 8 minute idle time, in which a cheater could 51..
The point of the random is to MAKE them wait the 8 minutes before they started hashing, or they would be hashing for nothing, because without including the random number (starting pistol shot), their block would be invalid.
I’m still talking 10 minute block times, but instead of hashing for all 10 minutes of every block, a random number could be released after 8 minutes, like a starting pistol shot, for a 2 minute hashing sprint at the end of every 10 minutes..
Their solution would have to include the random to prove they started after the 8 minute idle..
8 minute idle-release random after the 8-2 minute hashing sprint (difficulty adjusted to find solution in 2 minutes)-block still found/added in 10 minute increments
Would probably also reduce the variation in actual seen blocktime too..
Variation in shorter block times is less (I imagine it’s likely a percentage), and would still only have blocks every 10 minutes on average to keep the blockchain a manageable size (decentralization)..
This won't work.
At 8 minutes somehow generate random number (possibly use last/nearest tx broadcast closest to 8 minute mark as the random number?).
Next block must be solved including hash of last block and random number generated to prove work started after the 8 minute mark since last block solved.
Who determines what the random number is? Transactions are not timestamped when they are broadcast, and there is nothing to stop a miner from broadcasting their own transaction 8 minutes after the prior block was found.
Also, block timestamps are not the exact time a block was found, it can have up to a two hour variance, so it is possible for block n to have a later timestamp than block n + 1.
Still requires the same amount of computing power giving same security, but miners only run for 2 minutes out of every 10 minutes instead of constantly..
Reduces power consumption by 80%..
It takes time to shut down a miner, and to start a miner. The power savings would not quite be 80% under perfect circumstances.
I think this would encourage miners to backdate (or back time) found blocks, and withhold the blocks until the next block is broadcast, creating many orphans.
I do find this to be a valid point..
I’m not a code genius..
How could a starting pistol shot random number be programmed to be broadcast after an about 8 minute idle period to start the 2 minute hashing sprint?
Thus proving they didn’t start hashing until the idle period was over..
The way I’m imagining it, until this random number was broadcast after the idle period, they wouldn’t even have anything to work/hash on, because they don’t yet have all of the information they need to create a valid block at all..
Nodes would reach a consensus as to what this random number is after the idle break, and not accept a block that did not include it the random number.. Block would be invalid without it..
Somehow..