It doesn't matter if he says what the coin is in public, you just have to compare the working difficulty to the list.
Or is he feeding you false difficulty data? ... |
|
|
|
if you check the difficulty of the coin that we're working on and look at the current difficulties of various coins it usually isn't too hard to figure out which one we're mining.
Who says H2O isn't sending false Network difficulty data? Network difficulty as shown in cgminer could be a complete lie as far as I understand. That said, you could just watch the block you are hashing on, if you know how to dump that data. |
|
|
|
More miners means more hashrate meaning:
[...]
-hurts dedicated miners of the coin when we leave them with high difficulty
[...]
That is kinda part of the point of this pool... to devalue altcoins by raping them and then trading them to BTC. |
|
|
|
Ho my god. It's happening again.
Three cheers for H20.
This is straight up epic... Must be a side-deal with a private buyer or something. Pool balance ramping straight up. Epic... H20 H20 H20! |
|
|
|
|
A single collision wouldn't be very relevant... discovering a way to calculate collisions would be, but discovering 1 collision is extremely unlikely to even assist in that. And the OP topic makes no sense... there are many reasons it's more secure to use a new address for each transaction, but there is basically no reason to fear more addresses. The "logic" this thread talks about is not even slightly logical or mathematically sound.
|
|
|
|
|
Will the old stratum url's stay up indefinitely?
|
|
|
|
|
Too bad you limited shares. I would have been interested.
|
|
|
|
Users set themselves up for this shit by insisting on hot wallets.
Be willing to have the admins run their monthend trial balance until it balances before doing their monthly accounts-payable payouts and maybe there would be less of it, though even then arguably hackers could hack carefully enough to ensure the trial balance balances so that the admin will likely go ahead and run the payouts even though the wrong people get paid.
Another way to work around it is sheer volume of users combined with high enough fees, so that even if a hot wallet is emptied totally the loss can be absorbed by the site (admittedly due to having been passed on to the users in advance in the form and size of the fees).
-MarkM-
I would rather a pool that just pays what you are owed every day. No need for any manual or limit trigger withdrawals - an admin should look over the payments each day to make sure nothing is fucked up. Of course, a CPPSRB pool should never have had this problem. The fact this happened shortly after the un-warned move to PPS and back to CPPSRB when people complained strongly points to fraud. A properly configured CPPSRB system should never be able to inflate balances beyond what is payable (49.5LTC/block found). If the admin's story is true, the false earnings should have gone into shelved balances, not payable balances. |
|
|
|
The pool running again as before with CPPSRB and 1% fee.
Why is the pool not finding blocks? And our balances got 0'd again? WTF? |
|
|
|
Now ideally can't Hypernova link the wallet address with username and ask them politely to return? Or at least return enough to cover everyone's wallets? Luckily only had .01 LTC so no big loss but feel for the people who took a hit
They probably could... if the accounts don't belong to the admins that is. |
|
|
|
You had erroneously assumed that hypernova had moved back to CPPSRB when in fact it was only a plan to move back... The pool was/is still PPS. That is why money was lost. What? [..] We've heard your feedbacks and did a rollback this morning (11AM GMT+1) to CPPSRB with 1% fee.
We learnt from our mistake and won't change the reward system again as it seems CPPSRB is the only one people like !
Enjoy the most stable pool ever !
Soak and M0nsieurChat Hypernova was definitely supposed to be on a CPPSRB system when this supposedly happened. And if it was on PPS, then the pool developers/owners should take personable responsibility for all balances, because that's how PPS works... Either way, this is a huge error that points to multiple problems in the handling of this pool and its software. Dear all, Today we scheduled a maintenance that went bad on Hypernova. The purpose of this maintenance was to push the new litecoin daemon in its new version 0.8.3.7. As you may be aware, this new branch of litecoin needs to resync the whole blockchain. During the blockchain syncing, the network difficulty dropped to something like 0.XXXX and the PPS rate skyrocketed. Those who were mining during that upgrade within that 2 minutes timeframe experienced a WAY too high balance (we're talking about thousands of LTCs) The auto withdraw threshold feature perfectly worked. Here is how you empty a pool wallet in seconds. I'm very sorry about your loss. I decide to stop the Hypernova's adventures here. If the coins (or part of the coins) are returned by those who received the withdraws, I'll be happy to refund those who ask me in PM or at feedback@hypernova.pw (please tag your subject with [refund] as you guess I'll have many mails within the next days) If you see that Hypernova sent you too many coins, could you please send them back to LgDKkDSmjCmgEwkNZH5TXSnhd2aKbDFzzr so there will be less people screwed ? Thanks for mining on our pool and sorry again.. Human mistake. There are either multiple serious bugs at work here, or this is deception and fraud. Either way, this is very strong evidence that M0nsieurChat and Soak do not have the knowledge required to be running a mining pool. Funds should be returned to balances, and withdrawals frozen until this is worked out. If that does not happen very quickly, we all may as well be sending our hashes to notroll.in. Keep in mind that the funds that went missing could very well be to M0nsieurChat and/or Soak's own accounts. Sure there were a bunch of transfers across 3 blocks... what's it to the admins to have multiple accounts in preparation for testing, or with a plan to be devious in the future? M0nsieurChat: Was this a PPS pool or a CPPSRB pool? If it was a CPPSRB pool, how did balances inflate beyond what could be paid? |
|
|
|
Phzi, I was logged on while it was happening. I witnessed my two accounts' (one company, one personal) balances skyrocketing to 1000s of LTC. If you examine their pool address, you'll see the payouts going to addresses they always have been. There was not some massive cleaning to one address, there was not a cleaning to a bunch of new addresses, it was simply gross overpayment to current miners. There are no grounds for your accusation, nor should you be one to be making accusations at all (given your relative unfamiliarity on these forums). I personally trust M0nsieurChat, and professionally trust him (with my business). Hypernova has paid out fairly over my time with them, in fact, better than certain other pools.
Just because I am posting from a new account does not make me new here. There are plenty of grounds for stating that you wiped all balances... because you DID wipe all balances. I had a balance on the pool, I was not paid, balance is now 0. That means they stole balances; period. Doesn't matter if they lost money due to incompetance or stupidity, they still wiped/stole everyone's balances. Now please explain how more then 49.5LTC per block went to user balances if this is a CPPSRB pool? Payouts should have been capped at 49.5 LTC per block and everyone's shelved earnings should have skyrocketed. That's half the point of using a CPPSRB pool vs a PPS pool, is the payment security. Please explain that... |
|
|
|
|
WARNING!!! DO NOT MINE HERE!
Hypernova has stolen/wiped all balances.
|
|
|
|
|
Glad to see hypernova back on CPPSRB. I was very disappointed by the change to PPS, and planned to move my (albeit small) hashing power to another pool today.
I suggest: shelved earnings need some way to understand how 'deep' your shelved balance sits. A chart showing the pool's total shelved earnings and how deep your portions sit in the pool would make the CPPSRB system much easier to understand. And maybe a few "pool luck required to pay out xx% of your shelved balance" stats - e.g.:
Block probability required to get 10% of shelved balance: 40%
Block probability required to get 25% of shelved balance: 28%
Block probability required to get 50% of shelved balance: 13%
Block probability required to get 75% of shelved balance: 7%
Block probability required to get 90% of shelved balance: <1%
Block probability required to get 100% of shelved balance: >1 block required
These stats would be awesome to have for both per-user and pool-total. Could graph this as well (correlating luck with what percentage of the shelf will get paid off).
It might be easier to calculate the reverse, that is:
shelved balance to be paid if next block found at 1% probability: .12LTC
shelved balance to be paid if next block found at 10% probability: .07LTC
shelved balance to be paid if next block found at 20% probability: .05LTC
shelved balance to be paid if next block found at 30% probability: .01LTC
shelved balance to be paid if next block found at 49% probability: .001LTC
For the chart I mentioned, picture a graph with percentage of total shelved earnings from 0% to 100% on the left Y-axis, and block number on the X axis. Labeled on the right Y axis, have shelved earnings from 0 to <biggest shelved chunk value>, and for each block on the Y axis, show the user amount of earnings required.
Can substitute "block number" with "how many blocks deep in the queue (0-n)", or "percentage deep in the queue (0-100)" depending on how you are internally tracking the CPPSRB shelf payout order.
CPPSRB causes income to swing greatly with pool luck, so give people as much "luck" information as you can, and it definitely increase the appeal of the system. You have a good thing already with a seemingly solid hashing base - just add more stats and make everything you can about the payout system transparent.
---
Anyway, thank-you Soak and M0nsieurChat for listening to feedback and acknowledging your mistake in switching to PPS. You guys rock.
|
|
|
|
Okay, that page is kinda interesting, but their classification of SHA-2 as "Serious weakness discovered" is rediculous. I would say that in the worst case SHA-2 is in the "Minor weakness discovered" catagory. Even then, look at the 2007 note they use for why SHA-2 was marked as weak: "In 2007, the NIST launched the SHA-3 competition because "Although there is no specific reason to believe that a practical attack on any of the SHA-2 family of hash functions is imminent, a successful collision attack on an algorithm in the SHA-2 family could have catastrophic effects for digital signatures." One year later the first strength reduction was published." The strength reduction is barely significant from a computational point of view. You can still compare the complexity of the attack to the number of protons in the universe... And no full-round collision has been found years 6 years later. A bit of background on what is means to break a hashing algorithm: A secure hash algorithm depends on its ability to produce a unique hash for any specific set of data. A collision occurs where the same hash value is computed from for two different sets of data. Collisions do not represent breaks in an algorithm, but may possibly expose a weakness. When collisions are known, an attacker may be able to, for example, alter data without changing the resultant hash. A strong hash function is one that is resistant to such computational attacks. A weak hash function is one where a computational approach to producing collisions is believed to be possible. A broken hash function is one where there is a known way to reliably compute collisions. Other academic weaknesses are common in hashing algorithms. These weaknesses often propose methods of slightly shortening an all-out bruteforce attack on the alrogithm. Current, meet-in-the-middle preimage attacks exist against SHA-2 - these show that the first x number of steps can be preimaged, and reduce the work required to compute a hash. The best attack so far reduces SHA-256 to 42 steps (about 66% of the total 64 steps), but requires significant memory and disk resources to achieve this minimal reduction. (attacks reference: http://eprint.iacr.org/2009/477.pdf http://eprint.iacr.org/2009/479.pdf) IMO, so far, no publication about SHA-2 has shown anything that would cause real worry about the algorithm's security for bitcoin's purposes. None of this really matters to bitcoin's use of SHA-256 for Proof of Work. Unless SHA-2 is completely broken with a way to reliably generate data with a given hash, any further weaknesses are unlikely to affect it's usefulness for PoW. Future vulerabilities may make SHA-2 based hashing algorithms a poor choise for password hashing and data signing, but are unlikely to break it in a way that damages its effectiveness as bitcoin uses the algorithm. If the day comes where we see an effective attack against SHA-256 that affects bitcoin, the community will likely fork the blockchain and switch to another hash algorithm. Any damange to the blockchain can just be reverted by resuming the chain from a previous checkpoint with a new hashing algorithm. [If that needs to happen, however, all ASIC devices would become useless...] |
|
|
|
|
Best bet is to start offering your products/services and see what happens. Bitcoins are a great way to increase the reach of your product by introducing it to a new community.
Oh, and don't forget to accept litecoins! I will buy some tea when you do that. Always nice to have a good source of tea.
|
|
|
|
|
Can you get an SSL certificate already, please? Even self-signed would be better then nothing. Logging into a mining pool with a clear-text password just strikes me as foolish. If you add SSL, I will give WeLoveLTC a try now that hypernova has foolishly abandoned their payment scheme and is charging absurd fees.
Do you guys have block finder stats?
|
|
|
|
|
Show Posts
