FTFY?
http://www.urbandictionary.com/define.php?term=FTFY
Topic: [9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining - page 55. (Read 163893 times)
PPLNS doesn't punishes miners more for disconnects/non-continuous mining, while still being hop proof.
FTFY
FTFY? Do you understand PPLNS at all? You get paid for each share based on blocks solved after it's submitted. The value of the share has NOTHING to do with timing/consistency of share submissions. It is entirely based on how many blocks the pool solves after the share is submitted. There is no exponential/DGM scoring involved that makes shares worth less when you stop or when you start.
PPLNS doesn't punishes miners more for disconnects/non-continuous mining, while still being hop proof.
FTFY
After 10 minutes of thinking, my solution will be radical and easy: I'll re-create another account, and this time I will use my own wallets for every coin. And I would recommend this to anyone creating an account at this point!
Certainly the way to go. Stay in control of your own coins.
Also, Virc, Bter, and maybe other exchanges will "lose" any deposits from a new block coinbase. (They don't count as deposits any newly minted coins without an Input). It's a bug on the exchange's end but it seems widespread. If bitparking ever started paying that way, your payments would vanish.I did the same thing a while ago. I don't think doublec should change the way things work now. The main things that make Bitparking special are the site's simplicity, the merged alt coins mining and the pool's transparency. Pool hashrate had a steep drop when doublec changed the reward method from PPS to DGM, but that was probably a good thing and only temporary: pool hoppers were purged from the pool and a whole different kind of users are coming - miners who are more likely to remain loyal to the pool in the long term, which benefits everyone.
The target for DGM is "same payouts as pps", like all 'hop-proof' methods it has the net effect of setting your maximum reward as a ceiling and then punishing the miner who doesn't mine continually or drops out of a round. It transfers most of the risk and variance from the pool ops to the miners.
PPLNS doesn't punish miners for disconnects/non-continuous mining, while still being hop proof.
I would really like to hear some proof that DGM indeed works that way. I don't feel 100% confident that it's fair in that case, but haven't seen any real proof that it's not, either. It might definitely feel like you are losing expected payout when abandoning a round, but unless you have proof that DGM works that way, I'm more inclined to believe that the opinion is just based on a misunderstanding.
The huge failure of DGM is that it's almost impossible to understand (I mean really understand, not just on the "capacitor is being charged" -level) if you aren't a hardcore mathematician. I'm far from that level myself, and thus Bitparking doesn't feel as attractive anymore. Then again, even if you can understand a pool's payout method, it's another thing whether they have implemented it properly...
The huge failure of DGM is that it's almost impossible to understand (I mean really understand, not just on the "capacitor is being charged" -level
) if you aren't a hardcore mathematician. I'm far from that level myself, and thus Bitparking doesn't feel as attractive anymore. Then again, even if you can understand a pool's payout method, it's another thing whether they have implemented it properly...What can I say I've looked at the math.
The target for DGM is "same payouts as pps", like all 'hop-proof' methods it has the net effect of setting your maximum reward as a ceiling and then punishing the miner who doesn't mine continually or drops out of a round. It transfers most of the risk and variance from the pool ops to the miners.
If everything goes perfectly, you'll see about the same earnings you'd get on pps... when the pool has bad luck (or you do re:connection issues, low accepted shares etc) your earnings will drop off accordingly. Since it's waiting until confirmation of block generation and paying based on the last 5 rounds these losses will be obfuscated because they happen proportionally over the next 5 rounds. As I miner all you'll be able to notice is that your earnings seem to have decreased.
All I can say is, look at the equations - they aren't that hard to figure out. DGM does exactly what it was designed to do - transfer risk taken by pool ops to miners instead.
Is it a bad idea to have multiple workers submitting shares under the same userID ?
On that note, it'd be cool to have the number of blocks each user solved in the json. Sure it'd be zero for most, but neat.
Yes!!!!!!!!!!!!!!!!! My first block on new pool. EDIT: I didn't find it but it was the first we found since I join.
And I don't understand what is hard to understand in DGM... But then again I'm relay good in mathematics... And yes if you create new account and start mining on it old and new will total in same earnings.
And I don't understand what is hard to understand in DGM... But then again I'm relay good in mathematics... And yes if you create new account and start mining on it old and new will total in same earnings.
I created a new user last week. Watched one account go down and the other go up, pretty much exactly matching where the old account was first. Then the old account paid out for another 3.5 blocks or so at the ever decreasing rate of that "capacitor" effect.
I'll register a new account when the current block finishes. If I understood DGM well enough, I could lose more BTC abandoning the current round than I have in altcoins...
I'm under the impression that you should have no reason to think like that. In a fair payout method, all shares should have the same expected payout, and not depend on history at all. With DGM (and most other methods as well), the actual payout per share will have lots of variance, but it should average out after a long enough time, even over multiple accounts that are mining only occasionally.
DGM is really hard to understand, and unlike with PPLNS, I still haven't grasped it well enough to be 100% sure of the above. However, it would be a very lousy payout method if miners were forced to stay on the pool to not lose their expected payouts.
as I understand it abandoning a round at any other time then "very near the start" could infact drastically reduce your payout. Which is why I've argued so much about the switch. I'm off mmpool (for good I think) finally as a result of vircurex going down I don't really feel like recreating another dozen worker accounts to reset addresses.
I would really like to hear some proof that DGM indeed works that way. I don't feel 100% confident that it's fair in that case, but haven't seen any real proof that it's not, either. It might definitely feel like you are losing expected payout when abandoning a round, but unless you have proof that DGM works that way, I'm more inclined to believe that the opinion is just based on a misunderstanding.
The huge failure of DGM is that it's almost impossible to understand (I mean really understand, not just on the "capacitor is being charged" -level
) if you aren't a hardcore mathematician. I'm far from that level myself, and thus Bitparking doesn't feel as attractive anymore. Then again, even if you can understand a pool's payout method, it's another thing whether they have implemented it properly... I'll register a new account when the current block finishes. If I understood DGM well enough, I could lose more BTC abandoning the current round than I have in altcoins...
I'm under the impression that you should have no reason to think like that. In a fair payout method, all shares should have the same expected payout, and not depend on history at all. With DGM (and most other methods as well), the actual payout per share will have lots of variance, but it should average out after a long enough time, even over multiple accounts that are mining only occasionally.
DGM is really hard to understand, and unlike with PPLNS, I still haven't grasped it well enough to be 100% sure of the above. However, it would be a very lousy payout method if miners were forced to stay on the pool to not lose their expected payouts.
as I understand it abandoning a round at any other time then "very near the start" could infact drastically reduce your payout. Which is why I've argued so much about the switch. I'm off mmpool (for good I think) finally as a result of vircurex going down I don't really feel like recreating another dozen worker accounts to reset addresses.
Nope not me, I've only progressed from newbie status today so these are some of my first posts!
Hm... I saw this nick somewhere. Did we talked on IRC then?
I have problems with ICS. Widget is crashing and CPU also produces a lot of heat. Samsung galaxy Note upgraded to ICS
Yes there's more to come with regards to stats and work on the pool. If you search in the Android Play store you'll see a Bitparking app with widget
I know the app is not your business - already reported to the developer:
namecoins are missing i=coin still in
and biggest problem for me: the widget permanently crashes on HTCs Sence
but the website is so lightweight that there is nor problem in using it on a mobile device
Hmm I didn't notice this report, how'd you get it to me? I'll get to fixing that soon. Feedbacks always a good thing.
I know I must be missing something simple but I can't find where do I encrypt and backup IXC and DEV clients
You don't get to encrypt in the client as those clients do not have the encrypt feature yet.
Workaround is to run the client only when you want to send coins.
All other times keep it hidden away in an encrypted directory, or on a AES256 secured memory stick (if you are paranoid like me).
The downside is waiting for the blockchain to update each time you do this.
I know I must be missing something simple but I can't find where do I encrypt and backup IXC and DEV clients
8337 is the ixcoind port. For devcoin I'm using 9333, sorry.
You are my hero! :-) I got both DVC and IXC up tonight thanks to your help!
Now I'll just e-mail you my new addresses, sign with my BTC address and everything is fine again. So sweet!
I'll register a new account when the current block finishes. If I understood DGM well enough, I could lose more BTC abandoning the current round than I have in altcoins...
I'm under the impression that you should have no reason to think like that. In a fair payout method, all shares should have the same expected payout, and not depend on history at all. With DGM (and most other methods as well), the actual payout per share will have lots of variance, but it should average out after a long enough time, even over multiple accounts that are mining only occasionally.
DGM is really hard to understand, and unlike with PPLNS, I still haven't grasped it well enough to be 100% sure of the above. However, it would be a very lousy payout method if miners were forced to stay on the pool to not lose their expected payouts.
I got the Windows "package" from here, I thought it was the closest to the "official" binary.
Now forcing port 8337 didn't seem to do the magic. I think I need another devcoind.exe or compile it myself...
8337 is the ixcoind port. For devcoin I'm using 9333, sorry. Now forcing port 8337 didn't seem to do the magic. I think I need another devcoind.exe or compile it myself...
Jump to: