|
You can also stop the page loading (eg pressing escape) before the Javascript runs.
|
|
|
|
Seriously, I do mean 2 makes no sense at all. You got a link to where he said that? I'm curious to see that stupidity  I think some of it was at the tnt website which is down, but for example you have this which was posted on the HTH blog thread (meaning he was targeting hoppers specifically): (Quote header is a link) There's also this (by cablepair who helped mu50stang setting up): ...
As far as payout we are using PPLNS which is by far the fairest and most cheat proof payout system out there. It is what is being used at Eligius and many other pools these days, we considered going proportional just to get some sweet pool hopper action - but the truth of the matter is proportional is broken and outdated and PPLNS is one of the best payout schemes available.
...
|
|
|
|
I guess Inaba and Meni need to go attack all the other prop threads and report them to mods for whatever reason, I still can't work out what exactly it is, from reading this rather short thread.
That's actually not a bad idea, but no, I only report people who: 1. Start a proportional pool 2. Spam the pool everywhere with "proportional, all hoppers should come here" as a selling point 3. Switch to a different payout system mid-round without any prior notice 4. Close the pool shortly after creation 5. Start a new pool under a new username, without any reference to the previous pool 6. Lie about what they wrote (eg the edit of message #20 in this thread) Seriously you two, you do just make yourself look like idiots to anyone who reads this thread.
If anyone has reading comprehension difficulties it's their problem, just don't say we didn't warn you when this pools shuts down mysteriously. Even if we take Hanlon's razor to the extreme and assume the OP is just clueless, pools like this are an insult to people who work hard on making viable pools. But all I see (and I'm sure most others do also) reading this thread is you 2 bitching about there being a new prop pool coz it doesn't use DGM. Yeah those other reasons (3-6) may be valid, but certainly 1 and 2 on your list make no sense at all. Again, read this thread from the start and it seems like a "let's be whiny anti-prop bitches" session. At least cover items 3 to 6 in your post with details and point out that's the reason you're being drama queens, not the rest of the shit that Inaba has posted whining about it being a prop pool. I didn't give a list of reasons, I gave a timeline, 1 and 2 are a part of the timeline without which the rest doesn't make sense. #3 wouldn't have been that bad if he hadn't made a point of it being proportional in #2 etc. Inaba did cover all of the OP's transgressions, why would I need to repeat them? I simply agreed with his analysis and reported. Don't get me wrong, Inaba was completely in the right directing some of his criticism at the mere starting of a proportional pool. There's absolutely no justification to start a proportional pool these days. They are known to be broken. Starting a prop pools means you don't care that your users will be ripped off some 20% of their earnings and that you're counting on their ignorance to mine for you. I don't personally expose every prop pool that pops out, mostly because I'm weary of fighting people like you who come to defend the prop pool and accuse whistleblowers who actually care about people of having some agenda. You make it seem like I pulled DGM out of my ass and then went out to proselytize it by deciding that hopping-proof methods are good, when obviously the correct causality is that I saw the need for a hopping-proof method and then went to develop DGM to answer this need. (Of course it doesn't need to be DGM, PPLNS is also ok). |
|
|
|
cold truth is that casual miner with a few cards, can't maintain 99,9% uptime for whatever reason and all "fair" methods are a double-f**k for him
Myth. There's no need to maintain high uptime with hopping-proof methods. But I guess kano is right. As much as I care about people not getting ripped off by bad methods (and I do), it's not really my business to try to set straight every myth I encounter about proportional or score pools. The information is all out there, those who want to reach an informed decision can do so, the rest can do whatever they want. |
|
|
|
I guess Inaba and Meni need to go attack all the other prop threads and report them to mods for whatever reason, I still can't work out what exactly it is, from reading this rather short thread.
That's actually not a bad idea, but no, I only report people who: 1. Start a proportional pool 2. Spam the pool everywhere with "proportional, all hoppers should come here" as a selling point 3. Switch to a different payout system mid-round without any prior notice 4. Close the pool shortly after creation 5. Start a new pool under a new username, without any reference to the previous pool 6. Lie about what they wrote (eg the edit of message #20 in this thread) Seriously you two, you do just make yourself look like idiots to anyone who reads this thread.
If anyone has reading comprehension difficulties it's their problem, just don't say we didn't warn you when this pools shuts down mysteriously. Even if we take Hanlon's razor to the extreme and assume the OP is just clueless, pools like this are an insult to people who work hard on making viable pools. |
|
|
|
|
OP is almost certainly a scam artist. Inaba blew the whistle. I reported to moderator. Nothing to see here, move along.
|
|
|
|
|
This thread belongs in the Meta subforum.
This is an issue that was raised multiple times, it is impossible to do this with the current forum software.
I think the "ignore thread" mod of smf can be used for roughly the same purpose, but Theymos isn't willing to do any modifications before changing the whole thing.
|
|
|
|
But you may want to take advantage of the recently announced Crypto X Change coupons before eBay gives them the axe. |
|
|
|
I just recently started mining a bit at your pool, and I do have one question..
I understand the double geometric scoring system, and I love the idea of it...
I am curious, though, why my prop-diff is quite often negative. I'm not starting and stopping the rig, so I'm hashing continuously. Shouldn't I be at 0 or higher? What would cause me to get paid less than my share (proportional) if I'm not 'hopping' or taking breaks in mining?
Enigma
If you've started recently what you're seeing is probably your score building up. Your score starts at 0 and as you continue mining it increases until it reaches an equilibrium (which changes if the pool's total hashrate changes). So at first you'll receive less than proportional, in equilibrium it will be roughly the same, and if you quit at any time your score will gradually decrease to 0 and you will keep receiving rewards for some time. I have a feeling that he's referring to the wildly varying payout compared to the proportional calculation that a number of us have been experiencing over these past 60 or so blocks. The big up-swings in pool hash rate have caused some of us consistent miners to receive significantly smaller payouts when compared to proportional calculations for those blocks where the hash rate is unusually high. Once the hash rate settles back down, the payout very slowly recovers. I, for example, am still down compared to proportional for about the past 60 blocks. I have a highly consistent hash rate and near 100% up- time, but the big swings in pool hash rate have not been kind to my payout. That seems to be exactly what I'm talking about - although I can't be sure since I don't know the exact calculation/formula. Some blocks I'm ahead of the game, some behind - it's very inconsistent. Overall, I'm up compared to proportional - I'm just trying to understand why I often times end up in the red for a block or two. This definitely isn't me complaining - EMC seems like a great pool - I just want to be able to understand where the numbers come from. Enigma Oh, it is perfectly normal for there to be variations in the prop difference between blocks. These are caused mostly by fluctuations in the pool's total hashrate. BUT I want it to be very clear that it is the proportional reward that changes, not the DGM reward. DGM is guaranteed to give the fair payout on average, proportional isn't. What you may have been seeing is that the fluctuations would cause you a higher than average rewards with prop, but DGM isn't affected so you see a negative differential (eg if people happened to join before a block was found, and quit after). If the fluctuations are random they could just as well decrease the prop payout and then you would see a positive differential. Of course, I am not in any position to rule out technical problems with the pool itself which could cause abnormal behavior. What would you like to know about the calculations? The details of DGM are described in the DGM thread, the prop reward is calculated by your shares / round shares * block reward. Maybe there could be a graph showing your share density over the round, if it's lighter near the end it means people joined there which would cause a higher proportional reward (and lower prop differential). This has also been my experience, I mine 24/7 and, to be honest did much better with a scored system. Is there anyway to monitor our 'scores'?
This is a score-based system, though different (and better) than the specific score-based method currently used in slush's pool. If you've received less reward per unit time than with another pool this is most likely a result of bad luck (maybe specifically the recent invalid blocks). The displayed "estimated reward" is directly proportional to your current score. |
|
|
|
Raw credit card payments can also be reversed, and they're prone to be used with stolen CC data, so they're very risky for the seller. CC wrappers generally have the same disadvantages as PayPal. You'll be hard pressed to find a service which allows you to buy Bitcoins using your CC. You could try your luck finding in this forum or OTC someone willing to sell you for PayPal or similar. PS the main problem with PayPal isn't that we don't like it, it's that it doesn't like us, it freezes accounts used for Bitcoin exchange. Also check out this StackExchange question. |
|
|
|
I just recently started mining a bit at your pool, and I do have one question..
I understand the double geometric scoring system, and I love the idea of it...
I am curious, though, why my prop-diff is quite often negative. I'm not starting and stopping the rig, so I'm hashing continuously. Shouldn't I be at 0 or higher? What would cause me to get paid less than my share (proportional) if I'm not 'hopping' or taking breaks in mining?
Enigma
If you've started recently what you're seeing is probably your score building up. Your score starts at 0 and as you continue mining it increases until it reaches an equilibrium (which changes if the pool's total hashrate changes). So at first you'll receive less than proportional, in equilibrium it will be roughly the same, and if you quit at any time your score will gradually decrease to 0 and you will keep receiving rewards for some time. |
|
|
|
Thanks very much for taking the time to explain. I misunderstood completely where the capacitor was. Sent you a little something for your troubles and work on developing this pay scheme.
Thanks, much appreciated! |
|
|
|
Possible exploit: A chain made in secret with double-spends could absorb blocks from the main chain, allowing an attacker to overtake the main chain with a mere fraction of the hashrate and a little luck.
I'm not sure this will work. You'll have a rule saying that the parent with the most PoW contribution is scanned first (and continuing in descending order). So when the attacker absorbs blocks from the main chain, he needs his side chain to be larger if he wants his double-spend transaction to be included. I haven't worked it out but it might turn out that to succeed in the end he needs >50% hashrate. Of course there's a lot that needs to be thoroughly investigated, but I'm still not convinced my way fails. |
|
|
|
Do you see what I mean? In the end, every transaction inserted by honest miners is potentially reversible. You can try to "legitimately double-spend it" as I suggested above, but if it the attacker doesn't bite it, the transaction must be treated as reversible/unconfirmed.
No, I don't. As I said you shouldn't invalidate a parent if it has a conflicting transaction, you just don't include this transaction. If the attacker references a block with transactions he must include them (which as I said should be a rule), if he consistently doesn't include blocks he will lose the total PoW race. ">50% = Rewrite the block chain" works for the current "one chain" rule, it doesn't work for the the "trunk with side branches" proposal. |
|
|
|
But it's not that simple. As I said on the other posts above, we cannot consider transactions on branches which are not the trunk as confirmed, because they can be reversed on the trunk, which is under the control of the attacker. And the attacker would never accept to merge branches back to the trunk.
The attacker is not in control of the trunk. If the attacker tries to build his own branch without referencing the honest blocks, he will be beat by the honest network which references both honest blocks and the attacker's blocks. And, you can make a rule that non-conflicting transactions from parallel parent blocks must be included as I described above, so the attacker can't absorb the honest node's PoW without including their transactions. |
|
|
|
Definitions:
VALID - means that the orphan would have passed all block/transaction validation checks at the point where it would have ended up in the chain. The orphan MUST be from a chain that, when you add the orphan, has a lower total proof-of-work than the current chain. Additionally, to prevent an attacker from using this against the main chain, the transactions in the orphan chain (ignoring coinbases, which are discarded) MUST NOT conflict with the current chain.
To start, this spec only affects a blockchain's total proof-of-work. All other blockchain rules remain in effect.
Assumption: all VALID orphans would have increased the total proof-of-work of the main chain if the network had zero latency.
A block would be redefined to allow additional parents. However, there will still be a main parent, just like today. In Bitcoin, this could be added to the coinbase instead of making a new field in the header. (I wonder if the merged-mining format could help here...)
When a mining client receives a VALID, unused orphan block/blockchain that connects to the main chain somewhere in the last X blocks (where X is a number that I haven't really decided on), they SHOULD add that orphan as an additional parent to the current block they are working on. Additionally, they MUST(/SHOULD) add all transactions that haven't been confirmed yet to the current block.
When a client receives a block with an additional parent, it checks that the additional parent is VALID and connects to the main chain somewhere in the last X blocks. If the additional parent doesn't connect directly to the main chain, the client MUST recursively lookup that orphan's main parent until it finds a block that has either already been merged with the current chain or was part of the current chain. From there, the orphan chain's proof-of-work is added to the current chain. Any additional parents included in the orphan chain are then also processed in the same manner.
How will rewards be handled? Seems the most reasonable way is that only blocks on the main chain get generation rewards and transaction fees. This has the disadvantage that mining rewards will be less predictable because of the high orphan rate. Also might be an opening for denial-of-reward attacks. This is most definitely more complicated than it's worth for Bitcoin
I disagree, the branch selection rules will have to be changed at some point (could be 5 or 10 years from now), Bitcoin will not be secure against attack in the long term with the current rules. I think a combination of cementing with proof-of-stake will solve double spending, this suggestion can potentially solve the remaining problem of denial of service (as well as allow shorter block times, which allow quicker confirmation and improve mining variance). The only attack I can think of off the top of my head to reduce the effectiveness of this is to send different double-spend transactions to each peer, in the hopes of making any orphans that are created unmergeable. However, this can be reduced if the miners actually choose to communicate with each other and decide which transaction to go with, or use other such heuristics.
This can probably be solved the following way: Decide on a specific order among the parents and scan them in that order. Include any transaction which does not conflict with any previously encountered transaction, but do not invalidate a parent just because a transaction conflicts with one in another parent. Maged, could explain more what's this latency problem or link me to an explanation?
If the time between blocks is too short, communication latency between nodes will cause many orphan blocks, so the honest network will waste some portion of their hashrate. Meanwhile, an attacker will run on a localized low-latency network, thus have an advantage and it will be easier to attack with a given hashrate. By the way, when you say orphan, I believe you mean childless, right? By definition, the only orphan block is the genesis block, all the others have a block that preceded them.
Maybe the terminology is confusing but "orphan block" generally refers to one which is not on the main chain. |
|
|
|
In the capacitor analogy, every miner has a capacitor which is charged as he submits shares, and its charge level affects how much he gets per future block found. The pool at large does not have a capacitor which charges as blocks are found and affects the reward for future shares submitted. The pool's history has no effect whatsoever on the rewards for future shares. Hmm will be interesting to see my total payout after I stop mining Ozcoin some time in the future (also after I get all the after amounts)
Coz I joined them a few days ago when their luck was showing high, but I guess that doesn't mean I get more ...
The pool's luck in the past has no effect on your rewards. The pool's luck only affects you if your capacitor is charged at the time. It seems to me if a pool has a long enough run of luck, you join in and benefit while the value slowly works its way back down as the luck turns.
No. If you read the method's description you'll see that finding a block has two effects: 1. Giving out rewards to miners who currently have a score 2. Decrease the score of miners who currently have a score It has no effect whatsoever on future miners (or on the rewards of current miners for shares they will submit in the future - only those that they submitted in the past). Yep Hopping doesn't have to mean your gain is someone else's loss.
Maybe many think those two ideas are directly connected - but obviously in this case - they aren't.
Yes it does. With a given total hashrate, a pool's average reward is constant. If one miner gets on average more than his fair share, it means another gets less. In a hopping-proof method like DGM everyone gets their fair share on average. What I guess DGM does is allow you to capitalise on the fact that when a pool is lucky, that luck extends beyond the time when it occurs
Thus you can get part of that luck after the fact.
Absolutely not. The luck extends backward in time, not forward. You can't get part of the luck after the fact. To be completely honest, I'm growing weary of having to repeat the same thing over and over again. |
|
|
|
I don't see how you explain DGM is hoppable - can you explain exactly which/what pools list an amount they are paying per share? There's exactly two DGM pools that I know of and neither of them pay a set amount per share.
Presumably he means checking the parameters of each pool and its current state and calculate the reward from this... Which leads us back to the the expected reward being completely independent of the current state, since it depends only on the future and not the past. |
|
|
|
Don't forget to poll every DGM pool to find which is currently paying the most per share and hop to that site till the value drops on the next block they find...
Edit: If it wasn't obvious, this was me explaining how DGM is hoppable.
Yes, it was obvious that you do not understand how DGM works. DGM is hopping-proof, the expected payout per share is constant. |
|
|
|
To get up to speed, read the ChicagoCabbie thread.
What is this? Nothing comes up in search. Does this have to do with a charity? Sorry for the confusion, RaggesMonk. You're right! It doesn't come up in search if you use the white search box in the top right. But if you use the other search box located in menu tab, it comes up. Rassah has been on vacation for a couple weeks, therefore my reply was a quick hodgepodge of ideas/comments/questions directed toward him. Forgive me for not answering this, myself, earlier, but I was in Chicago having dinning with the Chicago Cabbie. ~Bruno~ I hope that the fact that the search box only searches within the current post/subforum isn't lost on anyone. So to search the entire forum make sure you're at "home" or otherwise not in any post/subforum. |
|
|
|
|
Show Posts
