Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The author misses the point. The security of the Bitcoin network (at least in terms of double-spending) is tied to the level of work required to generate a block. If everyone decided to use only 1% of their computing power, they'd use less electricity, but the Bitcoin network would then be 100 times less secure.

When people talk about "wasting resources", it's an indication they don't understand how Bitcoin works. One might as well complain about wasting resources on SSL when you could just send data in plaintext.



The trick lies in changing the bitcoin protocol. If the majority of clients can agree on a way to use less resources, then that's what will be enforced by the network. If a new bitcoin client enforced a mandatory delay of one hour and invalidated blocks that were made before that one hour, we would effectively have added one hour of idle time to the network. This is not a solution, but it is a demonstration of how the protocol can be altered, as long as the majority agrees on it.


The problem is what you define as "a majority".

If it's just a majority of clients, then an attacker could just start up a million new client processes and outvote the existing network.

If we're talking a majority of unique IP addresses, then anyone with access to a large IP address block could outvote the network. This approach also wouldn't be feasible for IPv6, where IP addresses are not a scarce resource.

The Bitcoin approach is to define "a majority" as the majority that has the most computing power. Because computing power is always going to cost money, this guarantees that anyone wishing to subvert the network needs to outspend all the honest miners.

If you can think of another way of defining "a majority" without needing a lot of CPU resources, a lot of people would be interested in hearing your solution.


> If you can think of another way of defining "a majority" without needing a lot of CPU resources, a lot of people would be interested in hearing your solution.

Let Bitcoins equal votes.

Set up a Bitcoin account for each option in the vote; send Bitcoins to the account associated with the option you prefer. Transaction verification acts as an electoral audit.

That sort of system would give power over the money supply to those invested in the currency, which seems to be exactly what the Bitcoin community wants.


Your solution is bootstrapping in the very literal and very impossible sense.

You can't use bitcoins as votes to verify transactions, because until you verify the transaction chain, you don't know how many bitcoins anyone has.


The question was how to allow clients to form a new consensus. I did not suggest using Bitcoins to verify transactions; rather, I suggested using verified transactions to verify the will of the Bitcoin community.


Forming a consensus isn't the problem; the problem is enforcing honest application of the new rules. Assuming the majority of people in the network are honest, you need some way of determining what that majority decides, within the network itself.


You have completely missed the point. Because the network can observe transactions, using a Bitcoin account as a ballot box, and Bitcoins as the votes, is a transparent, verified mechanism for determining the community's aggregate will.

This approach negates the incentive to create sham clients under a one-client-one-vote system; it has the same benefit over IP-based voting systems, or what have you. Voting with Bitcoins means that that every participant in the economy has a voting power equal to his account balance (if the Bitcoins are returned after voting) or the number of Bitcoins he both has and is willing to give up to affect the vote's outcome (if they are not returned). So those who are more invested in the Bitcoin economy would have more (or potentially more) power to determine the rules of the economy.


I'm not saying that you can't use bitcoins as votes. You could; but any change to the rules needs to be also be enforced within the network, right? So you need some mechanism for figuring out the majority within the network, which obviously can't be done with bitcoins.


The problem is that it is easy to simulate that you are waiting.

  1) Save current time
  2) "Precalculate" the current block
  3) Wait until the 3601th second
  4) Publish the block that you "calculate" in just 1 second
  5) Profit??


If the calculation for the next block requires the (network's validation of the) current block then you can only always calculate one block ahead.


The problem is that other people might have already found other blocks, rendering your block useless.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: