Bitcoin Forum
August 18, 2018, 02:30:38 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Could one say there are at once as many chains as there are miners ?  (Read 82 times)
echbit18
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
April 16, 2018, 03:36:56 PM
 #1

During the proof of work process, a miner receive a block to mine.

He mines it, whether the miner is rewarded or not, this block is added to his own chain.
So at once, his has a chain which is different from the main chain.
At this time could we say there are as many btc chains as there are miners ?

Next, is my understanding correct ?
The miner looses against miners, the block becomes orphan, and the miner's chain reverts back to the main chain (somehow) and he waits for the next block to be mined.
1534602638
Hero Member
*
Offline Offline

Posts: 1534602638

View Profile Personal Message (Offline)

Ignore
1534602638
Reply with quote  #2

1534602638
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
ranochigo
Legendary
*
Offline Offline

Activity: 1526
Merit: 1078


View Profile WWW
April 16, 2018, 03:48:48 PM
Merited by suchmoon (1)
 #2

No. During the mining process, the miner assembles a set of transactions and other data to be put into the block header. Using SHA256, the block header is hashed twice and if and only if the hash meets the target, the miner will broadcast the block to the network.

The miner will not broadcast the block if there is a block there has been broadcasted before his at the same height. If he does, every node in the network will simply reject it as there is a chain with a longer proof of work. The miner can only be rewarded if his block is valid and is recognised as such by the network. There is simply no reason for anyone to broadcast a block that is below the current block height if they won't get rewarded for it.
The miner looses against miners, the block becomes orphan, and the miner's chain reverts back to the main chain (somehow) and he waits for the next block to be mined.
No. While the miners are technically competing against each other, they are still somewhat working together to build the chain. If the miner has less than majority of the hashrate, it is not profitable for him to have a competing chain to the rest of the network since he will lose with the others holding more hashrate than him and thus possibly having a longer chain.

Xynerise
Sr. Member
****
Offline Offline

Activity: 266
Merit: 274

39twH4PSYgDSzU7sLnRoDfthR6gWYrrPoD


View Profile
April 16, 2018, 04:00:13 PM
Merited by ETFbitcoin (1)
 #3

During the proof of work process, a miner receive a block to mine.
He doesn't "receive a block to mine" , he crafts a candidate block with a Coinbase transaction and with transactions aggregated from the mempool.

Quote
He mines it, whether the miner is rewarded or not, this block is added to his own chain.
This is false.
Miners do not have their own separate blockchain from the rest of the network.
Also, the miner is rewarded iff his block is valid according to the consensus rules; he finds a nonce when hashed with the Merkle root, timestamp, etc, gives a block header hash lower than the target hash; no other miner releases a completing block (valid block with the same block height).
When all the conditions are satisfied, then the Coinbase transaction he crafted (including the block reward) becomes valid -- and can only be spent after 100 blocks.
Quote
So at once, his has a chain which is different from the main chain.
He doesn't have a chain, just a block which will either be added to the main chain or not depending on if he follows consensus rules.
Quote
At this time could we say there are as many btc chains as there are miners ?
Any block that hasn't been added to the blockchain IS NOT part of the block chain; it's just a candidate block.
So they are many CANDIDATE BLOCKS but just one blockchain.
Quote
Next, is my understanding correct ?
No, not really.
Quote
The miner looses against miners, the block becomes orphan,

His block only gets orphaned if after he published his valid block, another miner publishes a block with the same block height but higher cumulative difficulty, if he doesn't find a block in the first place then he's not part of the blockchain and so his block can't get orphaned.

Quote
and the miner's chain reverts back to the main chain (somehow) and he waits for the next block to be mined.
Miners mine on the TIP of the main chain.
Miners craft candidate blocks on top of a block that's on the blockchain.
Until a miner finds a valid block and publishes it and other miners  mine on top of it as the TIP of the next block, his candidate block is NOT on the blockchain.

For better understanding of the subject read Andreas' chapter on mining in his book Mastering Bitcoin.
angry_runner
Jr. Member
*
Offline Offline

Activity: 112
Merit: 6


