Topic: How does a block complete when there are lots of transactions? (Read 2035 times)
Have close to the topic question and luckily this post helped me to answer it. Thanks for good post and quite clear explanations.
February 20, 2014, 02:22:46 AM
There's a post somewhere in my 3000 posts where I describe the code when new transactions are added to the next block that is being hashed by Bitcoin. Without a quick search finding my post, essentially a new merkle tree and candidate block is created from the current "best" transactions in the memory pool every minute by Bitcoin, and that is what is hashed when mining.
(edit - found the post:)
(edit - found the post:)
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, 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 (for OP here).
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, 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;
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 (for OP here).
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.
Deepceleron's razor #17: If something is worth saying to a noob, deepceleron has probably already said it.
February 20, 2014, 02:22:33 AM
Now I hope I understand it well enough to explain it to about 120 engineers tomorrow at noon.
No offence but I am not very sure. It took me 2 months before I fully understand mining.
For example, do you know the answer for the following question: Why couldn't a mining pool participant steal the reward when he finds a valid block?
February 19, 2014, 05:46:37 PM
In the case of a tie. there is a fork and the longest blockchain is accepted.
Where "longest blockchain" actually means the blockchain with the highest total amount of "proof-of-work".
Just to clarify, since we're apparently going to get nit-picky here...
For the individual miner (pool), there is no such thing as a tie. The first valid block received is the one the miner is (supposed to) work on, regardless of whether a subsequent valid block for the same spot in the chain has more transactions or a higher difficulty (lower hash).
Just to nit pick on the nit-picking. The difficulty only changes once every 2016 blocks and it changes for all block of the same block height at the same time. A lower hash does not mean a lower difficulty (nor does it mean a higher "proof-of-work"). If I ask you to jump at least 12 inches (30.48 cm) in the air, and you end up jumping 14 inches (35.56 cm) the difficulty of the task requested of you has not changed.
What happens in the case of multiple valid blocks for the same spot is that the chain is forked
This has already been stated.
and the miners will work on whichever block they got first.
When the NEXT block is solved (next spot in chain), that chain is now longer (and has highest "proof-of-work", as Trongersoll pointed out) and everyone switches to that chain. The valid block in the other fork is orphaned (its transactions not part of the blockchain
When the NEXT block is solved (next spot in chain), that chain is now longer (and has highest "proof-of-work", as Trongersoll pointed out) and everyone switches to that chain. The valid block in the other fork is orphaned (its transactions not part of the blockchain
Unless those transactions were already also included in one of the blocks from that fork.
and the miners get nothing for their work).
February 19, 2014, 05:38:47 PM
Thanks for the replies. I think I get it.
Now I hope I understand it well enough to explain it to about 120 engineers tomorrow at noon.
Thanks again
Now I hope I understand it well enough to explain it to about 120 engineers tomorrow at noon.
Thanks again
February 19, 2014, 05:16:49 PM
In the case of a tie. there is a fork and the longest blockchain is accepted.
Where "longest blockchain" actually means the blockchain with the highest total amount of "proof-of-work".
Just to clarify, since we're apparently going to get nit-picky here...
For the individual miner (pool), there is no such thing as a tie. The first valid block received is the one the miner is (supposed to) work on, regardless of whether a subsequent valid block for the same spot in the chain has more transactions or a higher difficulty (lower hash). What happens in the case of multiple valid blocks for the same spot is that the chain is forked and the miners will work on whichever block they got first.
When the NEXT block is solved (next spot in chain), that chain is now longer (and has highest "proof-of-work", as Trongersoll pointed out) and everyone switches to that chain. The valid block in the other fork is orphaned (its transactions not part of the blockchain and the miners get nothing for their work).
February 19, 2014, 03:42:51 PM
In the case of a tie. there is a fork and the longest blockchain is accepted.
Where "longest blockchain" actually means the blockchain with the highest total amount of "proof-of-work".
February 19, 2014, 01:50:19 PM
It isn't the longest block that is accepted. It it the first block that finds an acceptable Hash that is accepted. In the case of a tie. there is a fork and the longest blockchain is accepted.
February 19, 2014, 01:24:15 PM
Miners decide which transactions they include.
Basically, there is no such thing as THE NEXT BLOCK. There is any number of possible valid blocks and miners (pool operators) decide which transactions they want to include. Whichever pool manages to solve their block and distribute it, get the rewards from solving the block (everybody else gets nothing) and their block is the next block.
Currently, the block sizes vary from 40-some kB to many hundreds of kB. In other words, some pools include a lot of transactions, some include pretty much nothing.
Basically, there is no such thing as THE NEXT BLOCK. There is any number of possible valid blocks and miners (pool operators) decide which transactions they want to include. Whichever pool manages to solve their block and distribute it, get the rewards from solving the block (everybody else gets nothing) and their block is the next block.
Currently, the block sizes vary from 40-some kB to many hundreds of kB. In other words, some pools include a lot of transactions, some include pretty much nothing.
February 19, 2014, 01:03:53 PM
I'm giving a presentation on bitcoins tomorrow and I gave a dry run this morning and I got stuck on one particular question. I have read the Wikipedia entry, I have read the https://en.bitcoin.it/wiki/Mining entry and I don't see exactly the issue that I'm asking.
If new transactions are arriving all the time, and the longest block is one that is accepted, then it seems like there's an endless treadmill of new transactions arriving while the hash is being calculated - what cuts off how many transactions are in a block? It seems like you could have so many transactions arriving that no one can ever calculate a hash?
Like I read this entry from this article http://codinginmysleep.com/bitcoin-mining-in-plain-english/
What prevents an endless flood of transactions from preventing the calculation of a block?
Thanks in advance for your patience in answering a somewhat-technical but still very basic newbie question.
If new transactions are arriving all the time, and the longest block is one that is accepted, then it seems like there's an endless treadmill of new transactions arriving while the hash is being calculated - what cuts off how many transactions are in a block? It seems like you could have so many transactions arriving that no one can ever calculate a hash?
Like I read this entry from this article http://codinginmysleep.com/bitcoin-mining-in-plain-english/
Quote
So the basic concept of Bitcoin mining is that there’s a little chunk of each block that contains meaningless random data, and Bitcoin miners take all the data in the current block, shuffle up that random chunk and calculate the hash of the whole thing. Remember that while hashes are easy to reproduce, they’re impossible to predict and they seem to function completely randomly, so the miner has no way of predicting what chunk of random data will produce what hash, he just has to keep changing that chunk until he gets the result he’s looking for. Eventually, some miner somewhere finds a chunk of random data that produces a hash that is smaller than a certain value, as determined by the difficulty, and submits this block and its accompanying hash to the Bitcoin network. Once the network confirms the solution is correct, the miner is rewarded with a number of Bitcoins.
What prevents an endless flood of transactions from preventing the calculation of a block?
Thanks in advance for your patience in answering a somewhat-technical but still very basic newbie question.
Jump to: