Coin-eater...

[ISAWHIM]

Just for curiosity...

What measures are in place to stop a "miner" within a "pool" from doing this...
- Mine away all the useless shares (Which takes no effort)
- Don't actually mine for any coins... (Thus saving a lot of power, and being able to mine multiple pools at once.)
- Collect a percentage from the useless processed shares in the pools.

or...
- Mine away in a pool...
- Use your own wallets server-id, instead of the pools id... Thus, when you find a block, you keep it... and still get rewards for shares from the pool. (Only using your ID on the blocks, not the shares, which are returned.)
- Mine multiple pools, processing useless shares, while collecting the found blocks for yourself... Thus, ensuring invalid blocks are always returned to the pool, too late, after they have deposited into your wallet.

[fghj]

- Mine away all the useless shares (Which takes no effort)

What do you mean by that?

- Don't actually mine for any coins... (Thus saving a lot of power, and being able to mine multiple pools at once.)

Then you have no shares to send to pool so they won't pay you.

- Collect a percentage from the useless processed shares in the pools.
(...)
- Mine away in a pool

?

- Use your own wallets server-id, instead of the pools id... Thus, when you find a block, you keep it... and still get rewards for shares from the pool. (Only using your ID on the blocks, not the shares, which are returned.)

To do that you would have to know answers before computing them, why don't you just solo mine blocks by calculating only the hashes of headers that will be below target, you could mine 300 millions blocks per second (this is sarcasm)

- Mine multiple pools, processing useless shares, while collecting the found blocks for yourself... Thus, ensuring invalid blocks are always returned to the pool, too late, after they have deposited into your wallet.

