Poolops what do you do with miners shares?

[Graet]

Seems to be some concern in the community about what pools do with miners hashpower.
I thought it would be good to have a thread where poolops could state what their pools do. It could be a useful reference for miners and help them decide where to mine
I would appreciate it if the community could keep this thread "clutter free" there are plenty of places this can be discussed in depth

There appears to be two schools of thought
1: as long as miners are paid for their shares poolops can do as they please with the hashpower (hop, merge mine other chains etc)
2: shares were invented so pools could keep track of work to pay miners

I'll go first

Ozcoin Pooled Mining Pty Ltd follows the second view

Bitcoin Pool
Merged Mining shares are submitted to bitcoind and namecoind for verification on ports 8332 and 80
Bitcoin only shares are accepted on port 8331 and are not submitted to namecoind and have no aux longpolls

Litecoin Pool
Litecoin on ports 9332 and 80

Thats it.

Thanks
Graeme Tee

Edit: thanks guys - good point all our blocks have eco@ozco.in /P2SH/ since we started using ecoinpool

[Jine]

We're (Bitlc.net) is doing the same as you guys.

Shares are generated by poolserverj WorkerMaker edition, and it verifies the shares internally.
Successfull shares that could be a solution for the block is sent to two upstream bitcoinds.

EDIT: All our blocks coinbase contain "BitLC" and our vote for P2SH: /P2SH/

We're then saving all shares (including stales/invalids) to our database.
And each 10-60min (depending on load and round length) we're calculating rewards for each worker, and then for each user.

The users are credited instantly when rewards are calculated, no need to wait for 120 blocks nor do we care if it's a orphan block or not.

Users can do payments instantly, and specifiy amount from 0.01 down to 8 decimals as you want.
So for instance - if you have 1.23456789 BTC, you can do a payment of 0.01234567 (8 decimals) to any address at any time.

We do not sell nor send shares to anything or anyone else then our own bitcoind on localhost.

--
Regards, Jim
Bit LC Inc.

[DrHaribo]

BitMinter only creates its own blocks. Shares are not sent anywhere else. Bitcoins + merged mining of namecoins. The word "BitMinter" is included in the coinbase of the bitcoin blocks.

I think transparency is important. If your pool op is doing something secret with your shares, it's probably because he thinks you wouldn't want to mine there if you knew what he was doing. And he might be right.

[bitlane]

I think transparency is important. If your pool op is doing something secret with your shares, it's probably because he thinks you wouldn't want to mine there if you knew what he was doing. And he might be right.

You mean like, merged mine an Alt currency to attack it with your pool's hashing power ?

[eleuthria]

BTC Guild has always mined blocks on its own Bitcoind/Namecoind.  Ever since the PoolServerJ workmaker editition, you can also verify our BTC blocks due to "BTC Guild" being included as part of the coinbase ("BTC Guild /P2SH/" is the current coinbase message we include).

[Sukrim]

There is no way I know of though to verify these statements other than trusting what you write here. From the information contained in a "getwork" message it is not possible to know coinbase messages or even if it's really a bitcoin block you're mining, not namecoin or anything else that uses the same hashing algorithm + data structure.

You could for example [puts on tinfoil hat] have a 50 TH/s pool each and just use ~300 GH/s for Bitcoin while paying all miners from your ginormously large private wallet(s), there's no way for you to proove this to someone who doesn't take your word for it.

You could post some analysis of where the coins from your blocks go, but that still could mean that you mine in secret somewhere else (own pocket, other chain, other pool...).

The old claim that poolops can simply steal every 100th block and call it variance, bad luck or stale share is still true and undetectable from the outside, even with statistical methods. It is however nice to at least try to be as open as possible (or it is all part of the conspiracy!!!112  )

[mcorlett]

There is no way I know of though to verify these statements other than trusting what you write here.

Select a block generation transaction, and pass the ?show_adv=true flag to blockchain.info, and it will show you the decoded coinbase:
http://blockchain.info/tx-index/15830054/f1445ae34d043f05c987809d70065d24089d9e696a81e55ca8961c6fa86bdd8e?show_adv=true

[farfiman]

We are down now but in a week we hope to be doing the same as above, also mining our own coins at times and also hopping double geometric pools.

I thought that isn't profitable ( any more than PPS ) !?

[DrHaribo]

Select a block generation transaction, and pass the ?show_adv=true flag to blockchain.info, and it will show you the decoded coinbase:
http://blockchain.info/tx-index/15830054/f1445ae34d043f05c987809d70065d24089d9e696a81e55ca8961c6fa86bdd8e?show_adv=true

