> If the hashing is made more efficient, that doesn't make it simpler for an attacker to grab a bigger % of the total hashing. After all, it's easier for everyone, so everyone can do more.
Sure, but "more efficient" doesn't mean anything when the whole point is to burn CPU cycles. If you figured out a clever algorithm to do hashing 2x as fast, that would just mean everyone did 2x as many hashes, burning just as much power as before.
> End result: Miners race to mine a block, then are sitting idle until the next block time-unlocks. We still have the same problem for the attacker; they still have to take over 51% of the hashrate but as they can't defeat the timelock they have no way to improve their position.
I guess that works, but you're assuming a magical timelock that can be synchronized to the millisecond across the distributed bitcoin network, and can't be sped up by applying more computing power. That kind of timelock seems very implausible; I can't imagine how one would even begin to go about implementing such a thing (given that the whole point of bitcoin is not to rely on any centralized authority).
Sure, but "more efficient" doesn't mean anything when the whole point is to burn CPU cycles. If you figured out a clever algorithm to do hashing 2x as fast, that would just mean everyone did 2x as many hashes, burning just as much power as before.
By more efficient, I'm talking about being able to force all clients to not work 100% of the time by way of the timelock, not about hashing 2x or 3x as fast.
That kind of timelock seems very implausible; I can't imagine how one would even begin to go about implementing such a thing
Nor can I; however that was the subject of the original article that we're all commenting on, it discusses possible solutions to this (none unfortunately are up to scratch). If such a timelock could exist, then you could reduce the CPU load of bitcoin down to minimal levels without affecting the currency.
> By more efficient, I'm talking about being able to force all clients to not work 100% of the time by way of the timelock, not about hashing 2x or 3x as fast.
You can't expect an attacker to play within your rules. There's nothing that prevents an attacker to put all their CPU power against the network.
> Nor can I; however that was the subject of the original article that we're all commenting on, it discusses possible solutions to this (none unfortunately are up to scratch). If such a timelock could exist, then you could reduce the CPU load of bitcoin down to minimal levels without affecting the currency.
If such a timelock could exist, you wouldn't need Bitcoin at all. You could create an entirely new type of network that doesn't need any CPU load at all.
But as of now, the only secure timestamping that doesn't rely on trusting some central authority ... well, that's the proof-of-work concept of Bitcoin. And it works by replacing "physical items" by CPU power (or more exacty, by using energy rather than matter). If you find a third way, it would be great, but it would still have to depend on some physical resource that is limited (and thus being "wasted" for the network's purpose).
Sure, but "more efficient" doesn't mean anything when the whole point is to burn CPU cycles. If you figured out a clever algorithm to do hashing 2x as fast, that would just mean everyone did 2x as many hashes, burning just as much power as before.
> End result: Miners race to mine a block, then are sitting idle until the next block time-unlocks. We still have the same problem for the attacker; they still have to take over 51% of the hashrate but as they can't defeat the timelock they have no way to improve their position.
I guess that works, but you're assuming a magical timelock that can be synchronized to the millisecond across the distributed bitcoin network, and can't be sped up by applying more computing power. That kind of timelock seems very implausible; I can't imagine how one would even begin to go about implementing such a thing (given that the whole point of bitcoin is not to rely on any centralized authority).