Topic: Hox many times wait to receive blocks awards??? (Read 1038 times)
Please stop posting the same question different ways. The bitcoin log does not represent your mining and those messages do not mean you have found a block. You have been told many times already and I will lock this thread.
Sorry for my english but i'm french and don't speak very well!!!!
In fact, on wiki, they explain, that the target time and actual time in debug.log must be equal.
Every two weeks, the wallet read the actual and target time of a block rewards!!!
in fact the reward's are mannaged like any other else transaction in the block which was created just before!!!
That's an american who explain me last time.
In your debug.log you must have command line like this:
Createnewblock()
Update tip: added 1 transaction in block something like this..
They explain me too, that is the reward added in block and managed like any other else transaction..
so I undersdant that i must wait like two weeks or+++?
ps: I'm not trolling, i want answers and BTC.
Sorry for double post!!! you can delete one of this if you want!!!!
I made an mistake beetwen Awards and Rewards sorry!!!
In fact, on wiki, they explain, that the target time and actual time in debug.log must be equal.
Every two weeks, the wallet read the actual and target time of a block rewards!!!
in fact the reward's are mannaged like any other else transaction in the block which was created just before!!!
That's an american who explain me last time.
In your debug.log you must have command line like this:
Createnewblock()
Update tip: added 1 transaction in block something like this..
They explain me too, that is the reward added in block and managed like any other else transaction..
so I undersdant that i must wait like two weeks or+++?
ps: I'm not trolling, i want answers and BTC.
Sorry for double post!!! you can delete one of this if you want!!!!
I made an mistake beetwen Awards and Rewards sorry!!!
IF you are not trolling, you may want to ask this on your local sub-boards.
I'm having a hard time understanding your english. so I'll just assume that you're asking about how long does it take to generate a block.
the answer is it depends on the pool's hashrate and the current dificulty. the higher it is the faster you generate a block.
I'm having a hard time understanding your english. so I'll just assume that you're asking about how long does it take to generate a block.
the answer is it depends on the pool's hashrate and the current dificulty. the higher it is the faster you generate a block.
In fact when you detect a block before long pool, you win the award block because in debug.log wallet you must having this=>
I reapeat before long pool must be written on command line of your's mining software, if it isn't you just increment block!!!!!!!!!!!!!!
On the wiki we have this:
The target is a 256-bit number (extremely large) that all Bitcoin clients share. The SHA-256 hash of a block's header must be lower than or equal to the current target for the block to be accepted by the network. The lower the target, the more difficult it is to generate a block.
It's important to realize that block generation is not a long, set problem (like doing a million hashes), but more like a lottery. Each hash basically gives you a random number between 0 and the maximum value of a 256-bit number (which is huge). If your hash is below the target, then you win. If not, you increment the nonce (completely changing the hash) and try again.
For reasons of stability and low latency in transactions, the network tries to produce one block every 10 minutes. Every 2016 blocks (which should take two weeks if this goal is kept perfectly), every Bitcoin client compares the actual time it took to generate these blocks with the two week goal and modifies the target by the percentage difference. This makes the proof-of-work problem more or less difficult. A single retarget never changes the target by more than a factor of 4 either way to prevent large changes in difficulty.
And on my debug log i've sometimes transaction delay (target time and actual time) not equal..
Believe me! i don't need to post copy screen again, i'm feed up with...
So i know that i must to wait that my actual time be equal to target time!!!
But in fact, is there equal to a month??? or +++???
How many time wait to reveive block awards in weeks or month or years delay?
if I understood, Every two weels, the bitcoin wallet read the target and actual time??,
So I think that i must wait at least two week or+++ it's depend to difficulty too!!!!
Isn't it?
Thanks!!
I reapeat before long pool must be written on command line of your's mining software, if it isn't you just increment block!!!!!!!!!!!!!!
On the wiki we have this:
The target is a 256-bit number (extremely large) that all Bitcoin clients share. The SHA-256 hash of a block's header must be lower than or equal to the current target for the block to be accepted by the network. The lower the target, the more difficult it is to generate a block.
It's important to realize that block generation is not a long, set problem (like doing a million hashes), but more like a lottery. Each hash basically gives you a random number between 0 and the maximum value of a 256-bit number (which is huge). If your hash is below the target, then you win. If not, you increment the nonce (completely changing the hash) and try again.
For reasons of stability and low latency in transactions, the network tries to produce one block every 10 minutes. Every 2016 blocks (which should take two weeks if this goal is kept perfectly), every Bitcoin client compares the actual time it took to generate these blocks with the two week goal and modifies the target by the percentage difference. This makes the proof-of-work problem more or less difficult. A single retarget never changes the target by more than a factor of 4 either way to prevent large changes in difficulty.
And on my debug log i've sometimes transaction delay (target time and actual time) not equal..
Believe me! i don't need to post copy screen again, i'm feed up with...
So i know that i must to wait that my actual time be equal to target time!!!
But in fact, is there equal to a month??? or +++???
How many time wait to reveive block awards in weeks or month or years delay?
if I understood, Every two weels, the bitcoin wallet read the target and actual time??,
So I think that i must wait at least two week or+++ it's depend to difficulty too!!!!
Isn't it?
Thanks!!
ps: I know that i went to subscrible on your forum!!
Because i'm new or your forum, i must to be a newb?
lauthing about this and it doesn't matter, because it seem's looking good mining for me...
In fact when you detect a block before long pool, you win the award block because in debug.log wallet you must having this=>
I reapeat before long pool must be written on command line of your's mining software, if it isn't you just increment block!!!!!!!!!!!!!!
On the wiki we have this:
The target is a 256-bit number (extremely large) that all Bitcoin clients share. The SHA-256 hash of a block's header must be lower than or equal to the current target for the block to be accepted by the network. The lower the target, the more difficult it is to generate a block.
It's important to realize that block generation is not a long, set problem (like doing a million hashes), but more like a lottery. Each hash basically gives you a random number between 0 and the maximum value of a 256-bit number (which is huge). If your hash is below the target, then you win. If not, you increment the nonce (completely changing the hash) and try again.
For reasons of stability and low latency in transactions, the network tries to produce one block every 10 minutes. Every 2016 blocks (which should take two weeks if this goal is kept perfectly), every Bitcoin client compares the actual time it took to generate these blocks with the two week goal and modifies the target by the percentage difference. This makes the proof-of-work problem more or less difficult. A single retarget never changes the target by more than a factor of 4 either way to prevent large changes in difficulty.
And on my debug log i've sometimes transaction delay (target time and actual time) not equal..
Believe me! i don't need to post copy screen again, i'm feed up with...
So i want to know that i must to wait that my actual time be equal to target time!!!
But in fact, is there equal to a month??? or +++???
How many time wait to reveive block awards?
Thanks!!
I reapeat before long pool must be written on command line of your's mining software, if it isn't you just increment block!!!!!!!!!!!!!!
On the wiki we have this:
The target is a 256-bit number (extremely large) that all Bitcoin clients share. The SHA-256 hash of a block's header must be lower than or equal to the current target for the block to be accepted by the network. The lower the target, the more difficult it is to generate a block.
It's important to realize that block generation is not a long, set problem (like doing a million hashes), but more like a lottery. Each hash basically gives you a random number between 0 and the maximum value of a 256-bit number (which is huge). If your hash is below the target, then you win. If not, you increment the nonce (completely changing the hash) and try again.
For reasons of stability and low latency in transactions, the network tries to produce one block every 10 minutes. Every 2016 blocks (which should take two weeks if this goal is kept perfectly), every Bitcoin client compares the actual time it took to generate these blocks with the two week goal and modifies the target by the percentage difference. This makes the proof-of-work problem more or less difficult. A single retarget never changes the target by more than a factor of 4 either way to prevent large changes in difficulty.
And on my debug log i've sometimes transaction delay (target time and actual time) not equal..
Believe me! i don't need to post copy screen again, i'm feed up with...
So i want to know that i must to wait that my actual time be equal to target time!!!
But in fact, is there equal to a month??? or +++???
How many time wait to reveive block awards?
Thanks!!
Jump to: