No, it will make the pool vulnerable to hopping based on pool hashrate fluctuations. It is more profitable to mine for the pool when the current hashrate is higher than the average over the current window.

Only if you assume people are willing to wait arbitrarily long for their rewards. The lower the pool's current balance, the longer it will take to get the full payout, and people will lose patience. Add to this the fact that people will fear the collapse of the pool, a self-fulfilling prophecy which will prevent ever getting the payment. When the pool is in the red, massive abandonment is a schelling focal point.

You might be interested in GiveWell, a site providing analysis of different charities.

In a nutshell, if an SMPPS pool with no fees runs long enough, with probability 1 it will eventually reach a point of such unluckiness that its payouts will be miniscule. Miners will leave and the pool will never recover. At that point miners with pending payments will never receive them. So, the claim that "you will get your due reward eventually" is refuted based on the pool's inevitable collapse.

First, defining the window in terms of units of time is bad. You need to define it in terms of number of shares.

But yes, I guess in the multiple-payment variant, you could make the window long. But this will also mean you'll have to make sure you're handling difficulty changes properly.

In the single-payment variant, the window must be less than the difficulty by some margin.

It needn't be a part of Bitcoin per se (in fact it could be part of a general p2p monetized data-sharing network). It's easier to see how it will be done with blocks - when a new block is found, miners will want it as quickly as possible and pay to the lowest asking node who has it (they'll need either trust between them or a trusted instant-payment intermediary). Nodes will pay for receiving it from other nodes based on how much they expect to gain from selling it.

With transactions it's harder to micromanage which node has what transactions, but this should be a solvable technical issue.

You all have missed the defining characteristic of true PPLNS, which is that it crosses round boundaries. If there are less than N shares in the current round, shares from the last round(s) are paid. For every block found, the last N shares (variant: which were not yet paid) are paid, regardless of which round they belong to.

Implemented in this correct way, PPLNS is indeed hopping-proof.

If you want hopping-proof without crossing round boundaries, use the geometric method.

IMO SMPPS is a bad method.

I have already addressed this concern.

Non sequitur. PPLNS has a valid variant where each share is counted at most once. We go back in history and pay the most recent X shares that were never paid. This does require keeping track of a longer history.

Anyway, there shouldn't be a problem with the multiple-payment variant. It just has some more variance than the one-payment variant.

Oblivious shares + p2pool network built on top of centralized pools = viable PPS with reasonable fees. I hope to see it one day.

Maybe I'm not getting it, but this looks to me the opposite of hopping-proof. Wait 10 days, if the pool has been lucky mine for it, if not don't.

First you need to remember that not all network nodes are necessarily miners. So even if transactions stop at miners, they can still propagate through the rest of the network.

I expect that as network traffic increases and requires significant hardware and connectivity investments, propagation of transactions and blocks will be monetized. So there will be an incentive to operate honest non-mining nodes, and maybe even miners will be incentivized to propagate in spite of the possible competition.

All valid points, but I think you're underestimating the impact of Bitcoin mining at least in some niches. E.g. Vladimir buying all 5970's in the UK (he's running a big mining contract service and I think he was serious with that comment).

Because of the myriad well-known disadvantages of grid computing? (Secrecy, protection against fake work, protection against tampering, communication overhead, need for a suitable platform for distributing the work, being at the mercy of end users who may quit at any point or not be convinced at all to join in sufficient quantities...). Bitcoin mining is very unique in its suitability for monetized grid computing.

They're doing fine without your Terahashes, thank you very much (and of course, they don't need literally hashes).

One which I (and surely others) have had for years. But like I said, for most application there are severe limitations for this kind of deployment, which I guess is why nobody managed to pull off something successful yet.

Empirical data over 4 days means very little. I'm not sure what you're arguing against but I guess "very low" variance is debatable. It is of course higher than proportional.

With PPLNS, variance is 0 per block for the operator and very low for the participants. Note that there is also variance created by the pool being too small regardless of the scoring method used.

You are in fact wrong. Both methods I mentioned give you the same expected return no matter when you submit shares or how intermittent your mining. In fact that's my definition for "hopping-proof" - that your expected payout per share is completely independent on when you submitted it.

However, for the geometric method intermittent miners will have even higher variance.

Anyone with the most basic knowledge of stochastic processes can see that SMPPS is a bad method.

There are two valid hopping-proof methods:

1. Geometric method. Cons: Requires implementation in logarithmic scale, has high (but tunable) variance.
PPS is a limit case of this.

2. PPLNS. Cons: Crosses round boundaries.

It looks like your RSMPPS is trying to take SMPPS and make it more like PPLNS. Better just use PPLNS instead.

(In case people mean the geometric method when saying "the cheat-proof method", please don't. "Cheat-proof" is an adjective, not a name. Better edit the thread I guess.)

Read the OP. Then make an on-topic comment.

Block finding is a non-homogeneous Poisson process with rate parameter proportional to the worldwide hashing power dedicated to finding a valid block. If it was homogeneous, time between blocks would follow the exponential distribution. The OP is suggesting that, due to the financial incentives of the miners in a post-minting world, the hashrate will drop after every block and gradually climb back, making the time between blocks distribution less variable than the exponential.

The effect will exist, but its strength will be less than you describe because:

1. Depending on the mechanisms that will be put in place to ensure inclusion in a block is a scarce resource, even after a block is found there will still be plenty of fees in the next.
2. Unless there's something else to compute, the decrease in profitability will have to be significant to pause mining, to avoid thermal cycles.
3. Some people just won't care enough about this to pause mining.
4. Even if the numbers are as you describe, instead of exp(10) we'll have 5+exp(5), which still leaves plenty of room for longer than average blocks.


They had better. But it's possible that in the future proof-of-work will be augmented with things like proof-of-stake so not a lot of mining will be necessary.

Yes.

We're hoping Bitcoin will succeed, which will inevitably cause its price to increase.


These days there are things called "computers" which can automatically halt the mining when a new block is found.

Propagating a block is supposed to take a minute tops. And this is completely irrelevant to the OP's point - people will mine on the old block, but if they find something their block will be invalid. Thus the finding of valid blocks will slow down.

He didn't say it will be completely predictable, only that it will be more predictable because it will no longer be a homogenous Poisson process.

Did you read the post? He explained exactly why this will change.

Send them another email.

This transfer already has a hundred confirmations, so that's not it.

Not every Bitcoin address in existence. Just those with a large number of bitcoins. And it needn't be for every block.

This is exactly why I say this should be used in conjunction with hashing. A small amount of proof-of-work provides the skeleton and protection against casual double-spends, while proof-of-stake provides an occasional rock-solid confirmation against massive attacks.


Nobody knows exactly how to prevent miners from including low-fee transactions, and hence, making sure people pay fees. Even if we figure it out, if we want transaction fees to remain low enough, there will be little incentive to mine, making the overall hashing capacity low. Thus the network will be vulnerable to attack, and people will not be able to safely send large amounts.

I see this as a major problem, which the inclusion of proof-of-stake, done correctly, can solve.

Another thought: Currently there's a problem with very large transfers, since guarding them against double-spending can take days (at least) of confirmations. Paying transaction fees won't help because it can only get it in a block faster, it can't significantly affect block generation rate afterwards.

With the new system (work/stake hybrid approach), senders of large amounts can include a signature fee in addition to the regular miner fee, which goes proportionally to stakeholders who sign the block in which the transaction appears. This will incentivize stakeholders to sign, making the transaction secure without having to wait for more confirmations.

This is vulnerable to attacks on the network topology. You can "fake" a Bitcoin node, you can't fake having bitcoins.

I need to look more closely into the current implementation though.