View Profile WWW
April 16, 2018, 04:14:01 PM
 #4

no. only one chain and miners add blocks to that chain.
every miners have own copy of the whole chain.
Jet Cash
Legendary
*
Offline Offline

Activity: 980
Merit: 1130


VOM member


View Profile WWW
April 16, 2018, 05:57:48 PM
 #5


His block only gets orphaned if after he published his valid block, another miner publishes a block with the same block height but higher cumulative difficulty,

I didn't realise that. So what happens if a 3rd miner finds a block almost instantly, and adds it to the first miner's block, but it happens just after the 2nd miner added his block in an attempt to replace the 1st block?

Xynerise
Sr. Member
****
Offline Offline

Activity: 266
Merit: 274

39twH4PSYgDSzU7sLnRoDfthR6gWYrrPoD


View Profile
April 16, 2018, 06:49:34 PM
Merited by vapourminer (1), Jet Cash (1), HCP (1)
 #6


His block only gets orphaned if after he published his valid block, another miner publishes a block with the same block height but higher cumulative difficulty,

I didn't realise that. So what happens if a 3rd miner finds a block almost instantly, and adds it to the first miner's block, but it happens just after the 2nd miner added his block in an attempt to replace the 1st block?
Competing blocks are not resolved immediately; other miners have to vote with their hashpower ON the block that they consider valid.
Also, blocks have to reference the previous block header hash to build upon them.
There are 3 miners: A, B & C.
Miner A & B found a valid block almost simultaneously and "published" their blocks
Right now there's a temporary fork in the blockchain.
Miner C then found and  published a block building on miner A's block.
The blockchain including miner A's block is the longest chain with the highest cumulative difficulty because it has the difficulty of the previous blockchain + that of miner C's block .
If other miners "vote" by building their block tip on miner C's block, then it becomes the valid block chain and the block by miner B gets orphaned.

Let's use numbers.
Let's say The current block height the miners are building on is block 100 with block header hash 000....100x
Then miner A finds a valid block that builds upon this, which should be block 101, with blockheader hash 000...101a
However miner B also finds a valid block also building on block height 100 with hash 00..100x, which is also a competing Candidate for block height 101.
Right now there are 2 block 101's -- that of miner A and that of miner B, and there's a temporary bifurcation in the blockchain. full nodes will store both blocks till it is resolved.
Then the miners will vote with their hashpower on the block they consider to be valid.
If miner C builds on miner A's block 101 with hash 000...101a and finds a valid block, 102, then the blockchain of miner A's block is longer, and it also has the highest cumulative proof of work (measured in the difficulty of the block), so his block is "more valid" than B's and if other miners agree with miner C and extend the blockchain by building on miner A's block, then miner B's block will get orphaned by the nodes.

In a rare scenario (eg the 0.8 bug) where after miners up to block 104  Are mining on the block found by A, and other miners decide to mine on the block found by B instead and overtake the length of the chain of A with higher hashpower, then the blocks found from 101 - 104 built on the block found by A will be orphaned and the blockchain will reorganise to the new chain with the highest cumulative proof of work.
Therefore a transaction mined in miner A's block 101 that now has 3 confirmations (3 blocks built on top), will be orphaned and invalid if the transaction was not included in any of the subsequent blocks found.
This is why you should wait for 6 confirmations before you consider a transaction valid even though block reorgs usually do not have a depth of more than 2 blocks.
It's also why the Coinbase maturity time is long (100 blocks)

The important factor in determining the valid chain is the one with the MOST proof of work, not the longest chain alone  or else it would be trivial to fork bitcoin, reduce the difficulty and  mine several blocks ahead of the main chain, forcing a block reorg of the "true" chain to my fake chain.
JohnB31
Jr. Member
*
Offline Offline

Activity: 60
Merit: 1


View Profile
April 16, 2018, 10:36:31 PM
 #7

