News for hackers. Stuff that matters.
Re:Time-Lock Encryption (2011) by joosters on Monday October 13, 2014 @03:17AM (#8447790)
I see that several suggestions involve using the Bitcoin blockchain to provide a fixed time delay. (Since blocks are given a varying difficulty so that only 'x' coins are produced an hour.)

However, IMO a much more interesting idea is the reverse of this: use time-lock encryption in bitcoin itself. If we can decide upon a non cpu-bound mechanism (and non memory-bound) then suddenly bitcoin can be billions of times more efficient. We wouldn't need thousands of miners constantly hashing the blockchain to solve an arbitrarily complex problem. Instead, the time lock can be used to ensure only 'n' Bitcoin are mined per hour, just like now.

This would save all the wasted CPU time (and considerable power costs) that Bitcoin currently relies upon.

Re:Time-Lock Encryption (2011) by vog on Monday October 13, 2014 @03:59AM (#8447869)
You may want to reread how Bitcoin actually works, especially about transactions and the proof-of-work concept.

The "wasted CPU time" is Bitcoin is not about mining, but about signing transactions. Sure, it makes it constantly harder for miners, but it also makes it constantly harder for attackers to insert fake transactions (that could make real transactions appear to have never happened, opening the possibility for all types of fraud).

This is what this whole "wasted" CPU power is all about. Increasing the "efficiency" of Bitcoin would destroy this security mechanism, making it almost trivial for attackers to game the system.

Re:Time-Lock Encryption (2011) by joosters on Monday October 13, 2014 @04:37AM (#8447951)
Not at all. There is an artificial difficulty added to the hashing and signing to ensure that only a certain amount of bitcoins are mined per hour.

The security in the protocol comes from the distributed effort whereby everyone verifies other people's hashing. The difficulty level does not make it more or less secure.

Re:Time-Lock Encryption (2011) by lmm on Monday October 13, 2014 @06:14AM (#8448137)
Having all that hashing going on is what makes the "distributed verification" meaningful. An attacker can compromise the bitcoin network if they comprise 51% of the overall hashrate. So if you lower that hashrate, the network becomes more vulnerable.

The ratio of hashrate:"mining reward" is arbitrary, a matter of monetary policy (one reason I believe Dogecoin is a much more viable long-term currency), and we could (if there were a network consensus) adjust it to give people more or fewer bitcoins for the same amount of hashing work. But there's no way to "save all the wasted CPU time (and considerable power costs)". Security relies on the network doing more hashing than any attacker could.

Re:Time-Lock Encryption (2011) by joosters on Monday October 13, 2014 @07:01AM (#8448206)
It still doesn't make it more vulnerable.

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.

(In fact, if you had a bitcoin system whereby mining didn't use 100% cpu, I'd guess that more people would mine, since you could use miners for other purposes and not be forced to buy a dedicated miner box.)

I'm not talking about the mining reward either, that's irrelevant. If the reward for a mining block is 10 bitcoins, and the difficulty level is such that each block will take 5 minutes to mine (n.b. numbers made up, no idea what the current values are), you could drop the difficulty so that a block takes 5 seconds to mine, but are time-locked so that the next block can still only begin to be mined after 5 minutes.

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.

Re:Time-Lock Encryption (2011) by lmm on Monday October 13, 2014 @07:08AM (#8448227)
> 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).

Re:Time-Lock Encryption (2011) by joosters on Monday October 13, 2014 @07:30AM (#8448266)
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.

Re:Time-Lock Encryption (2011) by vog on Saturday October 18, 2014 @04:47PM (#8476249)
> 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).