It's about 80% rhetorical. I don't know the first thing about web service administration and I'm not qualified to make any assertive statement.

Is it really a good idea to have the pool and the website on the same server?

That's what I said. runeks asked why isn't the period longer. I answered that inflation will become lower faster with a short doubling period.

Of course it can't be too short because there are disadvantages to that.

Yeah, that's what I call "the hopping immunity theorem". I'll add a proof in AoBpmrs as soon as I determine the most general conditions under which I am able to prove it.

A bit off-topic isn't it?

I used to be an algorithm researcher in a small internet startup. I recently moved to a 20%-time position there so I can focus on Bitcoil.


This, by the way, is my 1000th post.

Chapter 7 is finished.

Pool ops, please pay special attention to section "Score cashout". It describes a nice pool feature which I think shouldn't be too difficult to add.

To be sure, this isn't yet practiced. Eventually it will happen, so it's silly to say pools are a security risk going forward.

Pool ops don't typically make mining software.

They don't have to. It's more important that developers of mining software care.

And eventually, this probably will be small pools with a p2pool backend.

Right.

This won't work. Just because an address never received coins, doesn't mean it's unused. I could have posted it somewhere. If the client picks this address when I expect a fresh address, I'll be using the same address for two purposes.

No, that's not how it works. In step 3, funds are received at address A but the currently selected address is B, so the client does not move another address from the keypool. Compare this to the following:

1) I have address A in my wallet, B-Z in the keypool.  I make a backup.
2) I receive funds at address A, wallet moves address B from keypool to wallet (wallet displays address B as "your address").
2a) I go to the address book, click on address A, and click "Ok". (wallet displays address A as "your address")
3) I receive funds at address A, wallet moves address C from keypool to wallet (wallet displays address C as "your address").

So it's not that foolish, because the problem you describe won't happen in most use cases. If the user posts address A somewhere (say, in his mining pool) and keeps getting payments, pretty soon address A won't be selected so no more addresses will be used. However, if the user hands out the address to different people, and each time he uses the addressbook to copy it, then there might be a problem.

Note also that I didn't look under the hood to see what happens with the key pool itself. I only know that new addresses are added to the address book in the occurrence I mentioned - but obviously these are taken from the keypool.

Do I need to repeat myself? The client "generates a new address" (or, more technically, takes an address from the keypool and adds it to your addressbook) whenever a transaction is received into the address currently selected (the one displayed as "Your Bitcoin Address"). If you receive 100 payments into the same address, and after each time you go back to the address book and select this address again, then each time a new address will be generated, and eventually new addresses which were not in the backup's keypool will be created.

We can try it if you want. Select some address from your addressbook so it is displayed. Tell me what it is and I'll send a token amount to it. Watch as a new address is automagically generated.

It is 4 years.

The reasoning behind only 4 years is that what Satoshi really envisioned is a stable monetary base without inflation. Some inflation at first is necessary, but he wanted to "get over with it" as quickly as possible.

That's a myth. It's possible to have large pools without them having control of the blocks, and thus, without a security risk. Also there's p2pool.

That's not what it does. It's on a spectrum that has exponential-PPLNS on one end and Geom on the other, but it doesn't just pay out a convex combination of the respective rewards.

That's not really it. You can use any decay function (and linear decay gives the best variance/maturity tradeoff). But you must maintain a steady state with some combination of round crossing and correctly tuned variable fee. Suppose you take the geometric method, in which the operator's score is specified as 1/(r-1). If you choose to make the score any less, you incentivize mining in young rounds; if you make it any higher, you incentivize mining in old rounds; only with this exact score the profitability is always the same.

There's nothing wrong with the decay in proportional. It's equivalent to exponential decay with r=1. If you do this with infinite score fee and correspondingly infinite negative fixed fee, you get PPS which is hopping-proof. The problem is that people try to use it with 0 score fee.

That's not true. The client uses a new address from the keypool whenever payment is received to the currently selected address. So if the user receives 101 payments all to the same address, but he keeps reselecting that address so it is displayed in "Your Bitcoin Address", the keypool will be exhausted. This should be added to the list.

I think you meant "change".

In its most general scope, "hoppable" means the relative attractiveness of mining for a pool is different at different times. If the block reward is fixed, PPS isn't hoppable. When block rewards are variable (which they are to some extent now and more so going forward), the attractiveness is measured relatively to the momentary block reward. If a PPS pool literally offers a fixed pay per share, its attractiveness relative to the block reward is constantly changing, and it becomes hoppable - you mine there when the rewards is more than the solo average, and mine elsewhere when it is less. Now it doesn't matter, but in the future a correct PPS pool will always offer a reward of (1-f)pB per share where B is the block reward at the time it was submitted. Other hopping-proof methods can also adapt to this new reality by incorporating the current block reward into the share's score (at the cost of additional variance for the operator). By implementing this now, yourbtc is indeed less hoppable than the currently implemented PPS. (I'm not sure how it is in EMC. I don't know if I emphasized this point when we corresponded about the scoring.)

See also section "Variable block rewards" of AoBpmrs.

PPLNS isn't the only hopping-proof method. As you can see in section "general unit-based framework" of AoBpmrs, a hopping-proof method can either cross rounds, include a variable fee, or both, and have either exponential, step, or any other decay. Exponential decay is far from poorly-informed - it is the only decay that allows encoding the score with a single value.

The problems with slush's method aren't that it's exponential - it's that it's temporal, and that it has neither round crossing nor variable fee.

You don't take some of your compute power away from BTC and into NMC. With the same computation you solve both BTC and NMC blocks. That's why it's called "merged mining". You get the same BTC and bonus NMC, which is why everyone is excited about it.

For a technical explanation of how it works you can read this stackexchange answer.

Yes. (You can use the "members" button to search for members by name).

http://www.jjgames.com/ offers 5% discount for Bitcoin payments.

Thanks, much appreciated!

My curse is that I know what's important and what's not. What we've done here is a nice exercise but it's not important, because A) the effect is tiny and B) This only happens in temporal methods like slush's pool. I don't like it when slush's pool is subject to false criticism but I never recommended using his method, it has several problems and it's known that this is one of them. This simply cannot happen in hopping-proof methods where the average reward really is equal to the total worth of work submitted regardless of pattern. (Though I'm not talking about things like stale shares, invalid blocks, pool downtime etc. which have nothing to do with the reward system.) The geometric method is what slush's method would have looked like if it was done properly.

Well, seeing as my results before the edit were completely nonsensical, maybe they shouldn't be trusted too much . In my defense I did disclaim I hadn't taken the time to verify this properly.

Yeah, I doubt you'll be able to simulate properly such small differences. Also maybe there's a difference between slush and PPLNM, and maybe there are additional discrepancies in the scenarios we've looked at.

I don't know why people believe that. FPGA is a jack of all trades which can be taught the trade of hashing. The future is custom ASICs.