Some clarification
The purpose of mining is probably a little confusing at first. I will keep the Bitcoin blockchain as an example throu...
For further actions, you may consider blocking this person and/or reporting abuse
It's an ingenious system when you think about it! But let me ask you a couple of dumb questions I couldn't figure out from the article;
Thanks again for this great series, Damien!
This is one of the problem with this Proof of Work mechanism. It has to consume a lot of electricity to solve the problem. If you don't win a block's race, the energy used during those 10 minutes you tried to solve the problem is wasted. This is one of the reasons why the blockchain mechanism doesn't scale so well.
I believe you can't compete as an individual today against mining farms. I know you can 'rent' some mining powers. Like, you pay 20 000 € to generate 0.00000001 BTC each second. As far as I know, you need to have a powerful installation to make a profit from this kind of activity.
I believe you are confusing the Coinbase plateform and the coinbase transaction. Yes, Coinbase is a plateform that allows you to buy and sell crypto currencies. You're right, it does look like a central bank now, because so much transactions go through plateforms such as this, which kind of defy the purpose of a decentralized currency.
The coinbase transaction is just a transaction that the miner includes in the block he is mining. The miner indicates that he is paying himself. In the article, our miner Joe said to the network that he calculated his reward ( 17 or so BTC ) and gave his wallet's address. When the block is validated, the miner receives the reward in its wallet.
It is called a coinbase transaction, but it has nothing to do with the Coinbase plateform.
Thank you for the kind words :)
Another basic question :-) What is the mechanism for resolving the winner if there are two valid blocks submitted at the same time by two miners that include overlapping but non-identical set of transactions? Is the block timestamp used to choose the winner? If so, does it create an incentive to use older timestamps?
I believe, and I may be wrong about this, that the block who gets the most confirmations first wins. I think there are a number of confirmations to get to make sure that the block has been propagated and validated.
Thanks Damien!
Isn't the longest sub-block chain wins? Just making sure!
I believe it depends on what blockchain we are talking about. For Bitcoin, the block that receives the needed confirmations is added to the blockchain. Because it takes 10 minutes to mine a block, there are no conflicts between different blockchains states.
In Ethereum however, blocks are mined a lot faster, so there can be some conflicts in this regard. I don't know much about it, but it is called the GHOST protocol ( Greedy Heaviest Observed Subtree). This is basically what you said in your comment. The longest sub-block chain wins and becomes the truth.
It all depends how long it takes to mine a block. If it's low, you will need a system to resolve conflicts like Ethereum does.
I've been loving your recent series of articles on the blockchain / blocks / mining. I had a few questions I was hoping you might be able to flush out:
I understand that in your example the difficulty was
1,931,136,454,487.72and that the valid hash was00000000000000000020c60222099aaebc6e7795784f74628ec640b223d3d339(18 leading zeros). I have two questions.If I understand correctly, all miners are using basically the same information in attempting to generate a valid hash (previous block hash, merkle tree root, target, timestamp, and version.) The only thing that "changes" miner-to-miner is the nonce. Is that right?
Maybe I'm misunderstanding, but it seems like a miner would benefit from trying random nonces in order to take a contrarian approach that potentially rewards randomness > sheer computing power.
Thanks again for any explanation you can provide. I've really found these articles extremely helpful.
1) My explanation wasn't clear at all on this point. Let me try again.
First, the target. I'll keep the same block example. In the left column, you have a bits field, with the value 402690497. This is the target bits. This number expresses the Proof-of-Work target as a coefficient/exponent format.
If we convert this number in hexadecimal, we get this: 0x180091C1.
The first two hexadecimals digits ( 18 ) are the exponent, the next six ( 0091C1 ) are the coefficient. Here is the formula used to calculate the target from this:
So by using the hexadecimal value above, we can calculate the target:
Which in decimal is =>
Back to hexadecimal (and a 64 length string) is =>
This represents the higher limit the hash must have. If the hash is lower than this target, it is valid ( here => 18 leading zeros ).
As for the difficulty, we divide the highest difficulty possible by the target found:
00000000FFFF00000000000000000000 /
00000000000000000091C100000013DE
= 1C1A0B3CF57
Which in decimals => 1,931,136,454,487
This means that compared to the first block every mined ( where the difficulty was 1 ), this block was 1.9 trillion times more difficult to solve. I may have skipped the decimals in this, but I hope you get the idea.
2) Well, I suppose the Bitcoin core developers are responsible for this. You can find the code used for the calculation here. They take the last 14 days worth of blocks and adjust the difficulty based on their findings.
3) Well, not every miner is using the same informations. I may not have explained this very well. Once a block is mined, everyone has access to the same informations and can make sure that the data is valid.
But, they won't be mining the block using the same informations. First, the merkle root will be different for everyone. The first transaction in the block ( coinbase transaction) sends bitcoins to the miner personal wallet. Each wallet address will be different, therefore the merkle root will be different too. It is also very unlikely that they will use the same timestamp for the block. So Joe finds the proper nonce at 2469953656 with its data, but other miners may not have a valid hash with this nonce because their timestamp and/or their merkle root was different.
As for the randomness of the nonces, I want to say you are right. Although I'm not quite sure how to prove it. Mining is absolutely a lottery.
If we have 2 dices, and the target is 2 ( the lowest possible ), we have only one throw possible to reach the target ( 1 on each dice ). This would mean that 1 throw out of 36 possible solves the problem, which is 2%. So, if I manage to hit the target with my dices, it doesn't mean I've thrown the dices 36 times, but the probability should be enough to prove that I've put the effort.
I'm not sure if that last paragraph has a lot to do with what you mean :D. I was just freelancing.
Sorry for the long answer. Let me know if anything isn't clear enough.
1) Amazing. This sent me on another rabbit hole to learn more about hexadecimals but was very educational.
3) Okay, I had gotten a bit confused about how the list of transactions was generated in a miner's candidate block. I now understand that they're drawn from the transaction pool and added to the candidate block at the miner's discretion. The specific transactions drawn, the order they're in, and the initial coinbase transaction will ensure the merkle tree is different for everyone. Additionally, as you point out, the timestamp would also be different.
The concept of fees and reward is really interesting. This is a block with zero transactions where the miner simply went after the reward.
I've held a fascination about blockchains for a while, but have found it really un-approachable and confusing. Your articles and explanations have been awesome. Thanks for the reply to my questions!
Happy to help :) These questions force me to learn on a more deeper level. Always welcomed.
Hi Damien,
Thanks for the information.
Can you help me understand few basic questions:
1) If a block is verified, does it mean that the transactions in it are also verified? If yes, how does it make the system record authentic transactions (not exactly from a bitcoin perspective) ? Eg If a block has 20 pending transactions out of which 10 are authentic, is there a way to decline them?
2) What exactly is validation? Does every node (not every mining node) validate the block/transaction for it to be logged in a block? If yes, what happens if all the concerned parties do not authenticate- does this not increase the time in approving transactions?
Hi Damien, Thanks for the amazing articles. I just started to learn blockchain, you make the blockchain concept so clear to me. I still have a few dumb questions here. All the questions are based on Bitcoin Blockchain.
How to calculate the transaction fees? And where is this fee from? Are they just like bitcoins, which are generated from nothing, since there is no input for it? You mentioned after 2140, there will no new bitcoins generating, but the transaction fees will still be generated?
For each candidate blocks, do they use the same set of transactions in the transaction pool except the coinbase transaction to generate the merkle tree? If not, do they use the same number of transactions, or they use different number of transactions? What is the rule to choose the transactions from the transaction pool to be included in the candidate block?
At the end of the article, you said a valid block should include "All transactions within the blocks are valid ( also have a checklist on their own )". As I understand, the transactions in the transaction pool are not confirmed. How to check the transactions within the blocks are valid? What is the definition of the valid transaction? What does the checklist mean?
A little bit more, I have read the original paper, it mentioned simplified payment verification (SPV). To verify a transaction, we use the merkle tree, bloom filter and the method you mention in the article what is in the block, is this right? However, what if a transaction is still in the transaction pool, not in the block yet? Do we think it is not verified?
I am confused whether there are intermediate transaction hashes in the block. In the previous article you mentioned it in the Q&A, but not very clear to me? So if we have transactions 1,2,3,4. Do we have Hash_1, Hash_2, Hash_3,Hash_4, Hash_12, Hash_34 (where Hash_1 is the hash value of transaction 1)? In this case, Hash_1234 is the merkel tree root, right?
I think I have so many dumb questions. If you could help me, I will very much appreciate it.
I thought maybe I could help you,