[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[rav3n_pl]

Wow, I never thought about mining directly to something else than my wallet...

How about satoshi dice?
(but where would it send it back to )

That would be interesting, prize it would be gone or split among miners like block or what? ;]

[RandomQ]

There is no real difference between transferring through a client or transferring directly generated coins. They all land on the address you chose. I guess it is a glitch on Vircurex' side. What exactly did they answer?

Ente

Yes. We are using the standard wallets for the various coins and these wallets dont offer any feature to match generated coins against an address, i.e. we cannot match generated coins against the respective user account.
 
Please do not mine against a Vircurex address.  I'll spend some time today to manuall look through the blockchain and figure out how many coins you have so far mined against your address below.  This will take quite a bit so please bear with me,

I was lazy and never thought it would be a problem lol.
But I have p2pool litecoin pool setup and now i'm just mining @ the litecoin daemon main address

Has anyone Used Reaper and p2pool LTC yet?

[ragnard]

Has anyone Used Reaper and p2pool LTC yet?

I am using reaper to mine LTC to my p2pool instance for the past couple weeks.  It is working great.

[ThiagoCMC]

Has anyone Used Reaper and p2pool LTC yet?

I am using reaper to mine LTC to my p2pool instance for the past couple weeks.  It is working great.

Me too...

[rav3n_pl]

Has anyone Used Reaper and p2pool LTC yet?

I am using reaper to mine LTC to my p2pool instance for the past couple weeks.  It is working great.

Me too...

Me three
http://rav3n.dtdns.net:9327/

My config that works overnight (HD6770 ~180kh 5% stales)
reaper.conf

Code:

kernel reaper.cl
save_binaries yes
enable_graceful_shutdown yes
long_polling yes
cpu_mining_threads 0
device 0
mine litecoin

litecoin.conf

Code:

host rav3n.dtdns.net
port 9327
user rav3n
pass nn
protocol litecoin
worksize 256
aggression 16
threads_per_gpu 1
sharethreads 4
lookup_gap 2
gpu_thread_concurrency 6400
device 0

On aggression 11 i have about 110kh and can use my pc normally, even play 3d games.

[joemde]

It's a good week to mine p2pool!!!

[jackmaninov]

It's a good week to mine p2pool!!!

Hush!

[TheHarbinger]

It's a good week to mine p2pool!!!

[joemde]

Lol past performance is no indication of future success. I was simply happy to have made some coins this week  . Sorry  .... note to self ...... skip sharing happiness with others .....

On a different note, the stats webpage will not load for me today from any comp I have. Does anyone know what's up?

[mdude77]

Lol past performance is no indication of future success. I was simply happy to have made some coins this week  . Sorry  .... note to self ...... skip sharing happiness with others .....

On a different note, the stats webpage will not load for me today from any comp I have. Does anyone know what's up?

Not loading for me either.  Something must be wrong with it.

I'm glad to see some good returns finally on p2pool.  Makes up for those block-every-24-hours days.

M

[twmz]

On a different note, the stats webpage will not load for me today from any comp I have. Does anyone know what's up?

Temporary fix is in place.  A better fix in the works that should also improve performance.

[joemde]

On a different note, the stats webpage will not load for me today from any comp I have. Does anyone know what's up?

Temporary fix is in place.  A better fix in the works that should also improve performance.

Awesome!! The local stats page is good but it just feels better when the main stats page works.

[Schleicher]

I'm trying to compile the litecoin stuff for p2pool.
I'm getting this:

Code:

c:\mingw\bin\gcc.exe -shared -s build\temp.win-amd64-2.7\Release\scryptmodule.o build\temp.win-amd64-2.7\Release\scrypt.o build\temp.win-amd64-2.7\Release\ltc_scrypt.def -LC:\Python27-64\libs -LC:\Python27-64\PCbuild\amd64 -lpython27 -lmsvcr90 -o build\lib.win-amd64-2.7\ltc_scrypt.pyd
scryptmodule.c: In function 'scrypt_getpowhash':
scryptmodule.c:15:5: warning: implicit declaration of function 'scrypt_1024_1_1_256' [-Wimplicit-function-declaration]
build\temp.win-amd64-2.7\Release\scryptmodule.o:scryptmodule.c:(.text+0x1e): undefined reference to `__imp__PyArg_ParseTuple'
build\temp.win-amd64-2.7\Release\scryptmodule.o:scryptmodule.c:(.text+0x35): undefined reference to `__imp__PyMem_Malloc'
build\temp.win-amd64-2.7\Release\scryptmodule.o:scryptmodule.c:(.text+0x44): undefined reference to `__imp__PyString_AsString'
build\temp.win-amd64-2.7\Release\scryptmodule.o:scryptmodule.c:(.text+0x83): undefined reference to `__imp__Py_BuildValue'
build\temp.win-amd64-2.7\Release\scryptmodule.o:scryptmodule.c:(.text+0x8e): undefined reference to `__imp__PyMem_Free'
build\temp.win-amd64-2.7\Release\scryptmodule.o:scryptmodule.c:(.text+0xcd): undefined reference to `__imp__Py_InitModule4'
collect2.exe: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

Any idea why?

[mdude77]

On a different note, the stats webpage will not load for me today from any comp I have. Does anyone know what's up?

Temporary fix is in place.  A better fix in the works that should also improve performance.

