It's possible your client is still downloading blocks. If its status bar says "X blocks" where X < 127913 then that's it. It can take a few hours or a day to finish, after which you'll be able to see transactions instantly. How many connections do you have?

I noticed now that my comment may have been a little ambiguous - to clarify, I was referring to getting statistics from continuumpool.com, not to the miner flags.

Did you try it without pps? This should help narrow down the problem.

I hope you have carefully evaluated the risks of PPS due to sabotage as well as normal variance. Tycho takes 10% for a reason.

Also, does "overall hash rate" include PPS miners? It would be more useful to know the hashrate of the score-based so we can know its variance.

I don't know if that's the problem, but I noticed that when I copy-paste my address I often get a stray space which causes it to be unrecognized.

Note to martok - trim spaces from the input.

1. Yes, with a fairly simple modification of the protocol we can allow bitcoins to be divided to smaller parts.
2. Governments might, if they so choose, prevent people from openly using Bitcoin, but they can't prevent it from being used at all.
Difficulty is regulated automatically by the network via an algorithm.
Bitcoin is an open source project. It doesn't have a developer, it has several developers all over the world, and anyone can become a developer if they so wish. So Bitcoin will survive a manhunt against all current developers.

Look at my quotation of your post, I've corrected most of the English mistakes.

I calculated $2.5 / month for 4 MH/s. And again, that's just an average, it's not a steady payout. When mining solo (eg with the client) you only get anything when you find a block which is completely random. Due to difficulty increase, it is almost certain you will never find a block.

6 years. And no, I'm not kidding, with your CPU (assuming one server) I don't think you'll make more than 10 MH/s, which at current difficulty takes on average 6 years to find a block of 50 bitcoins. And of course by the time 6 years pass difficulty will increase, so you will probably never see even a bitpenny from the client.

With a CPU miner connected to a pool, rewards would still be measly but they will be spread out, meaning you will at least make some fraction of a bitcoin.

Yeah, the wiki is down.

This is Kiv's GUI version of poclbm.

This seems to be a miner good for CPU.

I think this indeed works. Your payout for a submitted share only depends on the future and not the past, so you can't hop. And it has a significant variance advantage over the geometric method. However:
1. You need to base the window on number of shares, not time. Time-based methods are a mess and open to hashrate fluctuation attacks.
2. You'll need to decide what to do with a short round when the pool starts, and there are no previous rounds to draw on. You could let the operator take the leftover, or distribute it between the shares (thus creating an expectation bonus early in the life of the pool).
3. You'll need to figure out how to make the payout invariant to changes in difficulty (should be doable).
4. You'll need to handle the case of changing the window length and fees. With other methods, each round is self-contained so you can change parameters between rounds. But here, a contingent future change may affect the current expectation.

You should also consider the reward system used by every pool.

72 hours isn't enough, certainly not with any of the smaller pools.

Did you forward port 8333? This should get you more connections.

poclbm, which also has a GUI version. You'll also need a mining pool like Continuum pool (and a GPU). There are also CPU mining software, a search should unearth them.

It looks like the wiki is currently unavailable.

This got me thinking:

1. Is it possible to have a website hosted in a peer-to-peer way?

2. Assuming a point of contention will be who decides the content of the website - what if it's a wiki, and proof of work is required to make edits?

These probabilities mistakenly assume that the attacker always builds on the last block.

However, the attack is, as satoshi discusses in his paper, to pick some block to build on and stick to it. If X>0.5 you can cut a branch however long you want, given enough time.

For example, if X=0.6 and you want to cut 10 blocks, after some time period the attacker will find 33 new blocks while the honest network only finds 22, making the attacker's branch win.

The calculations are correct. 0.001 (actually it's closer to 0.002) is the expectation, while 1.73 is what it would be if it's very lucky and the round ends now (remember, on average 430000 more shares will be introduced before the round ends).
Come to think of it, unless you make c higher (decreasing variance for participants), I don't know if the expectation for already submitted shares is such a useful measure.
Can you tell me the hashrate of this worker and how long it has mined before this evaluation?

Is it possible you've used lastscore instead of lastlscore?

If that's not it, can you post the values of

rd.f
rd.c
p
rd.b
lastlscore
sum(exp(lscore-lastlscore))
(1-rd.f)*(1-rd.c)*p*rd.b*sum(exp(lscore-lastlscore))

https://en.bitcoin.it/wiki/Block and https://en.bitcoin.it/wiki/Block_chain have some additional information. 100 confirmations means 100 blocks in the chain on top of the block in question.

For one thing, the number of merchants that accept Bitcoin is steadily increasing. Have you looked at https://en.bitcoin.it/wiki/Trade ? I'd say the list is quite impressive by now.

Also, merchants can accept bitcoins even without having faith in the currency. They can programmatically sell them for another currency whenever they make a sale, treating it merely as a superior money transfer mechanism. Because of its advantages it is only natural that more and more shops will accept it.

Note that to help understand how the scoring algorithm works, you would need to post it in linear scale.

Since you wrote it in log scale, it really serves the purpose of helping understand how to implement it in a numerically robust way.

+1. This is definitely the program you want.

I think this was already implemented. -i flag sets the GPU to be used, and you can get the ID of all GPUs with -h or something. I've used it successfully with 2X5970.

1. You need to hand out a different Bitcoin address to every customer, maybe even for each transaction. Keep a log of which address is associated with which details.
2. Not that I know of. PayPal has hassled people who use it to exchange BTC for other currencies.

The model you've analyzed in the paper is continuous and does not take into account share granularity. If p=1/difficulty and you submit to a proportional pool the very first share in a round, you'll note that your expected payout is $\sum_{i=1}^{\infty}p(1-p)^{i-1}\frac1i \approx -\log p$.

However, you are correct that I have not taken into account that you will also need infinitely many blocks for this. So what we can say is: With perfect hopping, you can get X13, but not continuously - rather, you run your miner only when a proportional pool has a new round, which will give you the measly volume of 1 share per block found by a proportional pool. This result is of course of no practical significance, but generally analyzing intermittent mining may be important if electricity is a large portion of the cost.

With a correct choice of parameters, the variance can be acceptable for both the operator and the participants.
At current difficulty, with c = 0.00015 and f = 0.02-c, you get 2% average fee and a variance reduction of X133 for both operator and participants, compared to having the same payout mining solo. This isn't bad.
If you want to give up a little hopping-resistance to gain a little variance-reduction, you can decrease the operator's score for a given r. slush basically reduces it to 0 and thus has only a little resistance, but you can find a better balance.
But the decay based on shares rather than time is a pure advantage which should be adopted even if score fee is eschewed.
I don't know where you got the part about huge fees.