1

According to the bitcoin wiki, the data used comes from calling getwork.

getwork is a JSON-RPC defined at https://en.bitcoin.it/wiki/Getwork as "An RPC method used by a miner to get hashing work to try to solve."

After reviewing the source here: https://github.com/bitcoin/bitcoin/blob/142e604184e3ab6dcbe02cebcbe08e5623182b81/src/main.cpp#L3352 I was unable to determine the code for the GetWork method. I am mostly curious about the source of the data though. Although the bitcoin system is said to be entirely transparent, it seems to skimp on information regarding the data used.

Where/what is the origin of the data that is being worked on by the bitcoin hashing algorithm?

Improve this question
7
  • 1
    possible duplicate of What are bitcoin miners really solving?
    – Stéphane Gimenez
    Jan 13, 2014 at 22:26
  • @StéphaneGimenez - Your answer from the link was informative. However, it merely points out the type of data being solved, and not where it comes from. You state there is data "waiting for inclusion" but give no source as to where that data originates.
    – Travis J
    Jan 13, 2014 at 22:33
  • 1
    Maybe you should clarify your question then.
    – Stéphane Gimenez
    Jan 13, 2014 at 22:35
  • 1
    All the data comes from peers, new transactions and recent block creations. All this is checked for validity and used generate a new block which must then be completed with the right nonce.
    – Stéphane Gimenez
    Jan 13, 2014 at 22:42
  • 1
    @TravisJ Yes, that's right. The client monitors the network, checks everything for validity, and determines the current blockchain. It then looks at proposed transactions and sees which are valid. The current blockchain is all that's strictly needed for mining, but miners generally try to include as many valid transactions as they can as well.
    – David Schwartz
    Jan 13, 2014 at 22:50

1 Answer 1

Reset to default
1

The proof of work that miners do is a double sha256 hash on 80 bytes of data.

Where do the 80 bytes come from?

They are build from enough data to describe the current block (and the transactions it contains) and a pointer to the previous block.

To wit:

  • 4 bytes version number
  • 32 bytes hash of the previous block
  • 32 bytes Merkle root of all the transactions contained in this block
  • 4 bytes timestamp
  • 4 bytes current difficulty target
  • 4 bytes nonce

These 80 bytes are concatenated and have the shit sha'd out of them until the required difficult is reached.

More info

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.