I was wondering how this page calculates the performance of finding blocks (7 days, 30 days, 90 days).  Is it based upon when the block is found, or the average for the block?

For example, let's say the hash rate for the pool was 300g/h.  It was a long block, and a bunch of people gave up before it was found.  When it was found, we were at 250g/h.  If the performance is based upon when it was found, it would look like we did better than reality, because it would take longer at 250 than it would at 300, when in reality, we were at 300 for most of the time of the block.

Conversely, if were at 250g/h and then suddenly jumped to 300 and found a block, it would look like we did worse than reality, because it would be shorter at 300 than it was at 250.

Since the hash rates seems to swing wildly from 200 to 300, I thought I'd ask.  If it's based on the time the block was found, it needs to be taken with a grain of salt.

Right?

M

[twmz]

I was wondering how this page calculates the performance of finding blocks (7 days, 30 days, 90 days).  Is it based upon when the block is found, or the average for the block?

Pool hashrate is sampled every 5 minutes, and the luck estimate/calculation uses the average of those samples over the duration of the round.

The fact that pool hashrate is sampled every 5 minutes is actually the reason the page loads so slowly (there are a zillion 5 minute data points between now and last february when I started collecting 5 minute samples).  The 5 minute sample are useful for the luck calculation, but the graph doesn't really need to be that precise so I will be changing JSON API to return fewer data points to the graph which will cut down the time for the page to load (block luck calculations happen on the server and will still use the 5 minute samples).

[louisBSAS]

Great day yesterday.  I have been mining for a month now, and P2Pool seems to beat other pools. Cudos!

I have been running just shy of 2Gh for over a week- non-stop. "current payout" listed at around .15at first, then .41 (after 4 days), now .28 to .33.

I have been trying to figure out how the payout amount is calculated and such.  All in all, it seems fair according to pool speed.

Question:

Over 8 hours while I slept, I gained 22 shares in 8 hours.. I had 418 when I woke up 5 hours ago - now I have 419 (in 5 hours time).
Orphans and 'Dead' have not changed  and 'expected time to share:' continues to be between 18 and 22 minutes.

Any ideas?

--
Running 2 rigs piped into P2Pool/Bitcoin running on a non-mining machine - all Linux
No changes in configuration at all - so, that can't be the cause.

Thanks ahead of time.

[zvs]

Great day yesterday.  I have been mining for a month now, and P2Pool seems to beat other pools. Cudos!

I have been running just shy of 2Gh for over a week- non-stop. "current payout" listed at around .15at first, then .41 (after 4 days), now .28 to .33.

I have been trying to figure out how the payout amount is calculated and such.  All in all, it seems fair according to pool speed.

Question:

Over 8 hours while I slept, I gained 22 shares in 8 hours.. I had 418 when I woke up 5 hours ago - now I have 419 (in 5 hours time).
Orphans and 'Dead' have not changed  and 'expected time to share:' continues to be between 18 and 22 minutes.

Any ideas?

--
Running 2 rigs piped into P2Pool/Bitcoin running on a non-mining machine - all Linux
No changes in configuration at all - so, that can't be the cause.

Thanks ahead of time.

Just crap luck, I'd guess.  I run between 4-6GH/s on p2pool and there have been times where I've gone over an hr between shares.   

[rav3n_pl]

Look at week stats. One day is not enough to make any close estimations.
On my crappy 150MH there was days i not get even one share, then 3 in hour. Just luck

[kano]

I was wondering how this page calculates the performance of finding blocks (7 days, 30 days, 90 days).  Is it based upon when the block is found, or the average for the block?

Pool hashrate is sampled every 5 minutes, and the luck estimate/calculation uses the average of those samples over the duration of the round.

The fact that pool hashrate is sampled every 5 minutes is actually the reason the page loads so slowly (there are a zillion 5 minute data points between now and last february when I started collecting 5 minute samples).  The 5 minute sample are useful for the luck calculation, but the graph doesn't really need to be that precise so I will be changing JSON API to return fewer data points to the graph which will cut down the time for the page to load (block luck calculations happen on the server and will still use the 5 minute samples).

Yes but hash rate is an estimate ...
Really it should keep the history of shares and use that - which is accurate.
Shares is the only accurate measurement of a pool.

[twmz]

I was wondering how this page calculates the performance of finding blocks (7 days, 30 days, 90 days).  Is it based upon when the block is found, or the average for the block?

Pool hashrate is sampled every 5 minutes, and the luck estimate/calculation uses the average of those samples over the duration of the round.

The fact that pool hashrate is sampled every 5 minutes is actually the reason the page loads so slowly (there are a zillion 5 minute data points between now and last february when I started collecting 5 minute samples).  The 5 minute sample are useful for the luck calculation, but the graph doesn't really need to be that precise so I will be changing JSON API to return fewer data points to the graph which will cut down the time for the page to load (block luck calculations happen on the server and will still use the 5 minute samples).

Yes but hash rate is an estimate ...
Really it should keep the history of shares and use that - which is accurate.
Shares is the only accurate measurement of a pool.

I agree completely that in a perfect world that would be better.  I just don't care about the difference enough to invest my free time to make the substantial changes required to make that work.  If someone else wants to do it and provide me a JSON feed of p2pool blocks along with the actual number of diff 1 shares that went into that block, I'm happy to replace the current hashrate based estimates.