actually no... lol, ok, I c what u did there... or not!

upnp is internal, so only computers that are directly connected to the internet (without router between) are at risk... 50 million?!

lol, bitcoin talk is basically a big scam built around the best idea of modern civilization!

I love the contrast!

There is no configure file!

But ok, I resolved the boost dependency... but now it can't compile the db because suse 11.3 has berkeley 4.5 and bitcoin requires 4.8, so thats the segmentation fault right there I guess?

So is it possible to fix this?

Ok, compilation fails: http://pastebin.com/iVpPwnzQ

does this programmer have to know german?

@Meni: Thx, you gave me the last puzzle piece!

@nibor: I think thats wrong, your solominer will still request work and submit shares with the getwork api to/from the client.

but when does a share merit to be sent to the network? are there 2 difficulties: 1 for share to be sent, 2 share wins block?

EDIT: Btw it has to be binary, either send OR don't send share... AND either share sent did not unlock block OR share won block...

Basically: What decides if a share should be sent to the bitcoin swarm, there will always be getworks, but what changes is if they result in a share or not. If this is the difficulty, then what decides if a share "wins" a block?

Nope, not if the firmware is loaded by the miner and it can change algorithm on the fly. For example from SHA-512 to SHA-3, you cant make a ASIC for something you dont know what it is, but you can progam a FPGA to anything, as long as it fits the FPGA you are using...

I wish to build a new alt-currency with a firmware for spartan-6 that contains a new hashing algo (that should be evolvable thus eliminating the possibility to ASIC it). And build a really lightweight client with merkle root thin chain in java.

Yes, but what is the cryptographic information in a "invalid" share? How does the client verify a "invalid" share versus a "valid" (block unlocking) share?!?!?

Yes, you still "getwork" from the client!?

but shares are submitted even when mining against the satoshi client no? and what is a share that doesn't solve a block?

So last thing I don't get about bitcoin: Why do the miners have to send shares all the time and not only shares that solves the block? Cant the local mining software judge if a share has solved a block?

Ok, thanks! I think I get everything about bitcoin now!

But so there must be a chance in one gazillion that two private keys generate the same public key hash no?

so basically, when you create the address there is a private key created that is stored in the wallet? how are addresses created?

But how does then the addresses work:

1) I have 1Eu6P1eRSewoqf8GZcYoBtMtXG1865Umjh, it has never received any money. How do I prove ownership of this address? Why can't somebody just claim to own this address?

2) If I receive money on this address without having bitcoin client running, will that money just magically appear when I launch the bitcoin client in the future (IE is it the ownership of the address that is stored in the wallet or the transactions/coins?)

I'm thinking about transactions as atomic, so say you have 3x1BTC incoming on one address (adr1) and 2x1BTC on another (adr2) and 1x5BTC outgoing (payment), then the swarm know you have 5BTC (because they can verify the sum on addresses you have as 5?) does that mean you say "I holder of adr1 and adr2 now give ownership of 5BTC to address XXX and here is a public key to prove i have the private keys to adr1 and adr2"?

Ah, yes. But thats not the issue the issue is that since 0.6.xxxx > the client segmentation faults on suse 11.3, works fine on my suse 12...

No debug at all.

I was using bitcoin 3.2 which worked fine but lately it spins out of control and wears my SSD...