Search content
Sort by
Showing 20 of 39 results by eja
Quote
Incrementing N will lead to immediate hashing speed decrease. Difficulty will reflect these speed changes (i.e. difficulty will decrease after N++) with lags. As soon as block reward depends on difficulty the reward will increase also and more miners will be motivated to join after N++. It's not easy to predict now but we can be sure that some waves will happen on each N++ event.
when will this event be?
Read official website http://www.yacoin.org/about.html
Says first one is on May 14th. Bookmark that date!
May 14, N=64, 8Kb
May 17, N=128, 16Kb
May 20, N=256, 32Kb
May 29, N=512, 64Kb
I've already asked for this but it's lost in this very very long thread :
Do you know the precise time (with time zone of course) it'll happen ?
Using the nfactor calculating code from the client I get for the coming year (timestamps in UTC):
Wed May 8 05:33:20 2013, factor: 4
Tue May 14 07:11:28 2013, factor: 5
Fri May 17 08:00:32 2013, factor: 6
Mon May 20 08:49:36 2013, factor: 7
Wed May 29 11:16:48 2013, factor: 8
Sat Jun 1 12:05:52 2013, factor: 9
Tue Jun 25 18:38:24 2013, factor: 10
Sun Jul 7 21:54:40 2013, factor: 11
Tue Aug 13 07:43:28 2013, factor: 12
Mon Sep 30 20:48:32 2013, factor: 13
Mon Nov 18 09:53:36 2013, factor: 14
It is probably close to the limit. For reference below is the resource usage on mine (1GB ram) after a couple of days running.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2188 bitcoin 20 0 353m 200m 3708 S 3 20.2 310:23.68 bitcoind
4320 bitcoin 20 0 306m 108m 2732 S 35 10.9 729:14.69 python
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2188 bitcoin 20 0 353m 200m 3708 S 3 20.2 310:23.68 bitcoind
4320 bitcoin 20 0 306m 108m 2732 S 35 10.9 729:14.69 python
It seems that the cert file that can be downloaded from the fix api page has expired and does not actually match what is currently used on api.bitfloor.com.
You can get current cert file with following command:
openssl s_client -showcerts -connect api.bitfloor.com:5252
From the output copy the lines starting from -----BEGIN CERTIFICATE----- up to and including -----END CERTIFICATE----- and save those to the .crt file
that is in stunnel configuration.
Re: [ANN] [PPC] PPCoin Released! - First Long-Term Energy-Efficient Crypto-Currency
...
Yeah, I could try that.
Is there anything special about the pushpoold NothingG is using? I'd rather just start up my own PPC pool.
ppc.kattare.com? heh.
Yeah, I could try that.
Is there anything special about the pushpoold NothingG is using? I'd rather just start up my own PPC pool.
ppc.kattare.com? heh.
I run a bog standard pushpool setup with my pool, seems to work just fine.
I tried but I don't seem to get it too work completely.. I added my BTC-e api keys and on the console I can see it fetching ticker data from btc and mtgox (or at least trying to). But I don't see them on the market screen. Am I missing something ?
+1 for the name though
+1 for the name though
Re: [ANN] [PPC] PPCoin Released! - First Long-Term Energy-Efficient Crypto-Currency
Could be that cpuminer submits all shares above a certain difficulty. I see the same from shares passed from pushpool, it appears to pass all shares above 256 difficulty to the coiner daemon and so cause these same messages in the log.
Bit still with 2GH/s it should generate a share with sufficient difficulty regularly, even if if also submit too low shares.
Bit still with 2GH/s it should generate a share with sufficient difficulty regularly, even if if also submit too low shares.
Re: [ANN] [PPC] PPCoin Released! - First Long-Term Energy-Efficient Crypto-Currency
well, luck is a bitch 
just wait for 24h. it can find all the blocks into 1 hour
unless there is a real problem, don't know
just wait for 24h. it can find all the blocks into 1 hour
unless there is a real problem, don't know
Yeah, without being able to get the networkhash rate, I have no idea what kind of blocks/hr (blocks/day) I should be seeing on 2000 Mh/s.
There's gotta be something I'm missing... ?
I managed to find four blocks in the past 5 days with my piddly 120 MH/s running only parttime (~10hr day), so that should give you some indication.
I think that is actually quite a bit above average, so maybe I just took all your luck. This is with cgminer btw.
Re: [163GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Re: [150GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Well, I've restarted p2pool this morning at 0900 GMT+1, tomorrow I'll let you know what numbers I see.
regards.
spiccioli
Here we are, 20 hours later,
Code:
09:35:21.192503 GOT SHARE! cccccc 2a50469e prev ee4e3887 age 28.24s DEAD ON ARRIVAL
10:51:29.609170 GOT SHARE! cccccc ae20489a prev f5036a0c age 22.39s DEAD ON ARRIVAL
11:00:45.274799 GOT SHARE! cccccc 7ae24ef4 prev b1d8d61a age 20.28s DEAD ON ARRIVAL
11:30:42.989054 GOT SHARE! cccccc 1fb89a27 prev 0af6c699 age 29.78s DEAD ON ARRIVAL
11:38:33.196739 GOT SHARE! cccccc 2ffce415 prev 2c561f75 age 20.60s DEAD ON ARRIVAL
12:20:52.215387 GOT SHARE! cccccc 2deeb628 prev 21ff2b7b age 13.81s DEAD ON ARRIVAL
13:40:47.230481 GOT SHARE! cccccc 1aef7202 prev 1c4d5fe3 age 20.82s
14:27:05.064232 GOT SHARE! cccccc 61749cce prev fc90b812 age 23.00s DEAD ON ARRIVAL
14:54:32.934686 GOT SHARE! cccccc bf2761d7 prev 36614893 age 23.06s
15:13:35.412215 GOT SHARE! cccccc 7981f9dc prev eab26f20 age 20.23s DEAD ON ARRIVAL
15:19:06.171630 GOT SHARE! cccccc f46aa885 prev f98f68d2 age 21.07s DEAD ON ARRIVAL
16:28:33.961269 GOT SHARE! cccccc a9dbaaf4 prev 4f3bac03 age 22.01s DEAD ON ARRIVAL
16:43:18.028367 GOT SHARE! cccccc b2ab8707 prev 881e93ba age 21.55s DEAD ON ARRIVAL
16:48:31.739828 GOT SHARE! cccccc 3231a5e2 prev 08075e20 age 34.50s DEAD ON ARRIVAL
17:11:56.867175 GOT SHARE! cccccc fd25a9bd prev 69d47462 age 26.91s DEAD ON ARRIVAL
17:26:35.194804 GOT SHARE! cccccc 640e9ebd prev 5c2e2221 age 11.85s
17:35:39.829151 GOT SHARE! cccccc 582b0db9 prev f452f2f8 age 16.75s
17:41:35.629520 GOT SHARE! cccccc bd41d585 prev 32818a48 age 33.79s DEAD ON ARRIVAL
17:48:58.909271 GOT SHARE! cccccc ee2d6b93 prev 47bb9cfa age 9.51s
19:13:12.722993 GOT SHARE! cccccc 8ef4140e prev a402ee4a age 11.58s DEAD ON ARRIVAL
19:13:50.677687 GOT SHARE! cccccc f09c4eab prev d0613a01 age 28.44s DEAD ON ARRIVAL
19:15:47.942192 GOT SHARE! cccccc f81a2d80 prev 59599851 age 16.00s DEAD ON ARRIVAL
10:51:29.609170 GOT SHARE! cccccc ae20489a prev f5036a0c age 22.39s DEAD ON ARRIVAL
11:00:45.274799 GOT SHARE! cccccc 7ae24ef4 prev b1d8d61a age 20.28s DEAD ON ARRIVAL
11:30:42.989054 GOT SHARE! cccccc 1fb89a27 prev 0af6c699 age 29.78s DEAD ON ARRIVAL
11:38:33.196739 GOT SHARE! cccccc 2ffce415 prev 2c561f75 age 20.60s DEAD ON ARRIVAL
12:20:52.215387 GOT SHARE! cccccc 2deeb628 prev 21ff2b7b age 13.81s DEAD ON ARRIVAL
13:40:47.230481 GOT SHARE! cccccc 1aef7202 prev 1c4d5fe3 age 20.82s
14:27:05.064232 GOT SHARE! cccccc 61749cce prev fc90b812 age 23.00s DEAD ON ARRIVAL
14:54:32.934686 GOT SHARE! cccccc bf2761d7 prev 36614893 age 23.06s
15:13:35.412215 GOT SHARE! cccccc 7981f9dc prev eab26f20 age 20.23s DEAD ON ARRIVAL
15:19:06.171630 GOT SHARE! cccccc f46aa885 prev f98f68d2 age 21.07s DEAD ON ARRIVAL
16:28:33.961269 GOT SHARE! cccccc a9dbaaf4 prev 4f3bac03 age 22.01s DEAD ON ARRIVAL
16:43:18.028367 GOT SHARE! cccccc b2ab8707 prev 881e93ba age 21.55s DEAD ON ARRIVAL
16:48:31.739828 GOT SHARE! cccccc 3231a5e2 prev 08075e20 age 34.50s DEAD ON ARRIVAL
17:11:56.867175 GOT SHARE! cccccc fd25a9bd prev 69d47462 age 26.91s DEAD ON ARRIVAL
17:26:35.194804 GOT SHARE! cccccc 640e9ebd prev 5c2e2221 age 11.85s
17:35:39.829151 GOT SHARE! cccccc 582b0db9 prev f452f2f8 age 16.75s
17:41:35.629520 GOT SHARE! cccccc bd41d585 prev 32818a48 age 33.79s DEAD ON ARRIVAL
17:48:58.909271 GOT SHARE! cccccc ee2d6b93 prev 47bb9cfa age 9.51s
19:13:12.722993 GOT SHARE! cccccc 8ef4140e prev a402ee4a age 11.58s DEAD ON ARRIVAL
19:13:50.677687 GOT SHARE! cccccc f09c4eab prev d0613a01 age 28.44s DEAD ON ARRIVAL
19:15:47.942192 GOT SHARE! cccccc f81a2d80 prev 59599851 age 16.00s DEAD ON ARRIVAL
something is wrong, isn't it? most are dead, and what does that "age" field really mean?
I'm using latest cgminer 2.2.1 on my miner, with I 7 (intensity) and just p2pool, I have a failover pool, to be honest, but with
Code:
"failover-only" : true
inside cgminer.conf.
Any idea?
best regards.
spiccioli.
Your dead share rates seems rather excessive, I haven't had any dead shares myself for two weeks almost (I've only got fairly slow miner though).
I've had bad experience with mixing traditional pool and p2pool with cgminer. Not sure what the logic behind it is, but in my case it ended up using long polling connection to traditional pool while doing work for p2pool. Since the polling cycle on p2pool is a lot faster than normal pools this leads to (possibly very) high stale/dead shares.
Normally you will see 'LONGPOLL requested work restart..' every couple of seconds with p2pool. If you're not seeing that, it might be this long polling issue. I'd try with just one pool configured.
Second thing I'd look at is if the host running your p2pool daemon is not too overloaded.