No. The efficiency is (total reward)/(total value of shares submitted). They do not submit any shares to <0.435*D rounds (by assumption these rounds take 0 time) so these rounds don't add to either the numerator or denominator.

The appendix calculates the average reward for every share submitted (by considering the reward in a random time), not for hypothetical shares which were not submitted.

Think of this. Let's say you're mining in some pool (doesn't really matter if it's a fair or proportional pool). Suddenly a Exahash/s miner joins the pool and in a split second finds 1000 blocks, then leaves. Do you lose anything from these 1000 blocks you had not chance to submit work to? No, you didn't do any work in this time and didn't get any reward, it doesn't affect you at all.

That's a myth. PPLNS and score-based are perfectly fine for intermittent miners, their average reward will not be affected.

The only countermeasure is using a hopping-proof method like PPLNS, geometric and double geometric. Other proposed "countermeasures" generally hurt honest miners more than they do hoppers.

For correct information about reward systems, please see Summary of mining pool reward systems and Analysis of Bitcoin pooled mining reward systems.

Can you specify which client you're using? In the default GUI client change addresses don't appear in the list of transactions so you're not supposed to care about them.

At the cost of a bit of privacy, can you post the address in question?

Yeah I have those too . My TH referral code is actually a special partner code which is better (for me) than normal codes. That's moot since nobody has used it in ages, I keep it for now mostly to show support for TH.

My volume recently has been too low even for "low profile" standards, so I can safely try to reach out a bit. Anyway I'm making a slow but steady progress on the legal front.

Google ads works great for this, because if someone is in Israel and searches for "Bitcoin" I'm almost 100% certain I have something to offer. Problem is, there isn't much relevant search volume. I did a campaign before to test and now relaunched it indefinitely, so expect to keep seeing those ads...

It's in my signature and you've seen me before, do you disable signatures or just don't pay much attention to them? Also my avatar is Bitcoil's logo, symbolizing it is a blue-and-white Bitcoin (exchange) service. It's also in some mandatory places like the wiki. Also appears in organic Google results for "Bitcoin ILS", "Bitcoin Israel" and "ביטקוין".

Anyway, I'm not sure how people miss this service but I know they do, hence the Google ads.

It is, you're welcome to use it!

That's interesting, whenever I checked I had never noticed such a significant difference. But I checked now and indeed there's some 10% discrepancy (why doesn't anyone arbitrage this? The depth isn't huge but I'm sure they could make a nice profit).

The reason for using Tradehill is that we were supposed to start a partnership (which we've postponed due to legal reasons) and we're amicable regardless of any partnership, so it would make sense to use them for backend trading etc. Now that I see the difference can indeed be significant, and seeing as customers would probably expect an mtgox rate, I'll probably switch to mtg rates.

This is probably a change address. It's a feature.

Electronic voting requires two steps.

1. Assign a unique cryptographic identity to every eligible voter.
2. Collect votes of all cryptographic identities with some protocol.

Cryptographic voting protocols for #2 with good properties already exist (example), and Bitcoin, which was designed to do something else entirely, brings very little, if anything, to the table. For #1, as long as voting eligibility relies on some meatspace attribute, you'll need a meatspace interaction to make the assignment, no sort of fancy technology can change that.

I pledge one 1 BTC coin and one broken 1 BTC coin.

AFAIK the PRNG uses serial numbers on the hardware components, so even if the two computers have the same configuration, they will generate different wallet addresses and extraNonce.

The CIA don't come to Bitcoin conferences, they just invite the Bitcoin lead developer to talk.

EMC uses c=0.01, o=0.99 which means there is very little reduction in pool-based variance. In AoBPMRS I've only done Geometric so far, not DGS, and anyway I've only calculated share-based variance - deriving pool-based variance is much harder.

Thanks. Most of the content of section 6.2 actually goes back more than half a year. PS the lie-in-wait attack was named by me and I'm the only one talking about it, but I didn't invent it, I picked it up from a comment on slush's pool's thread.

Thanks!

Chapter 6 done.

The idea isn't new and if there's a market for it it will happen. I think this will be obviated by split-key wallets as discussed for example in this thread.

Why do people keep making up these things? There are reward systems which actually work, why not use that instead? From their site - "anti-cheating score system punishing pool-hooping cheaters" - the fact that they think pool-hoppers should be "punished" (rather than simply using a fair invariant method) or that their method does this with any effectiveness, demonstrates they don't know what they're doing.

It may be "resistant" to changes in hashrate and difficulty, but not immune. It has a different variance/hopping profile from slush's, with at least one significant disadvantage - the profitability has no lower bound for arbitrarily long rounds.

Probably should be (total submitted shares*exp(C))/(C).

I disagree. A fee should also be taken for the risk. It doesn't have to be a high fee if planned properly.

Yes, that's basically it. With more miners there's more money passed around and more to lose if the pool gets unlucky. More formally, the variance of the number of blocks found is proportional to the hashrate. But the relative variance is inversely proportional to the hashrate, so with proper planning more hashrate is a good thing.

What you're missing is that there are many correct solutions. The block header is 640 bits (some of them can't be easily controlled, but never mind that) so there are 2^640 potential solutions, which is indeed virtually infinite. Of those, there are 2^608/Difficulty correct solutions. So people still have a chance to find a correct solution (1/(2^32*Difficulty) per hash), but no chance to test the same solution someone else did (if they're randomizing properly).

Pools aren't "more efficient" in the way you mean. The search space of solutions is virtually infinite, so there is no chance of people duplicating work even without any coordination. Basically miners are trying random numbers until they get a hit, whether they're mining pool or solo. The average number of blocks found by a miner is the same in both cases.

What pools do is reduce the variance in a miner's payout. I discuss the basics of this in chapter 1 of Analysis of Bitcoin pooled mining reward systems.

Not if people properly set up failover pools. And other current problems of pools with respect to network robustness have solutions which will be implemented in the future.

Volume is very low, but I have my hands full ironing out legal, technical and banking issues, as well as marketing and Bitcoin project development.

Sent you a PM about integration. Will be great to meet you when you're in Israel.