Miners.
Correct. Or mining pool operators.
More specifically the software that is being run by solo miners and mining pool operators.
ranchigo is pretty close with his explanation.
Each solo miner, and each mining pool operator builds their own block to work on. The block is has to meet certain requirements or the rest of the network will simply ignore it. As long as it meets all the necessary requirements, anyone can create their own block and then work on solving it.
The order of the transactions in a block isn't entirely random, but the solo miners and mining pool operators are allowed to select whichever unconfirmed transactions they would like to include in the block as long as the inputs to the transactions are either already confirmed or are included earlier in their list. The total size of the block is not allowed to exceed 1 megabyte. The block MUST include at least 1 transaction (the generation transaction that pays the newly created bitcoins as a block reward, sometimes known as a "coinbase" transaction).
As ranchigo stated, the software being run by the solo miner (or mining pool operator) chooses an order for the transactions and builds a merkle tree. The merkle root is unique for that specific selection and order of transactions. Any other selection or any other order (or any different generation transaction) will result in a completely different merkle root.
Then the software run by the solo miner (or mining pool operator) builds an 80 byte block header. The header consists of:
- A 4 byte block version number
- The 32 byte double-SHA256 hash of the previous header
- The 32 byte SHA256 merkle root of the transaction list
- A 4 byte timestamp
- 4 bytes representing the current mining difficulty
- A 4 byte nonce
As you can hopefully see, since each solo miner (or mining pool operator) will pay the block reward to themselves, they will each have a different generation transaction. This means that they will each have a different merkle root, and therefore they are each working on completely different blocks.
They each repeatedly hash their 80 byte block header and check to see if the resulting hash value is lower than the current difficulty target. If it is, they broadcast their block to all their peers. Each peer validates that the block they just received meets all the consensus requirements and then relays the block to their peers. The block continues to be validated and then relayed by every node that that receives it until the entire network is aware of the new block.
If the hash of the block is NOT lower than the current difficulty target, then the miner increments the nonce and tries again. They keep doing this until they either find a low enough hash value or they run out of nonce values (a 4 byte nonce has 4,294,967,295 possible values. If they run out of nonce values, then the software run by the solo miner (or mining pool operator) needs to find some other way to modify the 80 byte header. Since the version number, previous block hash, and difficulty can't be changed without ending up with an invalid block, the software will typically either modify the timestamp or modify the transaction list and generate a new merkle root.
Eventually someone somewhere ends up with a valid block header that hashes to a value lower than the current target. When any solo miner (or mining pool operator) receives a block from a peer, they verify that the entire block is valid. If it is, then they add it to their own blockchain and relay it to all their peers. Then they remove from their own list of unconfirmed transactions any transactions that were in that block that they received. They then build a new transaction list, a new merkle root, and a new block header with the new hash from the block that they just received and they start the whole solving process all over again.