Each pool will send you different root hash, collecting blocks for yourself also changes root hash. Changing root changes blockhash so you would have to calculate it once again and it will most likely be well above target (if you want it to be accepted by network it's supposed to be below).

You might want to read about hash functions, Merkle trees, proof of work and then about what is inside Bitcoin block headers, you will then understand why none of your ideas would work.
https://en.wikipedia.org/wiki/Cryptographic_hash_function
https://en.wikipedia.org/wiki/Merkle_tree
https://en.bitcoin.it/wiki/Proof_of_work

Btw. If you really need to do something bad you could submit only shares that are above target and drop those that are below, in PPS scheme you would lose 1/10000000 (DK about others) of your income but pool would effectively solve blocks like you don't exist (like they have less hashing power than they would have if you were not cheating). It could cause outflow of miners from attacked pool.

[Remember remember the 5th of November]

Just for curiosity...

What measures are in place to stop a "miner" within a "pool" from doing this...
- Mine away all the useless shares (Which takes no effort)
- Don't actually mine for any coins... (Thus saving a lot of power, and being able to mine multiple pools at once.)
- Collect a percentage from the useless processed shares in the pools.

or...
- Mine away in a pool...
- Use your own wallets server-id, instead of the pools id... Thus, when you find a block, you keep it... and still get rewards for shares from the pool. (Only using your ID on the blocks, not the shares, which are returned.)
- Mine multiple pools, processing useless shares, while collecting the found blocks for yourself... Thus, ensuring invalid blocks are always returned to the pool, too late, after they have deposited into your wallet.

Doesn't work like that. There are checks in place to see if a share is valid or not, including if the miner finds a block and tries to submit to his Bitcoin client.

[ISAWHIM]

A share has nothing to do with the block. It is just some useless value sent to you, to see "how fast you work". You are credited for the share, not for the actual block-work. (Block work is just thrown out once a new block is detected, if you have not submitted the solution to the pools wallet-ID.)

Like I said, what stops me from "Processing" useless shares from pool-a, pool-b, pool-c... but not actually doing the "block work" for pools a-c... Only submitting the "shares" to all three pools. (I am saying that you actually DO process the shares. Thus, they will all be valid.)

"You do not process shares when solo-mining, because you do not have to submit proof of your processing power."

"Shares are irrelevant blocks of data, distributed by the pool, to test your speed to give you credit for your power in a round, and have little impact on the processing power of hashing the actual block." (However, that is untrue. If you are stopping hashing the block, to hash a useless packet, then that takes-away hashing power that would normally be used to hash the actual block. No matter how easy it is. You just end-up hashing more easy useless shares then hard shares.)

Then, since that is not actually slowing the computer down... I am just solo-mining with my ID. Mining the block that I SHOULD be mining for the pool. Thus, since I am not actually mining that block with the pool, just pretending to mine it... the "pool" never gets the blocks I find. Yet, I get paid from all the pools, as if I am honestly mining away for them.

Yes, I realize the "stock program" is not programmed to do that. They would not be using a stock program.

They actually do the "share work". A share is just a fast and useless calculation, used to measure your speed, while you "solve the block". It has nothing to do with the block solution itself.

[ISAWHIM]

Doesn't work like that. There are checks in place to see if a share is valid or not, including if the miner finds a block and tries to submit to his Bitcoin client.

There is NOTHING in place to stop me from solo-mining MY block (which is the same as the POOL BLOCK.), then simply submit useless invalid block data to the pool, for that block... if I find it, and submit it to MY WALLET. Or just "not submitting any block" to the pool. As far as the pool knows, I am still processing it, and just "have not found a solution yet".

EG, "Not actually doing the pools work, other than the share-work." Instead, using your actual processing to mine your own wallet/server.

I can mine both solo and a pool at the same time... anyone can.

[kjj]

Basically, you don't understand how mining works.

The pool gives work to your miner.  That work is in the form of a block header, and it is specific to that pool: the associated block pays the pool.  Your miners work on that header, and any hashes found that meet the pool's criteria for being a share are sent back and used to calculate your speed and credit your account.

You can't send the same work to multiple pools, because only one of them will recognize it as being one of their blocks.  The pool is not giving you "worthless work" to do for shares, you are doing the actual work and looking for the actual block.

A "share" is just a header hash that meets the pool's share criteria, which may or may not meet the network's block criteria.

[ISAWHIM]

I know it is unique for each server. That is why you return each "share" where it belongs. Without actually processing the block.

We are working on the same block, until it says "new block". If you do not work on the block, for THAT server, but you do for your own (solo-mining)... then you are returning just the shares, which are usually 1-64 difficulty, which takes less than 1% to process from the servers "block", without actually trying to "find a difficulty 11,132,232 block for that server. It has no clue if you are actually hashing the block, and trying, or if you are just returning shares that are "valid" for "that servers block".

I know exactly how it works.

I want to know what measures are in place to prevent this.

The server only checks to see if the hash is valid for the share. Again, if "shares" actually consumed that much processing, then that would result in less processing for finding a block, thus, less actual hashing power. That is why the difficulty is so low for a share, so it does NOT interfere with processing the block itself (for a block-result).

"A share is awarded by the mining pool to the clients who present a valid proof of work of the same type as the proof of work that is used for creating blocks, but of lesser difficulty, so that it requires less time on average to generate."

EG... you do not have to actually process the block (looking for a valid-block, just keep processing the "share-difficulty", which takes nearly no time at all.)

EG... Running 4 clients, allows you to "present a valid proof of work of the same type as the proof of work that is used for creating blocks, but of lesser difficulty, so that it requires less time on average to generate", one for each of the servers.

Thus, you get paid 4x for doing absolutely nothing, except processing "valid shares". While on the fifth client, you are solo-mining on your server/wallet. (If you "happen" to stumble-upon, a valid share for another client, you could still submit it, but you wouldn't be "looking" for solutions, just accepting one if it came around.. for THAT server.)

[teukon]

Here is a simplified analogy with dice which should highlight the problems with you proposed attacks.  I drop all the complexities concerning fees, the market rate, hardware, difficulty changes, orphans/stales, or different pool reward structures (I use the simple and popular "pay-per-share" method here)

(Real) Mining:
You have a 20-sided-die (a d20).  You roll the die on a table.  If you roll a 1 you win a dollar.  If you roll anything else you win nothing.  You keep rolling the die and claim as many dollars as you can.

Pool mining:
You and two friends sit at the table with a pool operator (boss).  The boss gives you each a d20 and you all start rolling your dice.  Whenever one of you rolls a 4 or less, you show the boss and he gives you 25 cents.  If someone rolls a 1, the boss wins a dollar (the boss is mining as above).

When you are rolling your die for the boss you are doing work but you are not making any progress towards rolling a 1.  A roll of 2, 3, or 4, is worth precisely nothing as far as real mining is concerned: the boss takes these rolls as an indication of how hard you are working for him.

Extra detail:
The boss has a blue wallet.  You have a red wallet and your friends have green and yellow wallets respectively.  The boss gives you all blue d20s to roll.  When you roll a 1 the boss wins the dollar because of the colour.  If you want to win the dollar for yourself you must roll a red d20 but then the boss won't give you 25 cents for rolling a 4 or less.

[teukon]

The server only checks to see if the hash is valid for the share. Again, if "shares" actually consumed that much processing, then that would result in less processing for finding a block, thus, less actual hashing power. That is why the difficulty is so low for a share, so it does NOT interfere with processing the block itself (for a block-result).

Your right that hunting for shares does not interfere with the processing of the block itself but this isn't due to low share difficulty.

Back to the dice analogy above.  A share is a photo of a d20 with a 1, 2, 3, or 4 showing.  A block is a photo of a d20 with a 1 showing.  Looking for a share and looking for a block involve exactly the same work, that of repeatedly rolling the die.

If you focused 100% of your processing power on finding shares, not on "processing the block", you would be pool-mining no faster than an equally powerful honest miner and you would still find real blocks with the same frequency.  You could attack the pool by throwing these blocks away but this does not benefit you.  Indeed, such an attack causes you a tiny amount of harm (more harm if you are using an alternative pooled-mining method at a small pool).

[ISAWHIM]

Wow, that analogy was sooo useless, it wasn't even funny.

I found the answer I was looking for...

"There is only one pool-type that has preventions for this non-work-worker. (puddinpop)" (Though, it does not say if that is checking "worked failures metahashes", or just "metahashes of groups of shares-hashes", which would be back to being useless again.)

That is the only pool that actually checks if you are truly working, not just submitting "shares". (Which DO NOT require you to actually have worked for a block-solution.)

Finding difficulty 1-64 requires a micro-second or two. Finding difficulty 11,121,323 takes about 30 min. If you STOP processing after finding that share, and now process the next-servers share... then the next then the next then spend the rest of the time processing YOUR-SOLO... and return every time you are expected to submit the next 1-64 share for the others... you do that. (You can do a few in advance, to just release them at the right times, if needed.)

In any event, it is good to know that someone actually did something to attempt to prevent this situation. Though, in my eyes, I don't see that as a win, as it does not seem to be used. Or effective.

Again, (hashing a share) is like stopping after finding a 1-64 difficulty, is not = to work-solution. That is like stopping rolling after you hit a 1 or a 2 or a 3 or a 4 or a 5 on any ONE of the FIVE 6-sided dice... instead of keep rolling afterwards, trying to get Yahtsee, which takes hours (solving a valid block).

[teukon]

Wow, that analogy was sooo useless, it wasn't even funny.

Well, at least you read it.

Finding difficulty 1-64 requires a micro-second or two. Finding difficulty 11,121,323 takes about 30 min. If you STOP processing after finding that share, and now process the next-servers share... then the next then the next then spend the rest of the time processing YOUR-SOLO... and return every time you are expected to submit the next 1-64 share for the others... you do that. (You can do a few in advance, to just release them at the right times, if needed.)

Why do you think it's so super easy to find shares?  Why not just link up mining software with one big pay-per-share pool and mine shares (completely ignoring the real blocks and real difficulty) for all your worth and make a fortune?  If you do this and show others how then the problem will be fixed very quickly.  You can always return unfairly acquired funds later if you would feel guilty.

[Remember remember the 5th of November]

A share has nothing to do with the block. It is just some useless value sent to you, to see "how fast you work".

Then you really have no idea how Proof-of-Work works. A share IS a block, in fact. It's a matter of whether it meets the network difficulty. You are credited regardless of this, since you provided the pool valid work. In case you tried to game the pool and sent it invalid work, it will be rejected and will be noted on the pool.

"You do not process shares when solo-mining, because you do not have to submit proof of your processing power."

They actually do the "share work". A share is just a fast and useless calculation, used to measure your speed, while you "solve the block". It has nothing to do with the block solution itself.

The reason you don't submit shares when solo mining, like in pools, is because pools send you a target of difficulty 1, and check to see if the shares is >= diff 1, but solo mining, Bitcoin sends you the network target which is as of this post 11.2m.

A share is NOT a fast and useless calculation.

[wheatstone]

ISAWHIM, either you have misunderstood something about how mining works or you are failing to get US to understand what you mean.

I suspect the former.

Hashing consists of:

SHA256(SHA256(BLOCKHEADER)

Where BLOCKHEADER = VERSION + HASHPREVBLOCK + HASHMERKLEROOT + TIME + BITS + NONCE

(with + being the concatenate operator)

The merkle root hash contains the hash of the transactions, including the coinbase payout address (new coins + fees).

Your mining software repeatedly calculates the double hash above, incrementing the nonce and specific other subfields (e.g. extraNonce in the merke root). This is the ONLY hash your rig is calculating!

This hash value needs to start with a sufficient number of zeroes in order for the hash to be a valid block hash, whereas the number of zeroes required for your pool to accept it as a "share" is much smaller.

For every share you submit, you have calculated billions of hashes. The pool operator can easily verify every hash you submit and check that it contains a merkle root allowed by the pool (i.e. guaranteeing that the pool is getting the coinbase payout). The computational requirement of this is billions of times less than your effort in finding the hash (since you needed to calculate, on average, billions of hashes to find one with enough leading zeroes to be accepted as a "share").

This is a central tenet of Proof of Work:

Expensive to compute, cheap to validate.

-> There is no way you could sneak in a different coinbase payout. The pool software would notice this immediately since all shares are validated.

-> There is no way you could quickly generate a lot of "shares". The average number of hashes you need to calculate for each "share" is fixed (determined by difficulty, i.e. number of leading zeroes) and you cannot know beforehand which nonce (+ extraNonce) will give you hash with enough leading zeroes, so you HAVE to calculate billions (on average) for every "share".