Mining Pool Detection about insight HOT 15 CLOSED

Hey, it's better than nothing at all - those were done during testing of the capability to inject things in the first place, so you won't find any of the other miners during that time period tagging either ;)

from insight.

@luke-jr It's a challenge if nothing else, there's some blocks late in that period that certainly aren't yours ("I'm eating a big juicy hamburger"). I'm not sure if it warrants the effort of making a hardcoded lookup table just for those early blocks but it's still fun to think about.

from insight.

This detection can be (easily) fooled, right? In case a miner what to hide its tracks it could add a different string into the coinbase, or even a string from an other miner. So that would be the added value of showing this information? (Im just asking).

IIRC, its be possible to track miners by the IP that (first) relayed the block (that needs a modification on bitcoind to save those IPs). I wonder if one could identify miners by the output address of the coinbase transaction.

from insight.

Sounds like a good idea to me. It's true that it's easily fooled, so the interface could just make it clear that these are unverified claims about which pool it is.

from insight.

I agree, this could be a good addition.
On Feb 15, 2014 11:46 AM, "Ryan X. Charles" [email protected]
wrote:

Sounds like a good idea to me. It's true that it's easily fooled, so the
interface could just make it clear that these are unverified claims about
which pool it is.

Reply to this email directly or view it on GitHubhttps://github.com//issues/340#issuecomment-35157748
.

from insight.

@matiu It certainly can, it's more just for-interest than anything else. There's a lot of tell-tale information about the origin pool, but unless you're blockchain.info with some manual peering then looking at the connecting IP address is likely futile. I know that BTCguild and Eligius both use a variety of internal and external facing nodes to avoid the particular problem of people finding their IP addresses and attacking them. It's likely most large pools don't have a single place where their blocks exit.

Some pools like p2pool have very obvious signs (though not a coinbase signature), namely in the case of p2pool that they add a dummy output at the end of the coinbase output which enables them to effectively use Stratum. Some pools do use static addresses to mine to but it's not universal, easier just to identify the ones that want to be identified and leave it at that.

There's nothing in particular to be gained by identifying them, but it's always interesting to see who is creating gimped, tiny blocks. Discus Fish (f2pool) currently creates ridiculously small blocks (48kb) to try and reduce their orphans, for example.

from insight.

@Eveiv Thanks a lot for the insightful answer!
I didn't thought about identifying the ones that generate small blocks, we can generate some reports on that also.

So, to move forward, for a first version, would you say it would be enough to have database of the following form:

  [
        {   "pullName":  "myPool",
            "url": "myPool.com",
            "searchStrings": [
                   "mypool",
                   "myPool"
            ]
       },
       {...}
       ...
   ]

For each pool we will have a list of identifier strings. The coinbase will be scanned for those strings until the first match. We can put the most common first to speed up the process. If a simple string match is enough (and no regex) would be nice.

What you think? Could you provide that DB in a JSON format?

from insight.

@matiu

These are the signatures I've collected for the moment, it should be more than enough for a proof of concept and to get the system recognizing most of the current pools. I'll work on expanding it when I have more time to. Some like deepbit.net don't tag their blocks, but there's nothing we can do about that for the time being.

https://gist.github.com/Eveiv/40edfc61f1a0d30f5e5a

from insight.

Fantastic!

will add it soon.

On Sat, Feb 15, 2014 at 9:40 PM, Eveiv [email protected] wrote:

@matiu https://github.com/matiu

These are the signatures I've collected for the moment, it should be more
than enough for a proof of concept and to get the system recognizing most
of the current pools. I'll work on expanding it when I have more time to.

https://gist.github.com/Eveiv/40edfc61f1a0d30f5e5a

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/340#issuecomment-35173148
.

Matías Alejo Garcia
Skype/Twitter: @EMATIU
Roads? Where we're going, we don't need roads!

from insight.

@luke-jr @Eveiv I just added this new feature. Take a look :D

from insight.

@colkito Very good. I'm not sure "relayed by" makes sense in this context though, it's sensible for blockchain.info which does detection through it's peering but not so much for Insight. Maybe "mined by" might make a bit more sense?

from insight.

Yep. I was talking about that with @jeff. I will change it to "mined by" or
"generated by". Thanks!
On Feb 18, 2014 7:08 PM, "Eveiv" [email protected] wrote:

@colkito https://github.com/colkito Very good. I'm not sure "relayed
by" makes sense in this context though, it's sensible for blockchain.infowhich does detection through it's peering but not so much for Insight.
Maybe "mined by" might make a bit more sense?

Reply to this email directly or view it on GitHubhttps://github.com//issues/340#issuecomment-35440848
.

from insight.

We were discussing the same thing moments ago. Someone will make the change soon

from insight.

Is there any preference for the behavior I should use tagging for dead pools? There's some which have long since disappeared but still warrant including in the information panel. nmcbit.com for example mined 105 blocks in 2011 which is fairly significant, but the domain has long since been taken over by another party.

from insight.

just wondering if this will let you search pools using static addresses? if not is there a way to implement this?

from insight.