When you are mining you don't have the generation transaction. You only have the block header. So you don't know that much about what you are working on.

There is no way I know of though to verify these statements other than trusting what you write here. From the information contained in a "getwork" message it is not possible to know coinbase messages or even if it's really a bitcoin block you're mining, not namecoin or anything else that uses the same hashing algorithm + data structure.

You make a good point.

Here's a proposal to fix it: "gentx" getwork extension.

When the miner announces support for "gentx" and the server supports it, the server will include in the getwork response the generate transaction and a merkle branch that proves this generate transaction is in the block.

Extra getwork response elements:
"gentx", usual string hex encoded format, of the whole generate transaction, usual byte sequence to represent a transaction, same way "getmemorypool" does for regular (non-generate) transactions.
"genmrkl", gentx's merkle branch, usual string hex encoded format

The miner can now:

• Verify that the coins are going to the pool's known address, so pool op cannot steal
• Look for merged mining data in the coinbase, so pool op cannot secretly merged mine
• Look for "water marks" (pool name) to see where your hashes are actually going
• Perhaps prevent being used in 51% attacks? Bitcoin blocks will soon be required to include the block height in the coinbase, and you already have the hash for the parent block in the block header. Comparing height and parent block with a trusted source, you could see if you are building at a height lower than you should, or an unknown parent block. Only thing is, blocks take some time to become known by everyone, and there are also (non-hostile) forks. As long as the height looks ok, you'd have to cut some slack for the parent block.
• Display some of this info to the user, like height, generate payment address(es), presence of merged mining and pool names or other printable strings.

Downside: some extra bytes sent in each getwork response. But hey, if miners support this they probably support "midstate" meaning you can ditch midstate and hash1, saving back some bytes again.

[mcorlett]

Select a block generation transaction, and pass the ?show_adv=true flag to blockchain.info, and it will show you the decoded coinbase:
http://blockchain.info/tx-index/15830054/f1445ae34d043f05c987809d70065d24089d9e696a81e55ca8961c6fa86bdd8e?show_adv=true

When you are mining you don't have the generation transaction. You only have the block header. So you don't know that much about what you are working on.
e parent block.

If your pool doesn't disclose what blocks it's mined, via a stats page or else, you shouldn't mine there.

[DrHaribo]

If your pool doesn't disclose what blocks it's mined, via a stats page or else, you shouldn't mine there.

Such a list only shows what the pool op wants you to see. You can't know whether he used your hash power to generate some other blocks in secret. Or used pool hopping of prop pools to make a bigger profit. Or is secretly merged mining (ok, you can check that for the blocks he does show you).

The problem is that you can see what the pool op wants you to see. But noone can prove that this is the only mining going on. With what I suggest above the miner could instantly see all the addresses coins are being sent to, for every block it works on.

[Jine]

I would support that, it seems pretty decent to me. (gettx etc)

[Sukrim]

Select a block generation transaction, and pass the ?show_adv=true flag to blockchain.info, and it will show you the decoded coinbase:
http://blockchain.info/tx-index/15830054/f1445ae34d043f05c987809d70065d24089d9e696a81e55ca8961c6fa86bdd8e?show_adv=true

When you are mining you don't have the generation transaction. You only have the block header. So you don't know that much about what you are working on.
e parent block.

If your pool doesn't disclose what blocks it's mined, via a stats page or else, you shouldn't mine there.

Nearly all pools (I saw some decent micropools that DID show transactions some months ago!) only show _after_ they mined a block that they did it. While it gives some proof that they indeed have miners at a certain total hash rate, I criticised something different - that you can NOT see what transactions go into the getwork blob you are currently hashing on. It could even not be Bitcoins at all, a 51% attack... the idea of sending the generation transaction + merkle root of other transactions is a good remedy for now, however in the future when transaction fees become more important we'd still need something different I guess.

[DeathAndTaxes]

With p2pool I know exactly what is going into the blocks I mine.

I would hope the same transparency could be achieved via traditional pools.  Even better multiple small pools could join p2pool to reducing variance and provide more accountability and transparency which still providing advantages p2pool can't offer (like lower difficulty shares, reduced variance for small miners and alternative reward methods).

[DrHaribo]

I thought the main concern was the things I listed above. But it would of course be possible to include all transactions.

Apparently Luke-jr. is already supporting this through a modified version of the "getmemorypool" json-rpc in his Eloipool server. See https://gitorious.org/bitcoin/eloipool/commit/fc22a5a3dee1843336f74d737b283ec3efe41533 Hope it's OK I promote your stuff a bit. 

