That could be interesting. I don't know if I'll have much time or energy to dedicate to this as I'm too tied up with my other projects. Maybe you should PM me with your ideas for this?

Close, I try to follow the Halakha where possible.

Sent.

That will not be needed.

Please repay to 13z3RpNEnSFd1JJS3eLz27dbn7aGEVd8Du.

Ok. I can lend 100 BTC at no interest. Please post receiving address.

Can you give anything to indicate your reputation/trustworthiness?

Use a pool with a hopping-proof reward system and merged mining, such as eclipsemc.com and yourbtc.net .

The point is to use a hopping-proof method, where profits depends not on the pool's luck in the past, but in the future (which cannot be predicted without being a prophet).

That's a very restricted definition of pool-hopping.

The point with gambler's ruin is that the gambler is eventually ruined even if there is no house advantage.


It looks like people are completely missing the point about what's wrong with SMPPS. To everyone who speaks about how profitable it was for them to mine in SMPPS when the buffer was positive / mildly negative - congratulations, you have successfully hopped the pool! Hopping is mining only when it is attractive. Of course mining in SMPPS when the buffer is positive is attractive. It's entirely possible that, after the successful start, you'll be able to keep mining well into a negative buffer before you hop away, and have an overall profitable period. You'd make even more profits if you optimized your hopping using proportional pools.

But the question isn't really what you will feel when the buffer reaches -10,000 BTC. It's about others who would consider joining the pool at that point. It would be silly of them to join this over other pools because the maturity time will be insanely high. And those who previously mined will also quit. And the pool will collapse. And that this is inevitable is built-into the design of the pool. I don't know when this will happen as this is random. It could be quickly and it could take decades.

Operators are dishonest if they offer a method which could collapse any minute. People who mine there now when everything's peachy with the intention to leave when things get rough, are plain hoppers which as I commented elsewhere I think is unethical. And those who keep mining even during a highly negative buffer are simply working against their own best interests.

And, as teukon implied - if SMPPS is safe it means that PPS can be offered with a low fee. And this is even more so if the operator makes a calculated risk assessment, raises the capital needed to have a sufficient buffer, and acts as a proxy to a larger pool such as p2pool.

The lie-in-wait block withholding attack certainly can help the attacker.

That's a common myth. If you've mined for 12 hours and no block was found, then in hindsight, you have mined all that time for nothing whether you drop out or continue mining. Your future mining has no impact whatsoever on what you get for the past mining done, you're faced with a new decision on whether the potential rewards for your future mining are worth it or not. In a hopping-proof method the profitability is always the same.

In the future, PPS pools won't be literally "specified payment per share", but rather "specified fraction of share's value per share". That is, pB(1-f) given immediately per share where f is known and fixed, p changes every two weeks and B is variable.

If the thermal cycle cost is higher than the electricity cost, and there are really no other profitable things to do, they will probably keep mining 24/7 after all.

The calculator can show you the average payment in optimal conditions, but there's variance based on the pool's luck and there are occasional problems. slush clearly explained that there was both a DDoS attack and bad pool luck.

There are many other factors that could affect your rewards, such as pool-hopping and various pool features. Paying for invalid shares is nice, but probably doesn't make up for the high fee and hopping.

AngelusWebDesign is right - assuming the payment is done as he described, and even though he did not articulate it perfectly.

If the round is old and the accumulated NMC reward is high, it is more profitable to mine.

No free lunch. If it's more profitable to mine in an old round, it means it is less profitable to mine in a young round.

I find it odd that with the current version one can't get the block reward. As a temporary measure until the new version I'd do one of the following:
1. If "Transaction fees are paid" is not important for the pitch, I'd just keep them.
2. If it is, base all score calculation on B=50. When a block is found, in addition to the payment specified by the method, pay the transaction fees for the block to participants in proportion to their score.

Yes, except that only the Merkle root of the transaction list is in the header, not the entire list.

Yes, if transaction fees are rapidly changing, the pool (and, in a proper scoring method, the miners) are incentivized to work on an up-to-date header with higher fees. This should be balanced with the resource cost of frequently pushing work.

I think you're talking about SMPPS which is completely different from PPS. And no, that's not the main problem with either.

SMPPS is a broken method as I discuss in Analysis of Bitcoin pooled mining reward systems (work in progress).

If you really don't want variance use a true PPS pool, though I don't think there are any good ones right now. Also check out Summary of mining pool reward systems if you're shopping for a reward system.

You should emphasize that it is the average profit per time that is the same. All else being equal, larger pools have the advantage of less variance.

One bitcoin has 100 million units (which can be increased with a protocol modification). The 210 trillion figure was the total number of units in all coins for a hypothetical scenario where 90% of coins are lost and there are 2.1 million coins.

Great news!

A service that charges 20% extra doesn't count.

That's what we're doing already. You're welcome to join.

Of course the transactions should be recognized by the Bitcoin network, otherwise there's no point. I'm not completely sure of the existing and planned possibilities, but I think referring to time (or at least block #) being at least some value is a planned feature which opens a whole range of applications.

When everything is normal coins are spent by signing a transaction with both the server's and the client's key. Only in case the service provider goes belly up clients need to wait for its key to expire, and instead of "year" it can be any other time. But clients will need to make sure to extend the expiration (by moving to a new address with a different target time) when the target time is reached. The coins are still (relatively) safe even if the server's key expires, it only means transactions aren't instantly verified.

Every transaction output specifies a script to be executed in order to validate spending this output. Currently everyone just uses the script "supply a signature with a private key whose public key's hash it address X" - this is what the "OP_DUP OP_HASH160 2799cee55ec84f57ee76b27f4e0aa9e64cad533b OP_EQUALVERIFY OP_CHECKSIG" bit you can see in blockexplorer means. But they could just as easily specify "supply two signatures, one for address X and one for address Y". With OP_EVAL that's even simpler - everyone will just use the script "supply a script whose hash is address X, and data which makes it return true", and then when spending the coins the script that requires two signatures will be specified (though it has to be known a priori to come up with the address). With the date the supplied script will be "supply two signatures, or just one signature if time is > October 2012".