Indeed. When the number of votes is tied you need a way to break ties (not just in symmetric graphs). Using the blocks’ hash ought to work, but I prefer to use the ordering of the hash links in future blocks to do so. For example, if block x appears earlier than y in a DFS traversal break ties in its favor.
Future blocks will later amplify they tie breaking to a strict majority.
It is true that this is less than optimal, but this is not the only reason to have a block chain. The conflict here only occurs for identical (or replacement) transactions that appeared in parallel blocks (i.e., in blocks mined within seconds from each other — a minority of the transactions), and only if the network is under attack by an attacker…
Thanks for your reply.
A comment about your main point here:
Your ChkRobustAccept is probabilistic. Thus the accepted set is never 100% final, only (hopefully but there are exceptions if your chain is not the dominant one in the world) asymptotic.
Thus the mining nodes can’t…
Dear Shelby, seems like you have an “axe to grind” with general PoW chains. You object to some things we did not claim, and misunderstand the things we did. We’d appreciate more constructive criticism.
I didn’t dig into the consistency proofs which afaik are dealing with the pairwise…
That’s not how transactions are built.
Besides, seriously? there is no difference between taking the fee from the buyer and taking the fee from the seller. These are equivalent up to a change in the amount being transferred.
Here’s a hint as to how we do it: as you compute the votes of blocks towards the genesis, the votes of each new block depend on the vote of blocks in their future. At some point, the vote becomes sufficiently biased towards one winner, that you can deduce that all other voters will simply vote for the same winner.
In fact, this happens REALLY early on.