As stated before miners do not get a block to mine, they compose it from data like pending transactions, previous block info and an (unknown) number they need to guess.
As some info of the previous block is included in the next block a block can only be mined if the previous block is mined. Finding the next block involves not only hash power but also some luck. Not all miners find (and publish) a next block the same time.
In theory you can mine a several of blocks and wait to publish them after you mined e.g. 100 blocks. However in that case is is not sufficient to mine one block faster than all the other miners; you need to mine all this 100 blocks faster than all other miners together. This would be a race very difficult to win (also due to the luck involved), and if you lose or are not significant ahead of all other miners after this 100 blocks you will not receive any reward.
DannyHamilton
Legendary
*
Offline Offline

Activity: 2198
Merit: 1371



View Profile
May 09, 2018, 04:36:05 PM
Merited by DooMAD (2)
 #8

The conversation in this thread has been pretty good, but I'm going to try and clear up some things that might be confusing to someone that is trying to learn about this topic...

Receiving vs. Building the block:
During the mining process, the miner assembles a set of transactions and other data to be put into the block header.
He doesn't "receive a block to mine" , he crafts a candidate block with a Coinbase transaction and with transactions aggregated from the mempool.
As stated before miners do not get a block to mine, they compose it from data like pending transactions, previous block info and an (unknown) number they need to guess.

What was originally called "mining" involves a process that was divided into two parts when mining pools were created.  Part 1 is "building the block" and part 2 is "hashing the block".  If you are solo-mining, then you are BOTH building the block (as described by ranochigo, Xynerise, and JohnB31 above) AND hashing the block.  If you are mining in a mining pool, then the pool is handling everything except the hashing.  The pool maintains the blockchain, mempool, and UTXO, communicates with the bitcoin network, and builds the blocks. The pool participants generally receive a partially hashed block header (often called a midstate) from the pool and then handle hashing that midstate with the various nonce values.  The pool participant notifies the pool whenever it has succeeded at a difficulty that is lower than the current bitcoin difficulty.  That is how the pool can tell if you are actually hashing even if you don't succeed at solving a real block.  Sometimes that notification also qualifies for the actual bitcoin difficulty.  In that case, the pool handles broadcasting the block to the rest of the network.


Competing blocks:
other miners have to vote with their hashpower ON the block that they consider valid.

This makes it sound like there is a separate "voting" process where the block with the most "votes" wins.

In actually, every solo-miner or pool just assumes that the block which they received first is the "real" block, and attempts to mine a new block on top of it.  If they complete a block, then the chain they are building becomes the longest and the block they mined on top of "wins".  If, before they can complete a block, they receive a valid block from a peer that lists as its "previous block" that block that they were attempting to mine on top of, then that becomes the longest chain and the block they were attempting to mine on top of "wins". If, before they can complete a block, they receive a valid block from a peer that lists as its "previous block" the block they are NOT attempting to mine on top of, then that other chain becomes the longest, they mark the block they had been trying to build on top of as not part of the blockchain and they build a new block on top of the block they just received.

So, there isn't really a "vote".  There is just miners assuming that the first block they received is "correct" until they receive a longer chain.

Miner C then found and  published a block building on miner A's block.
The blockchain including miner A's block is the longest chain with the highest cumulative difficulty because it has the difficulty of the previous blockchain + that of miner C's block .
If other miners "vote" by building their block tip on miner C's block, then it becomes the valid block chain and the block by miner B gets orphaned.

Actually, the "vote" was happening while miner C was building his block.  He was the "voter" that won the vote by extending one of the two chains. When miner C broadcast his completed block, the vote was over, and miner A's block "won".  All miners will switch over to mining on top of miner C's block.

Let's use numbers.
Let's say The current block height the miners are building on is block 100 with block header hash 000....100x
Then miner A finds a valid block that builds upon this, which should be block 101, with blockheader hash 000...101a
However miner B also finds a valid block also building on block height 100 with hash 00..101x, which is also a competing Candidate for block height 101.
Right now there are 2 block 101's -- that of miner A and that of miner B, and there's a temporary bifurcation in the blockchain. full nodes will store both blocks till it is resolved

Just to avoid confusion, be aware there is no need for the block height to be part of the hash. It would have been just as valid to say that block 100 hash block header hash of 000...37ed, and that the two blocks at height 101 have hashes of 000...a3f2 and 000...2c49.  Using the block height in the hash value in the example just makes it easier to visually keep track of which block is being discussed.

