A Deterministic Tiebreaker for Bitcoin Block Selection: Enhancing Fairness and Convergence

#1

A Deterministic Tiebreaker for Bitcoin Block Selection: Enhancing Fairness and Convergence

Abstract

Bitcoin’s current first-seen rule for resolving competing blocks of equal length favors miners with superior network propagation, amplifying the risks of selfish mining and prolonging accidental chain forks.
We propose a simple, backwards-compatible change: when two blocks compete at the same height, miners compute a deterministic tiebreaker using the hash of their concatenated block hashes, H(A || B), and select the winner based on a fixed threshold.
This approach ensures a fair, latency-independent resolution, reduces fork duration, and maintains resistance to selfish mining without altering miner incentives or requiring a hard fork.

3 Likes
#2

While not deterministic, the current implementation in BCHN is not first seen, but favors blocks that have a block header timestamp that most closely matches the time the node received the block

(see line ~4000 in validation.cpp)

This was implemented to mitigate “selfish mining attack”
https://arxiv.org/pdf/1311.0243v1

1 Like
#3

On second look I don’t see any code that actually does the switch. It seems it was never completed, just added logging

1 Like
#4

Nice, but that still favors better-connected pools.

My proposal would reduce the advantage pools with better propagation would have over others to just the few seconds during which network could add +1 block and lock it in. If that doesn’t happen then uppon announcement of some late block B, it would have 50:50 fighting chance.

3 Likes
#5

Your idea seems super interesting and promising (“deterministic”) at first glance.

I will deep-read it 4 times to properly understand it and comment on later.

Thanks for the work! :+1:

2 Likes
#6

Am I a mathematical idiot, or isn’t half of 2^256 actually 2^255, not 2^128?

Edit: ie you’re essentially coinflipping the first bit in a 256 bit string as either 1 or 0.

Edit 2: Other than that, my first instinct is this is an excellent idea. Simple & effective.

1 Like
#7

Lol yeah, brain fart, I’ll add the fix

1 Like
#8

Why not just take the lower of the two hashes (if interpreted as a 256-bit integer)? Surely that’s always deterministic and has nothing to do with bandwidth/latency.

EDIT:

Also bonus: Technically picking the lower hash is fairer since the lower-hash miner has put in “more PoW” (even if it’s only slightly more) since there are potentially more consecutive 0-bits in the high order bit positions.

Or are you worried that using the lower hash does indeed enable some selfish mining tricks because if they throw more PoW at it than their peers they can pull it off?

What if the lower hash is lower by a significant threshold?

Meh.

#9

In that case a miner who gets a “lucky” hash would know it’s definitely a lucky hash and could withhold it until a block is found and THEN release it, so to make everyone waste work and give himself comparative advantage.

With H(A||B) he can’t know whether his hash will be lucky, because B will be unknown and it will have 50:50 of flipping his block.

2 Likes
#10

Hmm. Yes correct.

I guess if they define some threshold when they feel “lucky enough” (say has 2, 3 or 5 or whatever extra preceding 0-bits)… then they can do the selfish mine, otherwise mine normally. Yeah, good point.

1 Like