Topic: Poolops what do you do with miners shares? (Read 4081 times)

Yes, it does. It seeks out alt chains to destroy them, like a fucking death star, all fuckin' Darth Luke, nigga.

Eligius is experimental, and I don't consider it appropriate to guarantee any single behaviour. My current project for Eligius is enabling miners to do realtime auditing and block customization (like p2pool).

They can write what they want here...

Either they are trustworthy and you can believe what they say here which wouldn't change anything
OR
they are liars but there's no way I know of to be sure that they aren't - short of solving a Bitcoin block from that pool yourself (good luck with that!).
In the end there's no way currently to verify any claims of any poolop here (but also no way to falsify, so you can't see if someone's lying either), it's all about trust.

The real question should be btw.:
"Poolops, where do your getworks come from, to which chain(s) do they fit and which transactions do get included?"

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

REAL vs Proxy   - round 2 - ding!




edit: sorry for the clutter graet...

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"...

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.

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.

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

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.

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

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?

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).

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.

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

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.

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

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.


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.

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

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

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  )

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).

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