This is brilliant. Of course there's still a lot of work to figure out if it's technically feasible and resistant to manipulation, concentration of power etc. But it could solve a lot of the problems Bitcoin will face going forward.

This change is significant enough to warrant a new genesis block rather than forking the current chain. This leaves the problem of initial distribution. Mining serves the purposes of both transaction validation and initial distribution, so if validation rights depend on current possession it will obviously be problematic.

I think this will work best together with, rather than instead of, hash-based mining. Blocks are confirmed with hashing as normal; this is enough for casual double-spend attempts. When a block is old enough, stakeholders can sign it. If a major attacker tries to build an alternative branch, clients will reject it because it conflicts with a branch already signed by stakeholders. This will create a much lower mining requirements for a given level of security.


I'll go as far as saying that if this pans out and is indeed novel, you deserve a place right next to Satoshi in the annals of Bitcoin.
(Edit Nov 28 2013: I retract that last statement... Sure, it's a great idea and all, but a place in the hall of fame requires a bit more than that. Also I'm not sure how novel the idea really is.)

I don't think it's possible with the GUI. But it should be doable with the API (see this for example. Call getnewaddress in a loop and dump the returned values to a file). I don't know much about this myself though.

Unless something fishy is going on with the larger pools, it just means the smaller ones were lucky during that time. Smaller pools have higher variance, which means you're more likely to get payouts significantly more or less than the average. But the average is the same.

What could that mean? Generally the higher the better, and EMC is tiny.

I went back to slush. Passable scoring method, low variance, simple worker monitoring.

[Edit: The following should be correct for MPPS.]

It isn't any good if you ask me. Sure, if you make an oath to mine for eligius forever until the end of time, it will even out eventually. But if you just want to mine for it for any limited amount of time, the odds are against you.

If you mine for such a pool for the duration it takes the pool to find on average 1 block, you get a penalty of 1/e on average, so your expected payout is only 63.2% of the average in other methods. If you mine for the duration of finding on average L blocks (where L is an integer), your penalty proportion is exp(-L)L^L/L!, which by Stirling's law is roughly 1/sqrt(2 Pi L). So for L=100 your average penalty is 4%.

Given that pools are supposed to drastically decrease your variance while having insignificant impact on your expectation, I find this reduction in expectation, or alternatively the long-term commitment, unacceptable.

Edit: Actually, I'm still not sure how exactly MaxPPS works. Whatever it is, though, I suspect these calculations are at least approximately true.

[Edit: The following is for SMPPS]

Reading the more detailed description it looks like it doesn't work like I at first thought. It looks very difficult to analyze, which is why every time I try to think about it I come up with different conclusions. However, according to my current understanding it is doomed to failure. What will happen is this:
The pool balance (total earned - total owed) follows Brownian Motion.
Which means that it will reach any given level with probability 1.
So at some point the balance will be deeply negative.
So any newly submitted share will receive only a fraction of the expected payout.
Seeing this, miners will leave to greener pastures.
This will slow down the recovery, until everyone is fed up with it and the pool collapses.
Everyone who still has a pending reward will never receive it.


Note that there are several perfectly valid hopping-proof methods. PPLNS is hopping-proof and has less variance than the geometric method (mine), but it involves the extra complexity of crossing round boundaries. It has two variants, with or without double-counting shares.

Thank you for taking the time to incarnate the scoring method. It was a pleasure while it lasted.

Have you considered taking a fee for the pool? Maybe something like f=c=0.005 (1% average). I don't know if many people would mind, and it might make it worth your while even without participating yourself.

Not PPS, "proportional". PPS = Pay per share, which is completely different (and immune to pool-hopping).

Makes perfect sense to me.

Did you try deleting Bitcoin's application data folder?

No, that's not how it works. The customer can't broadcast a transaction if he doesn't have the funds available. The default software client will not allow him to double-spend coins. The only problem is if he deliberately tries to double-spend with special-purpose software, and even then it's not trivial to pull off.

The Bitcoin protocol specifies that the longest branch is the valid one. Thus an attacker having the longer chain can decide which transactions are to be included in it.

And I thought we already said that this allows disrupting Bitcoin commerce, for:
1. Damaging Bitcoin for political reasons.
2. Profiting from shorting.
3. Other stuff.

My numbers are not wrong, they just relate to a different attack from what you have in mind. I was talking about building up an alternative branch starting from the current block, without releasing blocks during construction. After about a week, the honest network will have on average 1000 blocks while the attacker will have on average 1083 blocks, and with high probability he will have more blocks.

SRS. It's no surprise what happened to you, because you used your password daily it never entered your long-term memory (at least that's what some theories say).

You can have two encrypted copies of your wallet, each with a different password, and memorize them both. If you forget one, chances are you'll still remember the other. You can even use an SRS which hashes your input so you won't have to keep the passwords stored on your computer.

Everyone calculates it based on the same block chain. The protocol specifies exactly how the calculation is to be made.

Not really. With 67%, you can reverse 1000 past blocks in a week. Reversing 1000 future blocks takes a week with 52%.

For starters, he can create a new branch with none of the transactions from the last 1000 blocks. Or he can bypass X% of blocks as per your original post, which is not very dangerous for merchants but will piss off miners who wish to be rewarded for the blocks they find. And so on, he can get creative.

Assuming a consensus can be reached not only about which chain is the real one, but also that discarding the computationally longest chain in some circumstances is desirable.

I think Bitcoin can survive this happening once. The problem is if there is a reasonable expectation of it happening again. That's why the possibility of repeating it scares me.

Personally I mostly fear the following scenario, which anyone can do at home (if he has a billion dollars lying around):
1. Short lots of bitcoins.
2. Build a huge mining cluster and completely mess up the block chain.
3. Watch prices drop as panic ensues.
4. Profit.
5. Lather, rinse, repeat.

dat, not bat. On Windows it's in the application data folder (it might be hidden by default).