[mining] resolve mining pool conflict for block 00000000000000000003aff64602a1687539515d9e2c44dc1f8c31289901781a

[nymkappa]

This PR adds a new mining pool conflict check when we tag blocks to their pool. The new logic is:

• If we only found one matching pool, we tag the block to it
• If we found more than one matching pool, we need to hardcode how to resolve the conflict and manually pick the mining pool. In the future if there are lot of conflicts, a weighted mining pools approach could be used. I will check if we already have lot of conflict in the historical blocks.
• If we did not match anything, tag to the unknown pool

Testing

DELETE from block where id = '00000000000000000003aff64602a1687539515d9e2c44dc1f8c31289901781a'

Restart the nodejs backend and confirm you see the following message:

May  7 22:57:17 [52945] INFO: <lightning> [Mining] Got conflicting mining pool match for block 00000000000000000003aff64602a1687539515d9e2c44dc1f8c31289901781a. Manually picking foundryusa

For now, if there is a mining pool conflict and we did not defined a conflict resolution rule, we return the first match, this way we keep the existing behavior intact.

So to resume this PR only fixes the tag for block 00000000000000000003aff64602a1687539515d9e2c44dc1f8c31289901781a but allows future manual fixes if needed

[nymkappa]

After running this for a while I've noticed there are quite a lot of conflict (about 500+ for up to block ~525000).

Most of them seems related to a conflict in the mining pool definition. For example https://mempool.space/block/0000000000000000001b9460202a7acc512630988f8204df39e5c7d605587425 is tagged to https://mempool.space/mining/pool/1thash using the coinbase address, but the tag �g��A<v(JA<u�Y/canoepool/�4P������� seems to obviously point that this block was mined instead by https://mempool.space/mining/pool/canoepool.

There are multiple scenarios:

• They are the same mining pool
• They were working together at some point
• The mining pool definition is wrong

Either way in those cases I don't know how to resolve the conflict without having to do some digging.

@0xB10C have you noticed those conflict in the mining pool definitions?

[0xB10C]

Thanks for looking into this. There's also bitcoin-data/mining-pools#36 (comment) which is quite similar. Might be worth posting there too.

I think that some pools merged or renamed at some point. In this case, the most recent coinbase outputs (e.g. in 688730) to the address 147SwRQdpCfj5p8PnfsXV2SsVVpVcz3aPq have the /1THash/ coinbase tag. In 525415 the coinbase paying to the same output had the /canoepool/ tag. I think they renamed. It might make sense to merge the definitions by moving the /canoepool/ tag to the 1Thash definition. However, this might again confuse someone as a pool tagged as /canoepool/ is then shown as a 1Thash pool...

To fix all of the 500+ mismatches likely needs some manual work. However, I'd be happy to invest some time into this (though it's not a top priority for me right now).

[softsimon]

It's just wrong to hard code a single block in the code like this.

If we are to do exceptions in the matching we need a better way.

[nymkappa]

What is your suggested better way?

We could move the hardcoded block ids into a dedicated file to avoid spamming the already messy blocks.ts file. But in terms of "hardcoding" I don't really see a way around it in the example I've provided https://mempool.space/block/0000000000000000001b9460202a7acc512630988f8204df39e5c7d605587425.

An alternative approach would be to have some UX elements to show that the block cannot be assigned to a miner with certainty and simply exclude it from the stats.

[softsimon]

Aren't these very related to the whole pools json database matching. So it should be in that file or a separate file that share the same commit history. Everyone using the mining-pools repo should get the exceptions list, and it can be collaborative.

[nymkappa]

That's a good suggestion. @0xB10C what do you think of this approach?

[0xB10C]

I think having an exception list that we manually define is OK. It sounds like a lot of work though.

One approach I've been happy with is:

1. try identifying by coinbase output address first
2. if unsuccessful, try tagging by script tag
3. if unsuccessful, miner is unknown

The coinbase output address is a better metric to check first as it's quite expensive to game. As a mining pool you can include arbitrary tag in the script at close to zero cost. By putting another pool's address in the output, you'd
essentially gift the coins to another pool.

[softsimon]

See comments

[nymkappa]

Closing for now. My approach is not satisfactory. @softsimon or @mononaut feel free to take on this issue if you want 👍🏻 .