|
Stats are broken until we find a block. All past mining and current mining will be properly credited. Sorry for the inconvenience.
|
|
|
|
With too-widespread software flaw, you can lose bitcoin EVEN if nobody picks your private key, or hacks into your PC. The bitcoin network is only as good as the software. If there is a critical bug introduced, and too many people use the client that has this bug, you could push through any transaction you want. Those would technically be invalid transactions, and clients not affected by bug would reject them, but if too many clients will accept, it will become de-facto a new block. And once a bunch of blocks are stacked over invalid block, it will be practically impossible to rollback. So, your paper money would lose the balance and you wouldn't even know. Bitcoin has had to rolled back up to 53 blocks before ( CVE-2010-5139), so I wouldn't say it's impossible. Integrity of the currency comes before miners' income. |
|
|
|
|
Pool is down hard. I think the datacenter must have a dead switch. Will post when I learn more.
|
|
|
|
It's easy to see what pools paid out what, especially if there is a historical hashrate available..*p2pool*. # of blocks * 50 / Hashrate for that period (in giga hashes) = payout per giga hash <conspiracy> No body will produce these graphs because it would prove without a doubt p2pool outperforms everyone else.  </conspiracy> Sorry, but even with Eligius's terrible luck lately, it still has a better track record than p2pool - and I'm pretty sure we're not the only other pool with historical hashrate available either. Are you saying Eligius has a higher payout per gigahash than p2pool does?  At this time, yes. Over the (very) long term, statistically they should be the same. |
|
|
|
It's easy to see what pools paid out what, especially if there is a historical hashrate available..*p2pool*. # of blocks * 50 / Hashrate for that period (in giga hashes) = payout per giga hash <conspiracy> No body will produce these graphs because it would prove without a doubt p2pool outperforms everyone else. </conspiracy> Sorry, but even with Eligius's terrible luck lately, it still has a better track record than p2pool - and I'm pretty sure we're not the only other pool with historical hashrate available either. |
|
|
|
Something is odd there. I point my miner to pool and after about 20hrs get stats: http://eligius.st/~artefact2/7/1Q6igQVdYrxLKy5qJBXAEsSn91S1ZhnoiiMost strange thing is that miner shows: (5s):105.5 (avg):146.2 Mh/s | Q:2795 A:176 R:1 HW:0 E:6% U:0.16/m
TQ: 1 ST: 2 SS: 0 DW: 336 NB: 115 LW: 0 GF: 1 RF: 4
How is this possible that pool telling me that I have only about 10MH/s average??? Do you have multiple pools defined in CGMiner? I think you need to set --failover-only or something or else it will "leak" work to secondary pools. |
|
|
|
How about some screenshot action. This is what keeps happening, and this time I decided to make a core dump of the process. The command window when I found it was not accepting button presses, so it seems that the mining process had frozen entirely. Since the U number was so low, it was obvious that the process had continued to run even after the unit stopped hashing, and froze much later - the U is normally around 11-12, and the average hash rate is normally around 865 not 675. As you can see from the screenshot, the last LP that it reported before it froze was at 13:53:09 Eastern Time, and it had stopped considerably before that although I'm not sure when. Screenshot was taken at around 14:30.
In addition, the secondary internal red light on the BFL unit was steady on, and not blinking every 5 seconds as expected. It also was idling and not running at full burn or stuck in a loop. Normally when the machine is idle, the internal red light goes dim.
I am not sure what the core dump contains, so I won't post it, but if Con, Kano, or Luke-Jr want to see it just ask and I will send it over. This is a BitForce FPGA, correct? You can send me the core dump (I imagine it's too big for email), but I'm not sure it will be of much use since you're running on Windows - perhaps I can pick out some strings from it. It does contain all your pool login info, note. |
|
|
|
you can shut down your pool at any point and not pay people out
I'm pretty sure I am guaranteed that p2pool stays up and keeps paying people p2pool is no more guaranteed to stay up than other pools (unless you have enough hashrate to solo mine, perhaps). Also, one benefit of Eligius has always been that since we include payouts for even the current round in the generation for its block, your payout is generally just as secure as it is with p2pool. Unfortunately, due to the design of Bitcoin, SMPPS sometimes carries a backlog that can delay things until it is paid from the buffer, but there's not much anyone can do about that until Bitcoin is hardforked (at which point, it would hopefully be modified to allow additional inputs to generation). |
|
|
|
with the recently very poor luck, I'd be interested in how many blocks are we "behind". Is there some way to get info about negative buffer size? A graph would be cool (I like graphs), but numbers will suffice. There is currently approximately 1000 BTC worth of extra credit issued. Considering Eligius's history of above-average luck, and often peaking out over 1000 BTC buffered, this seems pretty normal/expected. For comparison, another pool member noted yesterday that p2pool's luck works out to 2400 BTC behind. If this goes on for too long, I might consider "upgrading" to ESMPPS just so new miners don't feel like they're losing out. Thoughts? |
|
|
|
Uh oh. DDoS. Working on it, should be back online soon. Funny stuff. I remember you saying the other day Eligius would be harder to DDOS than P2Pool yet now I see p2pool still working.  I have nothing to do with the DDOS BTW. Just an observation and you got proved wrong ... No, it didn't prove anything wrong. Eligius is still working, I just had to activate the DDoS protection - now we have more info to build on to automate activating it better next time. p2pool is still working because nobody bothered to try DDoSing it yet. If someone wanted to do a comparison to "prove me wrong", they need to DDoS p2pool too (which is just as illegal as DDoSing Eligius, so I don't endore doing it) with the same amount of bandwidth and see how each pool does after 24 hours of it. |
|
|
|
Did you update the wiki page with the specification? I should probably do that... Please try to edit the existing specification draft, rather than replace it entirely. I combined the two, but please double-check that I didn't miss anything. Note that JSON does not have Float or Time types, just Number. I also made a quick pass over it to try to make it sensible for Bitcoin address mining. |
|
|
|
Hoppable prop pools will not be wanting to give out that much information... of course that's their problem.
That's why everything is optional. |
|
|
|
Plus I get to see Mined coins in my wallet instead of Received coins. For some reason they just seem shinier to me.  ..the most anonymous coins you can get, too! Ente Well it's pretty clear that they come from p2pool and since there are only about 200 of p2pool miners, that narrows down the anonymity a bit. Anyone solo mining and any pool owner has "virgin" blocks. Pools can choose to payout virgin blocks if they want as well. It's just hard to code so it's easier to resend. p2pool blocks can be proven to be so. |
|
|
|
Uh oh. DDoS. Working on it, should be back online soon. |
|
|
|
Did you update the wiki page with the specification? |
|
|
|
Suppose a group of supporters set up 30 public p2pool servers, each with 1 Gpbs bandwidth, located in various datacenters throughout the world. It is relatively easy and cheap to lease dedicated servers that meet this criteria. These would be centralized pools, even if they participate in a larger p2pool. Would the distributed group of p2pool servers be more or less capable of fending of a 30Gbps attack vs. Eligius?
Which setup is more DDOS-resistant and why? Having a single server to protect from DDoS is easier than having to deal with it at every site. However, if you could setup your servers as anycast (which would require switching to UDP instead of TCP), a DDoS might be easier to mitigate in some ways. |
|
|
|
Funny, I think p2pool might have a little bit more hashing power than that... Anyone up for it? He said Gbits/sec, not ghash/sec. Rather different. One is hash speed the other is network speed. And if you try it you will probably get reported to the FBI by him anyway. Yes, just to be clear: I do not endorse any attempted DDoS or attacks on any pool, and will report any attempts to law enforcement. And yes, the FBI does care about DDoS attacks of this scale (that 30gbit/sec one took out a big datacenter and a whole area of Comcast cable internet). |
|
|
|
Note that generating vanity addresses that start with 3 like "3vanity" will be much easier and faster than generating vanity addresses that start with 1 (like "1vanity"). Only if you bloat the blockchain with a lot of unnecessary garbage, or make hard-to-import "keys". I've published my BIP13 (3...-addresses) branch of vanitygen. |
|
|
|
I'm gonna laugh if someone decides to DOS Eligius just for fun. They tried that back in February. With over 30 gbit/sec. |
|
|
|
|
Show Posts
