Hello Again,
So Danny, you said that miners don't search hashes with 0 at the start, but why then all block hash have 0's before? for example:
https://blockexplorer.com/block/0000000000000000008664c500e67e68ecc775868eaad375183a9b92b121abf1
Because the hash has to be lower than the target value.
During the time in which that block was mined, the target was:
0x000000000000000000c1bd000000000000000000000000000000000000000000
And this value:
0x0000000000000000008664c500e67e68ecc775868eaad375183a9b92b121abf1
is less than that target.
Note that the following value:
0x000000000000000000e673b61ff56f79fbd866759f9be284292b8ca3a230bce0
has the same number of zeros, but is NOT valid, because it is higher than the target value.
And:
When a node receives a transaction, if the transaction is correct, does the node broadcast the transaction? before being added to a block?
Full nodes validate transactions and then send the transaction to all connected peers that have not yet received the transaction.
This is why you see a transaction that was sent to you immediately, before it is confirmed. The sender didn't necessarily connect directly to your node (how would they know where to connect to?). Instead they sent the transaction to the peers they were connected to, and those peers sent it to the peers they were connected to, and those peers sent it to the peers they were connected to, and so on until it got sent to a peer that you are connected to, and that peer sent it to you.
Note that this is also how the miners and mining pools find out about the transactions so that they can add them to their blocks. Nodes and wallets don't need to know the IP address of EVERY miner on the system. For that matter, they don't need to know the IP address of ANY miners on the system. They just send the transaction to the peers they happen to be connected to. The transaction gets relayed throughout the network and eventually miners hear about the transaction from the peers that they are connected to. Then they can add the transaction to the block they are working on if they want to.
Thanks man, sorry for my stupid questions...
No stupid questions. We aren't born understanding the Bitcoin protocol. It's something that we learn. Sometime we learn it through reading documentation or the source code itself, and sometimes we have others clarify and explain the pieces that we don't understand.
I would suggest, however, that you take some time to read about the protocol. If you ONLY learn from the things that you think to ask, then you are NEVER going to learn the things that you aren't aware that you need to ask about.
Since you are a "software developer since many years", then I STRONGLY suggest you take a look at the source code of a full node implementation. You'll get a much better understanding of exactly what it is doing.
I have problems with difficulty adjustments
. . .
I'm getting a new target, but it's too easy... I can mine with this target in less than 2s, it should be atleast 1m or so...
You are saying that it took 7 seconds to mine a block, and then after increasing the difficulty you were able to mine the blocks even faster (2 seconds)?
There are a couple of possibilities that come immediately to mind here...
1. Perhaps you are miscalculating the amount of time that your software spent actually calculating hashes? If you are including the amount of time that it takes for your software to load up into RAM and to build the block, and to output that block to you, then you are including a LOT of variable time that could be different every time you run the program. On such a small timescale those variable times have a larger influence on total time than the block hashing has. Possible solutions would be:
- Try timing how long it takes to solve 2000 blocks, and then adjust your difficulty
- Start with a MUCH lower target so that hashing is a larger percentage of the processing time
- Iterate multiple adjustments to see if it eventually starts growing appropriately as hashing becomes an ever larger percentage of processing time
2. You are not properly comparing target to hash? It is possible that you have a bug in your code that is causing it to exit your hashing loop before it has found a low enough hash value. Possible method to determine this would be:
- Print out both the target and the solution hash when your software finishes processing a block so you can compare the values yourself and see if they are correct