Geometric has higher variance than PPLNS. This is its well-known weakness, and is why I now recommend that people use either double geometric or PPLNS. I'm not sure if you understood me but my point was that with PPLNS you cannot "inconsistenly mine" and effectively have to treat it like the scoring method so in the end, you may as well use the scoring method (and inaba should just scrap the pplns pool entirely imo).
This is a myth. You most certainly can mine inconsistently, and your payout will be on average just like with PPS/solo. Your variance will be higher, but PPLNS doesn't have a lot of variance so you won't have a problem. |
|
|
|
|
Are there any pools which offer PPS payments to miners, but don't generate work themselves, but rather forward work from another (non-PPS) pool?
This has the same relation to operating a normal pool, as joining a pool is to solo mining. If the backend pool is larger than the frontend pool, it significantly decreases the frontend's operator's variance, thus allowing him to safely offer low PPS fee.
This isn't very scalable (at least until there are larger fair pools), but can be a good bootstrapping option. It also works if the frontend and backend are operated by the same person, on the same server.
What are the technical challenges in implementing this?
|
|
|
|
this community, which is nothing more than a bunch of get-rich-quick maggots looking for a free ride.
...
like the shit-headed Bitcoiners
...
the disgusting profiteering and speculation of Bitcoin
I thought you were someone else. I get it now. It is unfortunate that you do not appreciate the visionary revolutionaries that drive Bitcoin. I don't need to listen to these insults. I have very little faith in your ability to understand and solve the challenges Bitcoin is facing. I still don't understand why you refuse to publish your design, and I can only assume that it is because it does not live up to the expectations. |
|
|
|
It's this total de-emphasis on mining that I think totally negates the possibility of my design catching on with this community, which is nothing more than a bunch of get-rich-quick maggots looking for a free ride.
It's not supposed to catch on with the Ixcoin community, it's supposed to catch on with the Bitcoin community. Anyway, I'm not sure I understand the problem... Do you plan to profit from being the creator of this currency? I don't see how that's possible with a decentralized currency. You should write down your system, this way you can take credit for its invention before someone beats you to it. |
|
|
|
Not enough details to assess the feasibility or desirability of your system. Perhaps some of the ideas here are relevant, where we have discussed how to reduce the amount of hashing that needs to be done for a given level of security. I suspect that your system may take into account "circulation", as I suggest here - real economic activity is determined by the total number of different coins that move around (whereas a client sending coins back and forth will draw on a limited set of coins). |
|
|
|
I am currently considering this variation for my pool: PPLNS=Pay Per Last N Shifts
This is less resource-intensive than shiftless 0-1 PPLNS, but I don't find it simpler. I think exponential PPLNS is simplest in both presentation and resources (since you only need to keep track of one number per worker). For a full description of this, take the double geometric method with o=1. Note that for display purposes the relevant quantity is S/s. I'd base shifts on a specified quantity of score. Suppose X=0.1, if a shift starts at D=1M, 50K shares are submitted, then D increases to 2M and 100K more shares are submitted, this completes a shift (50K/1M + 100K/2M = 0.1). It's ok to change X between shifts and to base shifts on units of time, as long as you don't end shifts based on number of blocks found. Any block found in a shift of size X, gives a reward of (B*S)/(N*X) to any worker whose total score in the previous N shifts is S. The idea is: If I submit a share, I get score p which qualifies me to an expected reward of pB. For each of the next N shifts, the expected number of blocks found is X (where X is specific to that shift), so if I'm rewarded (B*p)/(N*X) per block that's on average pB/N for any future shift, and since there are N the average reward is pB. |
|
|
|
|
I've added a section and appendix about PPS, thus completing chapter 2.
|
|
|
|
FWIW, AFAIK bitcoin.org and bitcointalk.org are owned by sirius, while bitcoin.it is owned by MagicalTux (Mark Karpeles, owner of mtgox). The word "Bitcoin" has many meanings. One of them is a project to create and promote a p2p cryptocurrency. Another is an open-source project to create software for use by the Bitcoin cryptocurrency project. bitcoin.org is the official site of the latter, but not of the former. bitcointalk.org is the de-facto official forum of the former, and bitcoin.it is the de-facto official wiki of the former. |
|
|
|
Mining is actually quite essential to Bitcoin, I think. Those 50 BTC have to go somewhere, and assuming that Bitcoin becomes widely adopted, even a small fraction of that 50BTC will become radically valuable. The more miners there are, the more the currency is distributed and the longer it would take on average for each individual person to sell their holdings. It's like a communal investment that naturally helps stabilize the economy and increase demand/value.
Right, but if the difficulty continues to hover around the point where the average electricity cost to mine those 50 BTC is more than what those BTC will pay for, then the only people with a real incentive to mine will be those who are either stealing their electricity from someone else, are irrationally willing to pay a premium to get the bitcoins they want to spend by mining over a long period of time, when they could just buy then directly for less, or are speculators convinced that the price will go back up but still irrationally decide to mine as their way of "buying in", when, again, they could just buy them directly faster and more cheaply. I'm all for bitcoin succeeding, but it seems that unless miners can be compensated for more than what would be breaking even at near to whatever the common electricity rates are when using the most efficient hardware, then you end up with a "lowest common denominator", unethical currency system. I say this because I don't think you can claim to have an ethical currency system that is primarily built on the backs of individuals getting compensated for stealing electricity, nor can you say this about one that primarily benefits from irrational human behavior. Well, I guess you could argue that the latter is still ethical, in the sense that it is akin to "profiting off the proceeds of running a casino", but I don't think the former can be legitimized so easily. Now, there are also those who will pay higher than market rates to mine for their bitcoins, instead of buying them directly, simply because they want to support the cause, but I don't think that those kind of contributions alone can sustain it. Collecting transaction fees to make mining perpetually marginally profitable, even for those who don't steal their electricity, may be the only way to go about maintaining at least something that can't be argued to be based in large part on unethical practices. This is ridiculous. The first mistake is assuming that the only cost of mining is electricity. In addition there is the capital cost of the hardware, with a trade off - FPGA are expensive but energy-efficient, while old GPUs are cheap but inefficient. If the "average" electricity cost (whatever that means) is higher than purchase cost, it only means that those who mine will be those who have a comparative advantage in doing so. These are people who...: 1. Can afford FPGA / ASIC (perhaps developed in-house) as part of a scalable, profitable business. 2. Already have the hardware for other needs, such as GPUs for gaming. 3. Live in a place where electricity is cheap. 4. Live in countries where there is a need to import bitcoins and it is easier to buy computers than to send money overseas for purchasing bitcoins. 5. Speculate that the difficulty will decrease. 6. Enjoy mining or think they can learn something from it, and are not straw Vulcans. 7. Last and least, irrational people and those who steal electricity and can get away with it even after the bill goes through the roof. Relating to this my earlier comment, the average Bitcoin user is not any of the above, and thus shouldn't be introduced to mining. |
|
|
|
If there are 10 pools like this, can't I set them all up to be .1N a day in advance or whatever, mine for a bit at one, and then bump up the N and jump to the next .1N pool? Especially if you allow people to change their N at will, they can just make it float along so that their last batch of mined blocks is always in focus, until they drop it back to the minimum and begin mining again.
I'm not sure I understand what you mean, but I think you missed the point that you can configure what X will be for the future shares you submit to the pool, not for past shares. Although there's no problem with changing X for past shares, as long as they're rescaled to maintain the same expected payout. |
|
|
|
While I haven't given sufficient thought as to exactly how Bitcoin can address these desires, I have a few general suggestions. The first of these is simplification and security rolled into one. Find a way to merge the Bitcoin client with a miner ALREADY REGISTERED TO A POOL. So, in other words, the only thing to do to get started would be 1.) Download client/miner 2.) Click confirmation email which will confirm your account and provide you with username and secure password 3.) Start mining. Perhaps an automatic account on Mt. Gox or TradeHill could also be created when downloading this client. Bitcoin is not about mining! The kind of people to whom your post at large applies, are exactly those who shouldn't know there's such a thing as mining. Nor should they see coins magically appear for them, this will just reinforce the notion of it being "play money". Making Bitcoin more appealing to the public is well and good, but it should be appealing on its own merits. Bitcoin is not a cute beanie baby, and we shouldn't try making it into one. |
|
|
|
Is your geo method and this double geo method essentially PPLNS but N is the number of shares in the last x hours?
Absolutely not. Time never plays a factor in a hopping-proof method. To clarify the picture, all these methods fall into a spectrum with two axes: 1. Decay function: 0-1 (step function), exponential, linear etc. 2. Block finding effect: No effect, resetting the round completely, or something in between. PPLNS is 0-1 with no effect for block finding. Geom is exponential with complete round reset. Double geom is exponential with a partial effect of block finding, the magnitude of which is controlled with a parameter. Can you please graph the decay rate?
It's exponential decay, you can see a graph of how that looks like here. The exact decay rate depends on the parameters. With double geom it's more complicated because there is also decay when blocks are found, but that's also exponential in nature. |
|
|
|
you need to have a score system for PPLNS where each share is paid based on the current difficulty so when the difficulty changes the score for the new shares changes per share
so that way the rewards are consistent
and that means the round where the cutoff changes will have a weird amount of shares actually paid, in fact a single share could be partially paid to fairly reward the corrent N for the old difficulty and for the new difficulty
That's what I said in the OP. Are you simply agreeing with it? |
|
|
|
|
I, aka Bitcoil, will be attending the event as a sponsor.
They NYC conference was very interesting, but we need a much better organized conference. I'm confident in Mitchell's ability to run this professionally and successfully.
Mitchell, there should be an official attendance list to which people can optionally add their real name and/or forum/IRC nickname. It should also be possible for people who haven't yet paid to be able to add themselves with an "unconfirmed" status. In addition to a list of names, the total number of people, including those who wished not to reveal their identity, should be displayed.
|
|
|
|
Allowing users to change the N value themselves is a terrible idea for pool operators. Anyone implementing this please let me know though  It won't be too bad if some limitations are imposed, e.g. X must be between 0.1 and 10, and can be changed only once per day. I want to say "and only after the account has already submitted some number of shares", but that may be too inconvenient for honest newcomers. However, if implemented incorrectly, it is possible to hop based on imminent difficulty changes. I wonder what the real world implications of this are - roughly: A 10 GH/s user that has an expected reward of 10 BTC can get an extra 0.2 BTC based on the difficulty decreasing 2% ? Basically yes. If N is a fixed number of shares, D1 is the current difficulty, D2 is the future difficulty, p1=1/D1 and p2=1/D2, then the expectation for a share submitted just before the difficulty change is p2B where the fair reward is p1B, an increase by a factor of D1/D2. For a share submitted N shares before the difficulty change, the fair reward p1B is obtained. For the in-between period it increases linearly from p1B to p2B, so the total extra that could be obtained (with enough hashrate) is (p2-p1)NB/2 per difficulty change. Of course, to exploit it will require a reasonably accurate estimate of the time of difficulty adjustment, which is easier to do if the hashrate of the pool (including hoppers) is small. |
|
|
|
Something that I'd be interested in and where I'd really love to know if it's possible:
Can you let your users choose N (in multiples of D) individually?
Let's say I have a miner that wants to have payouts as fast as possible and be able to cash out and leave the pool quickly at any time - so he chooses N = 0.5*D
Another one really loved the idea of prop that every share gets paid at least something and wants to be paid something at every (or nearly every) share, so he chooses N=10*D
Is it possible to pay these users their fair share without enabling them to hop the pool by creating a few workers witrh different Ns and choosing the optimal(?) one?
If there is a scoring system for this (and I suspect there is), users then could "tune" the pool payouts + variance to their individual needs. If you first had N=1 and then set it to N=10, of course you'd only apply this to shares submitted afterwards, not to past shares...
Yes, this is possible. It creates some variance for the operator, but if the pool's composition doesn't change much it's fairly small. Basically, when you go backwards in the list of shares, you pay each share (sB/X) if the total score so far is less than X, where X is the value specific for this share. For participants it doesn't matter at all that others use a different X, because their own payments are exactly like in uniform PPLNS. For the operator it can matter, because there's no guarantee that the total paid is equal to the block reward, but long-term it will average out and I don't think the variance will be much of a problem. This is consistent with some ideas I have for moving away from traditional reward systems and using a more general "futures market" for pool shares. Instead of distributing block rewards, the operator keeps block rewards but allows miners to trade shares for "bets" on blocks found in the future. This way there's no fundamental need for different miners to take the same bets. If the bets conform to one of the known reward systems, the system will reduce to them, and if the bets are offered in a way that the total obligation per block is equal to the block reward, you have 0 operator variance. And these contracts could be traded on an exchange, so investors who are not risk-averse and not mining themselves, can trade instant money for a contract that will have a higher eventual expected return. This will also allow miners to get cheap PPS. But I'm getting ahead of myself... In the more immediate future, you can have a system where a miner can configure in the pool's website what reward system and parameters he wants to use, and get a quote for the fee the operator demands to compensate for the induced variance. |
|
|
|
If there is no mechanism for stakeholders to choose between chains, then why include stakeholders at all? Why not just have the miner who finds every 100th block flag it as a checkpoint (and prohibit reorgs past this point)?
Because there's no "the" miner. There are several miners, some of whom may be attackers, each of whom may find his own version of, say, block number 143100. Each of these blocks will have its finder flag that "My block is the real one!". How would a node know which branch to use? If you suggest that a block will be automatically flagged if the branch built upon it is sufficiently ahead of all other branches, you leave the possibility that a node will be introduced first to a wrong version and then refuse to conform to the right version when he finds it. Blocks aren't good or evil, all you have is synchronization, everyone should a agree on the same block. With stakeholder signatures you have that - once a block is signed, everyone can verify this and agree on the block. The only people who have some limited ability to mess this up are stakeholders, who have the least incentive to do so. As regards my suggestion, your concerns seem to be based on a misunderstanding of opportunity cost. The relevant question is the opportunity cost associated with mining via stakeholding, not the value of the bitcoin used to mine. The majority of bitcoins are just sitting in wallets with lots of confirmations. Using this money to mine has minimal opportunity cost since it is being held as a store of value anyways. I think that people holding bitcoin could be persuaded to mine even if the rate of return on their assets was extremely small (say 1% per annum). Remember that they can 'withdraw' their money from mining and spend it with minimal delay. If people are willing to participate even with a very low rate of return, then the opportunity cost associated with participation is necessarily extremely small. By contrast, the opportunity cost of mining via hashing is quite high because GPUs and electricity are not held as stores of value. Consequently, for computing power-based mining, the value of resources used in the mining process is the opportunity cost. What I am proposing involves a tremendous reduction in mining overhead (properly measured as opportunity cost) not an increase as you suggest.
More likely, my concerns were based on a misunderstanding of your suggestion. Upon further reflection, it looks like it is not too dissimilar to my own, yet I believe mine is superior. You'll need hashing anyway because it's intractable to collect proof-of-stake for every single block. And there doesn't seem to be an advantage in holding coins in escrow (which is additional overhead) over collecting signatures, with voting weight which depends on the history of the coins. |
|
|
|
How does this deal with variable or unknown block rewards? Already now block rewards are rarely 50 BTC and the endgame scenario is anyways random block rewards (which should just be profitable).
It doesn't. For now I recommend (for all reward systems) that the operator keeps transaction fees, and take this into account in his business plan when he decides what pool fees to take. I'll investigate this more thoroughly as it becomes a bigger problem. On second thought, it is trivial to deal with variable block rewards - at least, in a framework such as this which allows operator variance, and as far as hopping-proofness and expectation is concerned. Analysis of things like variance is harder though. I've changed the wording to be more friendly to incorporating this - basically the score given to a share should be based on the block reward at the time of submitting it. In other news, I've thought of a new framework which includes as special cases double geometric, 0-1 and linear PPLNS, and their extension to operator variance. Some parts of this I've known for months, others for weeks and a key part I've just thought about. I think in particular the extension of linear PPLNS will give the ultimate variance tradeoff (though it's not pure score-based). I'm so excited... And yet I really need to work on Bitcoil now. So much to do, so little time... |
|
|
|
|
In this case there's no need for rescan.
I think it's not too bandwidth intensive because you're limited by the number of connections. If you can forward port 8332 it should allow more connections.
|
|
|
|
|
Show Posts
