Pool seems to be down, strange that the website is working
And we're having bad luck finding that first block 

While not a math guru, I am certain this can't be done. The algorithm uses these kinds of operations:

- rotate or shift bits right by three different numbers of places, then XOR together
- select bits from one of two values, depending on bits in a third
- majority of bits set/clear in three values
- addition of the result of these operations and constant values for each round

you can build multiplication out of these operations if combined in a certain way, but the SHA-256 algorithm does not use them like this. If (parts of) SHA were equivalent to something as simple as multiplication, I'd say it could be broken in no time.

Also, SHA256 uses 32 bit values for everything. You could of course implement it on an 8 bit machine, but this would make it much slower. And having 24 bit wide registers does not even mean you could run three 8 bit ops at the same time

Another thought I had:
Is aggressive loop unrolling really helping performance? At least for FPGAs, I guess that lots of very small units that maybe do one hash every 64 clock cycles could be better than a much bigger unrolled design, and the same could be true for GPUs. Was this already tested or did everyone start with the assumption that unrolling is the way to go?

Yes, I understand that. Still seems a bit strange, especially with the negative shares. SLICE now has -230, do you plan on collecting that debt? 

I'm slowpoke btw, and I'll keep mining in this pool at least until we find a block...

How is that possible?

EDIT:
up to 176%, -32 shares
also pwner has no shares but 50% stale

already broken?

What is the answer to Life, the Universe and Everything?

I wanted a separate address for the forum, and it doesn't appear in the blockchain right now. Someone could help me with that 

Exactly what I meant.
You need some way to verify that the boot sector hasn't been modified. If that requires booting from an USB stick, it is no better than having your OS (or at least the kernel / disk crypto) on the stick as well.

Basically, bigger pool = more steady reward


As long as you're contributing the same amount of shares all the time, you will get the same amount of BTC regardless of round length.

By the way: in theory, it is possible to get full 50 BTC (minus pool fees) for a block if you happen to solve it with your first share before anyone else can get it 

I don't want to put a bitcoin address in my signature, it's just my username which happens to be too long 

OK, the Windows kernel is encrypted, but the same problem applies to TrueCrypt. You need to enter a passphrase / insert a USB stick, and someone could install a modified version of TrueCrypt that saves the key to somewhere (like the last sector of the disk, or NVRAM).

You will still lose BTC on average
4/5 * 1.2 = 0.96, and it gets more risky for 5x

The kernel has to be loaded from somewhere. Unless you boot from a CD or USB drive, it will be on an unencrypted partition of your hard disk.

If someone can get physical access to your computer, even Linux with encrypted hard disk is no protection. They could install a backdoored kernel that leaks your password.

You can actually restrict running cmd.exe using the software restrictions, but as I said this doesn't mean that another program you trust couldn't be hacked to do the same things.

Running as normal user should already block installation of drivers (rootkits do that). The only way to protect against "normal" trojans that could read your wallet.dat is restricting the programs you can run to a small set. You can do that from "Local security policy" by creating Software Restriction rules (by file name, certificate or MD5 hash).

Note that it's still possible that some exploit takes over a trusted program and reads out your files. Only safe way is to make an user account for Bitcoin only and don't use it for anything else.

Bitcoin addresses do not get "reserved" when they are generated, it is just astronomically unlikely to generate one that has been used before. In theory, you could keep generating new addresses until you hit one that has coins in it, but as SgtSpike said this would be much more difficult than finding valid blocks.

Try "Administrative settings\Local security policy" in control panel.
What version of Windows are you using, and what do you want to restrict?

Yes I haven't changed those defines yet, mostly added my own intermediate functions:


Since there is no noticeable drop in hashrate, I assume the compiler is inlining these functions.

Also, you can eliminate one extra assignment to Vals[4]:

Thanks, best version yet
Still not reached the 40 MHash/sec the wiki says my card could do  

Did you notice that Ma(x, y, z) is defined exactly the same now whether BFI_INT is enabled or not? Seems more elegant to me if moved out of the #ifdef. Also I tried to replace some #define's with functions, guessing that it would make it easier for a somewhat smart compiler to find repeatedly used terms and put them into registers. No performance improvement, but didn't hurt it either.

Also, OpenCL has a builtin Ch function, not faster for me but maybe for someone else:
#define Ch(x, y, z) bitselect(z, y, x)

You will need to install the APP SDK, get it here:
http://developer.amd.com/sdks/AMDAPPSDK/Pages/default.aspx


It's (supposed to be) a bitcoin address - I don't have a name  


does your user name or password contain "special" characters?
like <, >, &, |, \, $, #, ", '

if yes, put a \ in front of each such character, or the whole thing in single (') quotes

No, because if you have a trojan it could steal your password as well.


More important: How many MHash/sec can it do?