So, if I understand this right, and I'm not sure I do, the main problem is that there is no way to insure that the "generation address" is in fact the pool's address unless the pool hashes the block itself? So if the pool doesn't generate the hash for each block, you could potentially trick the pool into thinking that you are working on pool hashes when you aren't. When you actually hit a hash at the right difficulty, you claim it for yourself because you were actually using your address. At the same time you could submit the same work to a different pool that also can't confirm that you are using the correct address. Is this why you can't trust a pool member to provide the precomputed block data?

Oh, ok I see now. I did not realize that the pool gave you partially precomputed data. Now it all makes much more sense. Could the pool member send the same sort of precomputed data back to the pool? This way the pool doesn't have to process every block itself? Then when a proper solution for the difficulty is found the pool could hash the entire block for verification. Is there some reason the pool would need to "pre-hash" every block from every user itself? Can the member not be trusted to send a valid precomputed value for the block?

I don't understand all of the nuance of the hashing system, but I think I have a possible solution for the high bandwidth problem. As I understand it, currently the pool gives you the block information once, you add nonce and hash, and when you get a share you send the nonce:

Current System (low bandwidth)

1. Pool gives block to you once
2. You add nonce and hash
3. If share, send nonce to pool for verification
4. Repeat at 2, when valid block found start back at 1

This results in low enough bandwidth to be a sustainable system. Now people have said that the new system would require to much data to be sent because it would look like this:

New system (high bandwidth)

1. You generate your own block
2. You add nonce and hash
3. If share, send whole block for verification
4. Repeat at 2, when valid block found start back at 1

This results in bandwidth too high because you send the entire block with each share. But this seems thoroughly unnecessary to me. Why not as below:

New system (lower bandwidth)

1. You generate your own block
2. Send block to pool once
3. Add nonce and hash
4. If share, send nonce to pool for verification
5. Repeat at 3, when valid block found start back at 1

This would be almost the exact same bandwidth as the old system. In the old system the pool sent the block data to each member once, in the new system each member sends the block data to the pool once. The pool would have to do a little more work storing the blocks that each member is working on, but I don't think it is really a show stopper.

Is there a reason why this doesn't work?

I haven't been able to access bitcoin watch for a while. I'm getting a "server not found" error. Is anyone else having this problem? Does anyone know when it'll be resolved?

There is also betco.in for poker.

Congratulations. I just so happen to own a wedding photography and videography company that works all over the US. I would, of course, be willing to arrange something in bitcoins. I've been wondering if there is a demand for bitcoin wedding photographers. I guess there is. PM me if you want information.

1) It is possible to brute force attack your private key. But, it has been shown that it would take a computer that uses more energy than the sun creates to brute force it before the universe ends, trillions of years from now. The NSA does not have that power. The methods bitcoin uses are the same methods as any online bank. It is considered uncrackable unless the programer got it wrong. The math is solid.

2) There is discussion about "only sending the headers of blocks" to most users in the future. I'm not sure what that exactly entails, but it would make the amount of data the average user receives a much less.

3) Once again, even if we were hashing to form an attack, it would be like trying to create a block with difficulty 2^256. We're having trouble with just 400,000. The way the math works, our computing speed is pitiful, a tiny drop in the ocean, compared to what you need to mount a successful attack. If our computing power continues to raise EXPONENTIALLY for HUNDREDS OF THOUSANDS of years, then maybe we would begin to cover a small fraction of all the possible hashes.

SHA 256 is secure. Very secure.