Then the miners will vote with their hashpower on the block they consider to be valid.

Both are "valid", the question is which is to be added to the blockchain.  Saying that they "vote" is just a slightly confusing way of saying, that they will hash a new block on top of the block that they received first, and someone will eventually finish their new block first.

so his block is "more valid" than B's

It isn't any more or less "valid".  It is just currently part of the longest chain (greatest proof-of-work) and therefore accepted as the current blockchain.

if other miners agree with miner C and extend the blockchain by building on miner A's block, then miner B's block will get orphaned by the nodes.

We can assume that the blocks from A and C are actually valid blocks (otherwise they would have been ignored by everyone in the first place and there wouldn't be a "competing block" situation. Therefore, the only reason other miners would not "agree" would be if some miner D happened to complete and broadcast a block built on top of the miner B's block at nearly the same time as miner C was broadcasting his block. (in which case the competing chains would be 2 blocks long and the process would continue in the same way.

In a rare scenario (eg the 0.8 bug) where after miners up to block 104  Are mining on the block found by A, and other miners decide to mine on the block found by B instead and overtake the length of the chain of A with higher hashpower, then the blocks found from 101 - 104 built on the block found by A will be orphaned and the blockchain will reorganise to the new chain with the highest cumulative proof of work.

Correct.  At any time, if enough hash power all agrees to ignore the longest chain and build on some older block in the chain, then it is possible that they can overtake the current chain in length (total proof-of-work) and cause a re-organization to the blocks in their chain.

Therefore a transaction mined in miner A's block 101 that now has 3 confirmations (3 blocks built on top), will be orphaned and invalid if the transaction was not included in any of the subsequent blocks found.

This is not true.  The BLOCKS will become orphaned.  But the transaction will be neither orphaned NOR invalid.  It will simply return to being UNCONFIRMED.  It will only become invalid if some OTHER transaction in the new chain spends the same inputs.

This is why you should wait for 6 confirmations before you consider a transaction valid even though block reorgs usually do not have a depth of more than 2 blocks.

There is nothing magic about the number 6.  You could wait 5, or you could wait 7, or any other number that satisfies your own personal risk tolerance.  It is possible to have 10 (or more) confirmations, and then for a re-org to wipe out all of those confirmations.  It is also possible to have 1 confirmation, and then discover after a re-org that the transaction suddenly has more than 8 confirmations.

Re-orgs that are more than 2 blocks are extremely rare.  If one should happen, then it is very likely that the transaction is already confirmed in the new chain.  Even if it is not already confirmed in the new chain, it is very likely that the transaction is still valid and simply waiting to be confirmed in the new chain.

The important factor in determining the valid chain is the one with the MOST proof of work, not the longest chain alone or else it would be trivial to fork bitcoin, reduce the difficulty and mine several blocks ahead of the main chain, forcing a block reorg of the "true" chain to my fake chain.

Under normal circumstances, the chain with the most blocks is always also the chain with the most proof-of-work.  This is because difficulty is adjusted by everyone independently in exactly the same way.  Simply adjusting your own difficulty would be insufficient.  You'd need to get EVERYONE else to adjust their difficulty as well if you wanted to perform the attack that you are claiming is "trivial" (otherwise they'll all see your block as invalid).  There are 2 ways to get everyone else to change their difficulty. One is to somehow convince everyone into running a modified version of the protocol (this is what Bitcoin Cash has done to separate their difficulty from the Bitcoin Core difficulty). The other is to go back farther than at least one difficulty adjustment and mine blocks with different timestamps.  In this way you can "trick" the difficulty adjustment calculation into calculating an incorrect difficulty.  As you pointed out, even if you had enough hash power to pull off such an attack and catch up with the current network in number of blocks, you'd fail to force a re-org because your chain would have less total proof-of-work.  If you have enough hash power to get more total proof-of-work, then there is no need to mess around with difficulty since you'll have enough hash power to have more total blocks.



Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!