Topic: Are blocks like trees or lines (Read 645 times)
Thank you both, very informative
Is it really not enforced? I thought the protocol strictly enforced that the subsidy and all transaction fees must be accounted for in the coinbase transaction. I said at least 12.5 since the minimum with it being strictly enforced would be the block subsidy in the case of an empty block.
I apologize for taking this thread off-topic a bit, but since technical details of blocks were being discussed, I figured it would be good to correct mistaken statements.The maximum is strictly enforced.
The miner (or pool) that builds the block is welcome to pay themselves less if they want to, and software bugs in the past have resulted in exactly that happening. Doing so removes those bitcoins from existence. They will then never be mined, and the eventual total bitcoins existing in the blockchain is reduced.
- snip -
the first transaction is the coinbase transaction. That transaction is one that you create yourself. It is the only transaction in the block that is allowed to have a blank input and it must output at least 12.5 Bitcoin.
- snip -
the first transaction is the coinbase transaction. That transaction is one that you create yourself. It is the only transaction in the block that is allowed to have a blank input and it must output at least 12.5 Bitcoin.
- snip -
This is incorrect.
There is no minimum reward enforced by the protocol.
There is a maximum reward enforced. The sum of the outputs in the coinbase transaction must be less than or equal to the sum of the current block subsidy (currently 12.5 BTC) plus all the transaction fees of all the other transactions included in the block (the difference between the sum of the values of all the inputs and the sum of the values of all the outputs).
It doesn't make financial sense to spend money on mining and then give yourself a smaller reward than you are allowed, so nearly everyone takes the maximum allowed reward, however there have been bugs in mining software in the past that resulted in smaller than allowed block rewards.
- snip -
the first transaction is the coinbase transaction. That transaction is one that you create yourself. It is the only transaction in the block that is allowed to have a blank input and it must output at least 12.5 Bitcoin.
- snip -
the first transaction is the coinbase transaction. That transaction is one that you create yourself. It is the only transaction in the block that is allowed to have a blank input and it must output at least 12.5 Bitcoin.
- snip -
This is incorrect.
There is no minimum reward enforced by the protocol.
There is a maximum reward enforced. The sum of the outputs in the coinbase transaction must be less than or equal to the sum of the current block subsidy (currently 12.5 BTC) plus all the transaction fees of all the other transactions included in the block (the difference between the sum of the values of all the inputs and the sum of the values of all the outputs).
It doesn't make financial sense to spend money on mining and then give yourself a smaller reward than you are allowed, so nearly everyone takes the maximum allowed reward, however there have been bugs in mining software in the past that resulted in smaller than allowed block rewards.
Apologies, I just re-read it.
So basically if someone else mines it and it is equal to the line of mine I am going to carry on mining my next block with the hope that mine is accepted over there's, if there's is higher than mine then I dump my because my hashPrevBlock is incorrect anyway. Is this correct?
Almost correct. You stop mining your because the odds of your block being accepted is much lower and thus you are wasting work. The hashPrevBlock is correct since it references a valid previous block. However, if the block you received is the same height (or higher) than the one you are working on, then if you broadcast your block (after it is finished), then it is less likely that others will accept yours since they probably received the other block first. It is more effective to stop mining that block and move onto the next one.So basically if someone else mines it and it is equal to the line of mine I am going to carry on mining my next block with the hope that mine is accepted over there's, if there's is higher than mine then I dump my because my hashPrevBlock is incorrect anyway. Is this correct?
What is height determine by?
It is determined by the block with the greatest total difficulty. Each block has a field called nBits. This field puts the difficulty that that block is mined for. The highest block is the block with the greatest total difficulty. The total difficulty is the sum of that block's difficulty and the difficulties of every single block preceding it.
Apologies, I just re-read it.
So basically if someone else mines it and it is equal to the line of mine I am going to carry on mining my next block with the hope that mine is accepted over there's, if there's is higher than mine then I dump my because my hashPrevBlock is incorrect anyway. Is this correct? What is height determine by?
So basically if someone else mines it and it is equal to the line of mine I am going to carry on mining my next block with the hope that mine is accepted over there's, if there's is higher than mine then I dump my because my hashPrevBlock is incorrect anyway. Is this correct? What is height determine by?
Brilliant, thank you.
There's something I don't understand:
Sorry really confused with this part
You misread that (and quoted it wrong). You aren't broadcasting it. There's something I don't understand:
Quote
If you receive another block, you are supposed to validate it (check the proof of work and the transactions). If it is the same height as the one you just broadcast, you keep it but keep working on the block you already started. If it is a higher height (longer chain, more PoW) then you discard whatever you are working on and begin building a new block on top of the one you just received.
Quote
If it is the same height as the one you are working on you broadcast it and keep working
- If I am broadcasting that means I confirm that it is valid > If it is valid am I not now supposed to change the 'hashPrevBlock' for the new one I have just confirmed?Sorry really confused with this part
Brilliant, thank you.
There's something I don't understand:
Sorry really confused with this part
There's something I don't understand:
Quote
If you receive another block, you are supposed to validate it (check the proof of work and the transactions). If it is the same height as the one you just broadcast, you keep it but keep working on the block you already started. If it is a higher height (longer chain, more PoW) then you discard whatever you are working on and begin building a new block on top of the one you just received.
Quote
If it is the same height as the one you are working on you broadcast it and keep working
- If I am broadcasting that means I confirm that it is valid > If it is valid am I not now supposed to change the 'hashPrevBlock' for the new one I have just confirmed?Sorry really confused with this part
I always thought that blocks were like trees where one transaction creates a branch. Is it more like a line and where one fork or double spending creates a branch?
It's a line, more specifically, it's a chain since each block is chained to the one behind it.I ask this because I thought hashPrevBlock would stay the same for a transaction when trying to mine it until the transaction in the block has been mined but now I'm assuming it changes everytime someone mines a block unassociated to that transaction?
Transactions don't have a hashPrevBlock, blocks do. A block's hashPrevBlock is always the same, regardless.Also, on a side note, if I were to start mining would my machine also be 'listening' to blocks which have been mined in order to update itself and 'pass' on the work and get more work as the block it was trying to mine has already been discovered? If we say 50% of machines are needed to confirm correct nonce for your discovered block are we waiting on these 50% to agree and then you will get the reward? How does this reward process begin and end ie discovered block > sent to all machines > 50% confirm (how can my machine decide what 50% of the machines are?) > they've confirmed > the reward is assigned to my address (how does this get assigned via blockchain?)
It doesn't work like that at all. There isn't any need for any percent of the network to confirm anything. Rewards are not assigned to addresses by other people.If you are a miner, you create the block. In your block, the first transaction is the coinbase transaction. That transaction is one that you create yourself. It is the only transaction in the block that is allowed to have a blank input and it must output at least 12.5 Bitcoin. This can be split among multiple outputs and it goes to whomever you want; usually yourself.
When you create that block, you broadcast it to the network and then immediately start working on the next block. If you receive another block, you are supposed to validate it (check the proof of work and the transactions). If it is the same height as the one you just broadcast, you keep it but keep working on the block you already started. If it is a higher height (longer chain, more PoW) then you discard whatever you are working on and begin building a new block on top of the one you just received.
I always thought that blocks were like trees where one transaction creates a branch. Is it more like a line and where one fork or double spending creates a branch?
I ask this because I thought hashPrevBlock would stay the same for a transaction when trying to mine it until the transaction in the block has been mined but now I'm assuming it changes everytime someone mines a block unassociated to that transaction?
Also, on a side note, if I were to start mining would my machine also be 'listening' to blocks which have been mined in order to update itself and 'pass' on the work and get more work as the block it was trying to mine has already been discovered? If we say 50% of machines are needed to confirm correct nonce for your discovered block are we waiting on these 50% to agree and then you will get the reward? How does this reward process begin and end ie discovered block > sent to all machines > 50% confirm (how can my machine decide what 50% of the machines are?) > they've confirmed > the reward is assigned to my address (how does this get assigned via blockchain?)
I ask this because I thought hashPrevBlock would stay the same for a transaction when trying to mine it until the transaction in the block has been mined but now I'm assuming it changes everytime someone mines a block unassociated to that transaction?
Also, on a side note, if I were to start mining would my machine also be 'listening' to blocks which have been mined in order to update itself and 'pass' on the work and get more work as the block it was trying to mine has already been discovered? If we say 50% of machines are needed to confirm correct nonce for your discovered block are we waiting on these 50% to agree and then you will get the reward? How does this reward process begin and end ie discovered block > sent to all machines > 50% confirm (how can my machine decide what 50% of the machines are?) > they've confirmed > the reward is assigned to my address (how does this get assigned via blockchain?)
Jump to: