Bitcoin Forum

Is there a way to verify that a particular pool is submitting shares to the network and how many shares it has submitted?

I have a hypothetical theory brewing and I'd be interested to learn if this is possible or available data?

Thanks

G.

What do you mean by verifying? Do you need to verify every pool if it's submitting hashrate to the network? I don't think you can verify them because they're private, but we have some sites or tools where you can check the current stats of every mining pool.

Why not check them here: https://miningpoolstats.stream/bitcoin

What I mean is I want to verify that the number of share submissions made to a particular pool are actually being processed by that pools bitcoin core and that they are not forwarded onto another service.

i.e. spoofing until a suitable share size is found

for example

Miner 1 connects to Pool A

Pool A's software processes the request from Miner 1 for a get block template, now rather than issuing the block itself from its own bitcoin core, it goes off to another service that lets say is paying PPNLS and requests the block from there.

Miner 1 is none the wiser as to where the block template came from, so it hashes the block and reports the share back to Pool A. Meanwhile the PPLNS pool is none the wiser either since the get block template request would look properly formatted as though it was from a miner.

Pool A's software looks at the returned share value and if its below a given threshold it returns the block to the other PPLNS service, thereby Pool A is earning a fee from the work done by Miner1

Now, lets say that Miner 1 is lucky and the share value it submits to Pool A is greater than network difficulty i.e. its found a block.

Pool A's software instead of forwarding the result to the PPLNS service instead returns the block to its own bitcoin core, thereby winning the block and Pool A's owner gets their 0.5-2% block fees while the PPLNS service looses out on the block rewards.

Or worse in senario #2

Pool A's software rejects the share and spoofs the whole block for itself under the guise of a different address and Miner 1 looses out as Pool A's software has essentially stolen the block.


Because of the intermediary of Pool A's software the chain of trust is broken.


Its all hypothetical until I can prove that its not.

This comes up every now and then and you can see all the info if you want to put a bit of work into it.
Follow this post: https://bitcointalk.org/index.php?topic=5397166.msg60503248#msg60503248
And it will show you how to decode the info between your miner and the pool.

But, beyond that no it can't be done since if you change any info the other pool will not see it as a valid share.

-Dave

Thanks Dave,

I know I've fallen into another deep Rabbit hole, but I have a feeling a service that I've had a rig pointed to has been doing what I described above.

I just need to work out how to prove it.

The first step is showing a discrepancy between the number of shares Pool A is reporting were submitted and what their core actually submitted.

Thanks for the link, I'll take a read through that in the morning with a clear head.

Cheers

G.

The pools Core is not constantly submitting 'shares' to the BTC network....

Shares are strictly between miners and a pool. They are how a pool distributes the work for the block it has generated to all miners connected to it. Each miner is getting unique work to find the hash needed to satisfy the pools block being found.

A pool is a stand-alone entity running Core that only communicates with the BTC network to:
 A. Always listen to be notified when a block is found & get the header of the new block
 B. Verify the Tx's in it meet all BTC rules (are valid TX's) and then generate new work to start building on that found block
 C. Based on the pools new work, generate unique shares to send to all miners connected to it
 D. When a miner in the pool reports that it found a block 1st verify that it really did and if so, broadcast the Block Found message to the network for others to pick up on (to again generate new work to build on it).

Sad to say, *some* pools do not always verify the TX's in part-B. When a block is found they sometimes skip the verification and generate new work for an empty block to save a few ms of processing time and hope their empty block is the next one found & built upon.

@OP, you should probably refer to https://kano.is/index.php?k=minedet for details on how BTC mining works.

This is a widely used approach, many small pools (don't want to name them but they are obvious  :D) don't mine their own blocks, they just act as a proxy, most of those pools provide PPS payments and charge some good fee while having deals with larges pools like Viabtc, they do not trick Viabtc, they actually have a deal, miner 1, doesn't care because the proxy pool pay them what they promised to pay.




Nah, this can't happen, the getblocktemplate is generated by the PPLNS pool,  miner 1 hashes the PPLNS payment address (coinbase transaction) inside the block they hashing, this can't be changed because it's in the Merkle tree, if pool 1 changes the coinbase transaction AFTER miner 1 submits the share, the whole block will be rejected by the network.

What you need to understand is that once something is hashed, there is no going back, so pool 1 is forced to either send the work with the PPLNS service address or his own address, if it's his own address then the PPLNS pool will not reward him for any shares because those shares will be invalid, so it's not like pool 1 can know before hand "oh the next share is going to win a block, let me put my address in the coinbase transaction" nah, no , nop this can't happen.








Nop, can't happen. Refer to my previous answer.



edit: I tried a short and sweet explanation. if that doesn't cut it, let me know. I will do a long, boring explanation to show you how whatever you think is happening is impossible.