I addressed this in my comment.
Coins will be spendable if ( (server sig and client sig) or (client sig and time > October 2012) ). If the server vanishes, clients will wait a year and then be able to reclaim their coins. Server unreliability can still be a nuisance though.

Great idea. A few improvements though:

There's no reason the client should send the private key to the server. You can make bitcoins that are spendable only with digital signatures from two private keys (and with OP_EVAL, you can do it transparently as a normal Bitcoin address). So the client only needs to send a digital signature for the requested transactions. This eliminates any risk of the server stealing coins.

I think you can also make it so that the coins are spendable with just the client's key after a specified time. So even if the server loses his key, the clients can reclaim the coins after this time. If everything is fine, the time arrives and the clients wish to continue using the service, they move the coins to a new address with an updated time.

Yet more proof that all the supposed "problems" with Bitcoin are solvable with its incredibly powerful and flexible architecture.

It looks like https://btcex.com/ has an API.

Will you add a feature to automatically convert the NMC balance to BTC?

You could make a daily job that sends the NMC of everyone with the option selected to an exchange, withdraws, and distribute the earned BTC in proportion to the namecoins taken.

The "privacy from governments & banks" bit will probably alienate a hundred times as many people as it would attract.

The green line is how many coins were generated every day.

The blue line is how many coins were sent to some address in a given day and hasn't moved up to the time your cursor is over.

Both quantities are divided by 144, the average number of blocks per day.

For example, if your cursor is over July 15, 2011 and the blue line over March 15, 2011 is 100, it means there are 14400 bitcoins that were transferred on March 15, 2011 and either did not move since or moved only after July 15, 2011.

Nice graphs. Some smoothing will make them more informative. A Gaussian kernel would be best, or you could just change the bin size to 60 minutes 3 days or something (I assume it's now 1 day?).

The approximation only holds for sufficiently large n and m. So you can't use it directly to find the probability of quick recovery. But you can do it in reverse. For example, m=10, n=1000 gives a probability of 25.2% that it will take at least 1000 rounds to recover from -500 BTC, which means probability of 74.8% to recover within 1000 rounds. While m=20, n=1000 gives a probability of 50.4% for at least 1000 rounds, meaning only 49.6% probability of less than 1000 rounds.

Yes, Brownian motion is pretty crazy but quite a lot can be said about its dynamics. For example, over a period of n rounds the buffer will change in an amount on the order of sqrt(n) times the block reward. The probability that it will take at least n rounds to recover from a negative buffer of m times the block reward is roughly (m/sqrt(n))*sqrt(2/Pi). (From which it follows that the expected time to recovery is infinite.)

The pool has no problem surviving as long as its buffer is high - in this case the distinction between it and PPS are blurred. If the buffer is currently positive but on a more earthly level, people are signing up for a pool which is by design doomed to failure (even if it will take a while for the failure to actually take place).

Chapter 4 (*MPPS) is done.

Education / information resources. Currently someone who learns about Bitcoin can't get clean, concise, accurate information. The wiki might be the proper venue for this but currently leaves a lot to be desired.

Blockchain proof of work needs to be hard to come up with but easy to verify. Captcha solutions are as hard to verify as to find, and a captcha problem can't be generated without the generator already knowing the solution.

In theory it's possible to distinguish. In practice a good PRNG with a not-too-long truly random seed can fool pretty much anything you throw at it. In other words, much harder to verify randomness than to generate it.

Also, Intel IVB will have integrated "digital" true RNG making randomness generation easy.

I think it has something to do with falling for the myth that score-based methods penalize intermittent miners, then starting a holy crusade stating that any method is good as long as it's not score-based. And, the vulnerabilities of SMPPS are different and subtler than of proportional.

Actually a shift system can work. I've discussed here how to do it correctly.

Oh, it's reduced all right, in a sense. The hopper can't get more than 0-fee PPS out of it, and the honest miners' losses depend on the long-term dynamics and usually come in the form of increased maturity time rather than reduced expectation.

I'd say fixed-N PPLNS is good enough in practice. That opens up quite a few options, such as MMC. And you have some great, even if small, double-geom pools such as EclipseMC and yourbtc.

Sorry, making up new probability laws is beyond my powers.

That's exactly the thing I said shouldn't be done. The correct way is much simpler, it's to use the block reward of the share itself. That is, the share is a hash of a block header you hand out for the getwork, which has a merkle root of a transaction list with a given total transaction fee, which together with generation is the total block reward. That's the value of B which should be used for this share.

This part I like...

This part I don't like. What's the point using a hopping-proof method and then adding a hoppable feature?

The method handles transaction fees as is as long as you determine B correctly. It needs to be the total block reward corresponding to a share's getwork.

You can add namecoins by having separate Bitcoin Score and Namecoin Score, where the namecoin reward according to the method is converted to bitcoins before entering the confirmed balance.

And, the solutions to the problem are much better understood now. You have p2pool (which can be used as a variance-reduction substrate for small pools), and there's been discussions of pools accepting shares constructed by the miner as long as the generation transaction credits the pool.

To the extent that this is true, that's exactly what the ado is about - that there's a large bulk of miners who harm network security instead of improving it.

Summary of mining pool reward systems
Analysis of Bitcoin pooled mining reward systems (work in progress)

You yourself made the error of including SMPPS in a list of "hopper proof" methods.

Lie-in-wait. But no, assuming the attacker has no posterior knowledge of future blocks and that the atomic action is finding a share and submitting it to a pool of choice, double-geom and unit-PPLNS provably cannot be optimized.


SMPPS was "designed to be hop-proof" by someone who hasn't got a clue what he's talking about. I've explained why it's broken until I went blue in the face ever since it was spawned.

Way ahead of you, see links above.

You can change the parameters, but you'll need to either modify the scores or using an invariant scoring in the first place.

No it's not. To be absolutely solid you need to use the "unit-PPLNS" variant (to which I refer in my PPLNS post simply as "the correct method").

The correct way to end a PPLNS pool is to immediately pay out the expected values of outstanding scores.

I don't think that's true. slush and SMPPS should be avoided. ESMPPS might sort of work out ok. There are very good hopping-proof methods so there's no justification to settle for anything less.


Shared Maximum PPS.

Please don't.

Or at least make it as described - beneath the first post in every topic - rather than the first post in every page as it is now. That way it will kind of make sense separating the OP from the discussion.

I am, you're probably not looking hard enough. And not interested enough in mining pool reward systems, which is generally my primary area of contribution.

Which thread? Is a link missing?

In case you're not already in the loop, there's been some discussions about extending the scripting language used for transaction verification and modify it to allow scripts to be transparent to senders (example). I'm not at all in the know what's going on but it's possible this can be accomplished with the right script.

PS I've been thinking about the same thing for a long while.