5 ms·

As for proof of work, am I right in assuming it works like this :- Add a field to store a random number. Keep generating values for this field until the hash o

• wildbunny 9y ago
  Again, that's how it works, but not why it works. It bitcoin it is used as an unforgeable proxy for elapsed time.
  • bogomipz 9y ago
    >"It bitcoin it is used as an unforgeable proxy for elapsed time" This sounds pretty interesting, can you elaborate on how exactly its proxy model for the passage of time?
    • wildbunny 9y ago
      In a p2p environment, timestamps are totally useless at proving when I sent you bitcoins. However, when I sent you bitcoins is fundamentally important when it comes to ordering transactions, because I can send you bitcoins, but also send them to myself after you accept them. If I can forge timestamps then this attack is trivial to pull off. You need an analogue to elapsed time to solve this problem. Hashes in bitcoin are probabilistic, there is an expected number of hashes required to solve the PoW (on average). Each hash takes an amount of time that cannot be made faster, so you suddenly have an unforgeable, easily provable analogue to elapsed time.
      • bogomipz 9y ago
        That makes perfect sense. Thanks.
• DSMan195276 9y ago
  Yes, that's more or less it. It's worth adding to that description that the hash must be secure in that it does not allow determining what random number to use to get a particular output (I'm sure you already recognized this detail - it just guarantees you have to keep trying actually random numbers to find a result). Also worth adding is that the 'n' (Basically the difficulty) is generally going to need some way of scaling based on how quickly correct hashes were found in the past. This is important to prevent problems that would happen with people being able to generate correct results too quickly (Or even just significantly faster then previously). In particular, Bitcoin's difficulty factor scales such that a new block is found aprox. every 10 minutes, so 'n' is adjusted every so many blocks depending on how fast the hashes were found. Because in the case of Bitcoin, a found block means more coins in the market, it is important that when more hashing power is added, it doesn't result in blocks now being found 1 minute apart. If that were to happen, then you'd have 10 times the number of coins entering the market.
  • e12e 9y ago
    And this scaling of the work factor - is that tied to timestamps in the previous blocks? (Ie - the work factor is something like max(average(time_blockN - time_blockN+1)? [ed: from other comments, I gather that "passage of time" means "added blocks (hashes)" - but I'm still not clear on where the agreement on what constitutes "in 10 minutes on average" comes from - if A sees an addition to the blockchain of N blocks with X proof-of-work, lets call it N * X from B, and sees M blocks with Y proof-of-work from C -- it should be easy to figure out which is bigger of N * X and M * Y (here we don't really assume multiplication, but some way to figure out maximum proof-of-work). But how does A know how long either took? Is the time local, so that A looks at the head of the B and C chains, and considers when A saw this head, and figure the elapsed time based on that?]
    • DSMan195276 9y ago
      Yes, but it is not adjusted per-block, but every 2016 blocks (Which is 2 weeks time if each block takes 10 minutes to find). It's also worth keeping in mind the problem that timestamps are technically forge-able by the miner. Bitcoin doesn't really solve this problem, but it does place requirements that the timestamp of a block be larger then the average of the past 11 (With various constraints). Thus if you presumably have mining distributed enough, then one giving you as invalid of a time as would still be accepted wouldn't end-up affecting things long-term since they can't generate blocks fast enough to heavily affect the average. Still technically an attack vector though.