What if one block contains many more transactions than the other? Wouldn't it be better to pick the block with more transactions? Also, why is a tie ultimately broken randomly, rather than a deterministic way that helps the network?
4
-
If two blockchains are of equal height, clients will prefer the one they received first.– Nick ODellCommented Nov 2, 2016 at 20:56
-
Also, minor nitpick: nodes use chain work, not chain height. For small forks where the difficulty is the same, the distinction usually doesn't matter, though.– Nick ODellCommented Nov 2, 2016 at 20:57
-
Thanks, but that was my real question- why pick the one they received first, or by random? Let's say one block has no transactions but was received first, and another with the same work has many transactions was received later. Why not pick the latter?– kanuCommented Nov 2, 2016 at 23:46
-
Ah, that sounds like it's not a duplicate. My apologies.– Nick ODellCommented Nov 3, 2016 at 3:41
Add a comment
|
3 Answers
Consensus rule dictates that chain work is measured based on the production of a solution which satisfy the difficulty set by consensus. So as long as a produced block satisfy said rule, said produced block would be accepted.
It is technically infeasible to choose base on blocks with more transaction for a variety of reason. First, bitcoin lacks strong consistency (i.e. its impossible for nodes to share a consistent state for its mempools), if block acceptance requires that a block based on the highest number of transaction is accepted, then the blockchain will most likely be orphaned many times as miners compete to produce competing block tips and nodes would discard block tips literally each time a new block with more transactions is received. This results in more partitioning in the network, which leads to a poorer security as less work is focussed on any particular branch of the chain.
-
Thanks! Perhaps I'm nitpicking, but it seems to me that this explains the first two rules referenced here: bitcoin.stackexchange.com/questions/37273/… . Do these same arguments hold if we replace rule #3 to "most transactions", from "block with larger pointer address"?– kanuCommented Nov 4, 2016 at 3:57
-
No. The 3rd rules assertion on randomness would be violated. Pointer addresses are random. Blocks that arrive later would tend to contain more transactions, hence will not satisfy randomness.– rnyCommented Nov 4, 2016 at 4:51
-
Blocks that arrive later would get filtered out by th3 second rule, correct? I don't see the reason to make rule #3 random. It wouldn't cause miners to compete on transactions, as we're accepting earlier blocks before applying rule #3– kanuCommented Nov 4, 2016 at 20:22
-
Yes you are right, my apologies. However, the main point here is that there is really fundamentally no difference in terms of work done between a block that contains more transactions and a block that contains no transactions. It is at a miner's discretion to elect whether or not she'd like to include transactions. Miners are simply incentivised to include transactions so that they may reap transaction fees. Besides, random selection is still better, because if you had to compare, you'd have to process both blocks and that takes up valuable time.– rnyCommented Nov 4, 2016 at 23:22
-
It definitely makes sense from the miner's incentive perspective- including transactions is completely her discretion. However, is it better for Bitcoin as a system to change rule #3 (perhaps negligibly so, but still better)? Regarding your point about processing time, won't both these blocks already be validated for correctness by the full node prior to adding them to the blockchain? A simple count shouldn't add much overhead.– kanuCommented Nov 5, 2016 at 7:17
It makes for a stabler system if we pick the first that we receive.
The whole point of Bitcoin's blockchain is to determine a fixed order for the transactions. Two blocks being discovered at the same height is an unfortunate incident that cannot be circumvented due to the probabilistic nature of mining. It is not something that we want to occur: Two competing blocks defer the certainty of the block order to a later time but we want it to generally become stable as soon as possible.
Thus, the first block that is seen in order re-establish consensus as quickly as possible and to incentivize miners to immediately switch to mining on the successor block instead of trying to oust already existing ordering.
-
It's incorrect that the system becomes stable by if the protocol is to break ties by the first block received. As I've explained in my answer, this rule could be gamed by a selfish miner.– kanuCommented Nov 7, 2016 at 7:26
-
As I explained on your answer, I don't think selfish mining is a rational attack anymore.– Murch ♦Commented Nov 7, 2016 at 9:51
The current protocol rules for breaking ties is explained here. Breaking ties by number/ value of transactions is not only infeasible as other answers here explain, but is also easily gamed. An attacker could simply move his own coins around to have the most number of transactions. Breaking ties based on time received is better, and the third rule is almost never used.
However, here is research that shows breaking ties by time received does not make for a stabler system. This paper on selfish mining explains the idea. To summarize the intuition here:
- An attacker mining pool may choose to not immediately publish a block it mined, but instead intentionally fork the blockchain. The pool would continue mining on its private blockchain as long it has the lead.
- When the public blockchain approaches the length of the pool's private blockchain, the pool publishes all its private blocks.
- The effect of this strategy is that honest nodes waste hashes on blocks that will never be a part of the final blockchain, while the pool's revenues are disproportionately greater than its hash power.
The paper also shows that even if conditions are extremely unfavorable to the selfish pool, selfish mining would be advantageous to the pool as long it has more than 1/3rd of the total network hash power.
Rule #2 fails here because the selfish pool may set up lots of virtual (dummy) miners whose sole purpose is to peer with other nodes, stop the propagation of honest miners' blocks and instead propagate the selfish pool's blocks when it chooses to publish its private blocks as explained above.
The paper instead proposes that ties should be broken randomly, which would put the selfish pool at a disadvantage (virtual miners and being better connected to the Bitcoin network will not help the selfish pool here).
-
Since selfish mining requires 1/3 of the hashing power, it's not "easily gamed". Besides with compressed block relay such as FIBRE and Compact Blocks, it would seem to me that withholding blocks will almost exclusively make the attacker the only miner on his chain. That would make selfish mining a losing strategy, though. I've asked a follow-up question here.– Murch ♦Commented Nov 7, 2016 at 9:48
-
I referred to breaking ties by number of transactions as easily gamed, not selfish mining. With selfish mining, haven't pools reached 1/3rd of the hash power many times in the past? As I understand it, 1/3rd of hash power is the threshold if every miner is connected to the same relay network. If miners don't use relay networks at all, the threshold is arbitrarily small.– kanuCommented Nov 7, 2016 at 13:34
-
Also, I think you're only considering a private chain with a single block lead over the public chain. If the lead is two or more blocks, the relay network would not help when the pool chooses to publish its private chain. So I'd say the chances of a successful attack have decreased with relay networks but not vanished.– kanuCommented Nov 7, 2016 at 13:42
-
Ah sorry, I mixed the two. By number of transactions is easily gamed indeed. While mining pools have reached 33% of the hash rate before, I am not aware that selfish mining has occurred. And to reach a two block lead, the miner first has to decide to withhold a block when he has a one block lead.– Murch ♦Commented Nov 7, 2016 at 14:54
-
Selfish mining would be very hard to detect, as mining is probabilistic. I'm not aware of any mechanisms in place to detect it, or even if one can definitely prove that selfish mining has taken place. For your second question, the mechanics of profiting by withholding the first block in the hope for a second are explained in section 4.2 and 4.4 of the paper I've linked above.– kanuCommented Nov 7, 2016 at 15:08