The server provides the usual "getmemorypool" info with data for the block header and all the regular transactions. The modification is that the server in this case also includes a generate transaction.

If the server allows it the miner could exclude transactions (maybe you want to demand a minimum fee), or even add transactions the server hasn't seen. The server could also allow the miner to modify the coinbase, although BIP-16/17 style voting may be a bad idea if the server doesn't actually support the things the miner is "voting" for.

This would also allow the miner to create its own work, thereby drastically reducing server load. You only need a new set of data once per block change.

And it also makes possible all the checks I described above.

This seems like the more versatile option that fixes a lot of issues with mining. Can we make this a standard and get more miner and pool backend authors supporting it?

[Luke-Jr]

Apparently Luke-jr. is already supporting this through a modified version of the "getmemorypool" json-rpc in his Eloipool server. See https://gitorious.org/bitcoin/eloipool/commit/fc22a5a3dee1843336f74d737b283ec3efe41533 Hope it's OK I promote your stuff a bit. 

Not a problem.

But note this is in a non-master branch of Eloipool and not live on Eligius just yet. I'd like to allow miners to add transactions or other coinbase content (msgs/data), but the current code does not support actually submitting via getmemorypool yet.

If the server allows it the miner could exclude transactions (maybe you want to demand a minimum fee), or even add transactions the server hasn't seen. The server could also allow the miner to modify the coinbase, although BIP-16/17 style voting may be a bad idea if the server doesn't actually support the things the miner is "voting" for.

Yeah, we should probably come up with a standard format for flags so pools can filter out ones they don't support.

This would also allow the miner to create its own work, thereby drastically reducing server load. You only need a new set of data once per block change.

Not quite. With payouts in the coinbase, I need to expire work every 2 minutes regardless. And merged-mining adds its own twist. The main thing it enables is real-time auditing, and allowing miners to add their own transactions.

Can we make this a standard and get more miner and pool backend authors supporting it?

I suggest building something similar to bitpennyd that miners can use with getwork.

[Sukrim]

Even with P2pool only if you run a full node, you know what you get into blocks - if you get some getworks from a publicly exposed node, you still have no clue on what you're hashing.

Forcing miners to have a full bitcoin node running (to get transactions and whatnot into blocks) might become a scalability issue...

My idea would be similar to P2pool, just not with a mesh network approach but with a one-to-many approach. Pools start sharechains for each individual mining account. Users there can then either (for a 0.x% fee?) use the pool as getwork source or set up their own "M2pool" (miner to pool) client and include their own transactions at will. The pool will then only check if generation transactions are done according to the pool's ruleset, if the computed hash is really that difficult and if the block is a winning block. Every x minutes/hours/days/whatever the pool then publishes the updated set of transactions to reward all it's miners accordingly and that's the only transaction (as generation) miners have to include + obey.
Such a pool could then even run "below" P2pool, acting as a huge miner to P2pool itself, profiting from the block finding rate that P2pool already has, but offering a different interface or other benefits(?).
One of the main advantages of an "M2pool" would be the resilience towards pool outages - headers of the current block can be obtained from any bitcoin client (and there might soon be "lite" clients that only store parts of the blockchain, or just headers...) and blocks can be sent a little bit later to the pool too. Depending on the payout scheme, it wouldn't even make that much of a difference, when the pool finally realizes that you did some work.

Getworks then would only be generated locally or (if you trust the poolop) could be done by the pool traditionally.

[Graet]

Seems to be some concern in the community about what pools do with miners hashpower.
I thought it would be good to have a thread where poolops could state what their pools do. It could be a useful reference for miners and help them decide where to mine
I would appreciate it if the community could keep this thread "clutter free" there are plenty of places this can be discussed in depth

I guess the bold bit.....sigh

so far Jine, DrHaribo, eleuthria and myself have posted what we do on our pools, thanks guys. I see Luke-Jr has joined the discussion but not answered the question....

Thanks Chaang Noi a.k.a. Goat for info on your proxy

I REALLY had hoped we could just have a thread for poolops to respond to my initial post. once the "discussion" (that I asked to be elsewhere starts) this thread loses its point...

so keep filling it up, when poolops post (and i have time) I will make  a seperate locked thread with just the poolops responses so miners can have a concise list.

If your poolop isnt posting in this thread what they are doing with your shares ask him "why"...

[farfiman]

If your poolop isnt posting in this thread what they are doing with your shares ask him "why"...

REAL vs Proxy   - round 2 - ding!




edit: sorry for the clutter graet...

[Graet]

Any other poolops going to stand up and state what they do with miners shares?

There must be more than 4 of us willing to share