Thanks.
How pool's break a work to small parts? they split works on what parameter/range?
Topic: [Question] Transactions on current block (Read 829 times)
Bitcoin maintains a memory pool of all valid transactions that are waiting for a block. This contains all transactions that are valid and at least meet the minimum anti-spam fee rules. It also includes "orphan" transactions, which are not yet funded by a payment in the blockchain. These are relayed to other Bitcoin nodes when first seen.
When mining, Bitcoin assembles a sub-set of the memory pool transactions into a block (there may be some or many memory pool transactions that won't fit in the structure of the current block with the miner's rules), and keeps mining the same block data until there are new transactions and it's been over 60 seconds, if 4 billion hashes are done, if or if a new network block is announced.
Main.cpp
Only when these conditions happen is a new Merkle tree built and a new block assembled with another set of transactions (if the block is full, transactions can be bumped out of the temporary block by newer ones with higher priority or more fees). A flood of transactions won't create a CPU denial-of-service attack.
The transactions (and other block data) that would be included in a block by your Bitcoin is available for your viewing with the Bitcoin RPC command getblocktemplate.
When mining for a pool, their Bitcoin assembles blocks the same way (although they may have tweaked the rules). The only difference is pools have an additional layer of software that assigns work to specific miners and keeps track of what miners are working on, and will reject unassigned work submissions.
When mining, Bitcoin assembles a sub-set of the memory pool transactions into a block (there may be some or many memory pool transactions that won't fit in the structure of the current block with the miner's rules), and keeps mining the same block data until there are new transactions and it's been over 60 seconds, if 4 billion hashes are done, if or if a new network block is announced.
Main.cpp
Code:
// Check for stop or if block needs to be rebuilt
boost::this_thread::interruption_point();
if (vNodes.empty())
break;
if (nBlockNonce >= 0xffff0000)
break;
if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)
break;
if (pindexPrev != pindexBest)
break;
boost::this_thread::interruption_point();
if (vNodes.empty())
break;
if (nBlockNonce >= 0xffff0000)
break;
if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)
break;
if (pindexPrev != pindexBest)
break;
Only when these conditions happen is a new Merkle tree built and a new block assembled with another set of transactions (if the block is full, transactions can be bumped out of the temporary block by newer ones with higher priority or more fees). A flood of transactions won't create a CPU denial-of-service attack.
The transactions (and other block data) that would be included in a block by your Bitcoin is available for your viewing with the Bitcoin RPC command getblocktemplate.
When mining for a pool, their Bitcoin assembles blocks the same way (although they may have tweaked the rules). The only difference is pools have an additional layer of software that assigns work to specific miners and keeps track of what miners are working on, and will reject unassigned work submissions.
As i read in bitcoin wiki, when a new transaction is created from a users, it is broadcasted to all nodes in network.
So i am confused about a problem, Each moment tons of miner's are working on current black number. each block has it's own merkle tree root and transactions that miner's trying to find it's proper hash.
problem is, when all miners are working on current block, and simultaneously a user from other side of world, broadcast his new transaction, all the miners should include this transaction into current block and start try hashing again???
or i am missing something?
So i am confused about a problem, Each moment tons of miner's are working on current black number. each block has it's own merkle tree root and transactions that miner's trying to find it's proper hash.
problem is, when all miners are working on current block, and simultaneously a user from other side of world, broadcast his new transaction, all the miners should include this transaction into current block and start try hashing again???
or i am missing something?
Jump to: