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

[Rogue Star]

if ur bitcoind isnt synced u get 100% orphan

obviously, but what are the effects on p2pool as a whole? does it report orphaned shares correctly in this scenario, are there other effects?

[K1773R]

if ur bitcoind isnt synced u get 100% orphan

obviously, but what are the effects on p2pool as a whole? does it report orphaned shares correctly in this scenario, are there other effects?

% of orphan increases @ stats?! yes it does "report" them correctly. a side effect would be the wasted traffic, altough this isnt much.

[mdude77]

I am.  It doesn't make sense to use p2pool w/o supporting the author.  And the 0.5% "fee" on bitminter is so I have access to API stats.  In my mind, bitminter comes out ahead.

M

You could have chosen a 0.5% donation to forrestv. The fee comparison is not valid.

and I could go zero on both.

in my mind, the minimum for both is 1% for p2pool, and 0.5% for bitminer.

M

[Prattler]

p2pool's main problem is being penalized for including transactions.

P2pool miners are protecting the network against >50% attacks. That is a HUGE benefit for the bitcoin network.

Most p2pool users don't have the powerful servers and gigabit internet connections, so they should not include every possible 0-fee or 0.0005 BTC/kB transaction. It's not a huge problem if we leave that to the centralized pools.

the bonus for solving a block should be the entirety of the transaction fees instead of what it is now... simple fix

Very good idea!

[kano]

p2pool's main problem is being penalized for including transactions.

P2pool miners are protecting the network against >50% attacks. That is a HUGE benefit for the bitcoin network.

Although the concept sounds good, since p2pool is only around 300-400GH/s - it really isn't protecting anything

... and if p2pool miners do as you suggest below, the larger pools, that include more transactions, are indeed better for BTC ...

Most p2pool users don't have the powerful servers and gigabit internet connections, so they should not include every possible 0-fee or 0.0005 BTC/kB transaction. It's not a huge problem if we leave that to the centralized pools.

[Red Emerald]

p2pool's main problem is being penalized for including transactions.

P2pool miners are protecting the network against >50% attacks. That is a HUGE benefit for the bitcoin network.

Although the concept sounds good, since p2pool is only around 300-400GH/s - it really isn't protecting anything

... and if p2pool miners do as you suggest below, the larger pools, that include more transactions, are indeed better for BTC ...

Most p2pool users don't have the powerful servers and gigabit internet connections, so they should not include every possible 0-fee or 0.0005 BTC/kB transaction. It's not a huge problem if we leave that to the centralized pools.

And I thought forrest made it so that the transactions are really quickly between peers anyways, so are miners really still being penalized?

[zvs]

p2pool's main problem is being penalized for including transactions.

P2pool miners are protecting the network against >50% attacks. That is a HUGE benefit for the bitcoin network.

Although the concept sounds good, since p2pool is only around 300-400GH/s - it really isn't protecting anything

... and if p2pool miners do as you suggest below, the larger pools, that include more transactions, are indeed better for BTC ...

Most p2pool users don't have the powerful servers and gigabit internet connections, so they should not include every possible 0-fee or 0.0005 BTC/kB transaction. It's not a huge problem if we leave that to the centralized pools.

And I thought forrest made it so that the transactions are really quickly between peers anyways, so are miners really still being penalized?

i'd think that it would be moved in a way that wouldnt involve that much more data, but you can see a clear difference in orphans when you set your blocksize to 1000 vs 250000.    though i'd go for something like 5000 so it can cherry pick the occasional huge fees.

anyway, re: memory leak, check this bad boy out:

http://5.9.157.150:9332/static/graphs.html?Month

maybe it has something to do with DOA shares?

[K1773R]

p2pool's main problem is being penalized for including transactions.

P2pool miners are protecting the network against >50% attacks. That is a HUGE benefit for the bitcoin network.

Although the concept sounds good, since p2pool is only around 300-400GH/s - it really isn't protecting anything

... and if p2pool miners do as you suggest below, the larger pools, that include more transactions, are indeed better for BTC ...

Most p2pool users don't have the powerful servers and gigabit internet connections, so they should not include every possible 0-fee or 0.0005 BTC/kB transaction. It's not a huge problem if we leave that to the centralized pools.

And I thought forrest made it so that the transactions are really quickly between peers anyways, so are miners really still being penalized?

i'd think that it would be moved in a way that wouldnt involve that much more data, but you can see a clear difference in orphans when you set your blocksize to 1000 vs 250000.    though i'd go for something like 5000 so it can cherry pick the occasional huge fees.

anyway, re: memory leak, check this bad boy out:

http://5.9.157.150:9332/static/graphs.html?Month

maybe it has something to do with DOA shares?

is your node public? interested in stats.

[zvs]

p2pool's main problem is being penalized for including transactions.

P2pool miners are protecting the network against >50% attacks. That is a HUGE benefit for the bitcoin network.

Although the concept sounds good, since p2pool is only around 300-400GH/s - it really isn't protecting anything

... and if p2pool miners do as you suggest below, the larger pools, that include more transactions, are indeed better for BTC ...

Most p2pool users don't have the powerful servers and gigabit internet connections, so they should not include every possible 0-fee or 0.0005 BTC/kB transaction. It's not a huge problem if we leave that to the centralized pools.

And I thought forrest made it so that the transactions are really quickly between peers anyways, so are miners really still being penalized?

i'd think that it would be moved in a way that wouldnt involve that much more data, but you can see a clear difference in orphans when you set your blocksize to 1000 vs 250000.    though i'd go for something like 5000 so it can cherry pick the occasional huge fees.

anyway, re: memory leak, check this bad boy out:

http://5.9.157.150:9332/static/graphs.html?Month

maybe it has something to do with DOA shares?

is your node public? interested in stats.

i put it back up about 4-5 hours ago, not mining on it again yet, though.. just for a relay...  it's @ http://nogleg.com:9332

[Rogue Star]

obviously, but what are the effects on p2pool as a whole? does it report orphaned shares correctly in this scenario, are there other effects?

% of orphan increases @ stats?! yes it does "report" them correctly. a side effect would be the wasted traffic, altough this isnt much.

well they certainly aren't reported on the local graphs, otherwise it would show a much higher waste rate in the mining graphs, so that's one of the reasons I ask. i suppose it makes sense since you can't fully verify a share until it's been included in the sharechain. the other reason I ask is the variance we see when there are problems with the nodes/sharechain seem to imply that the orphan/dead rate perhaps isn't reported correctly.

another question I had was if sharechain 11 is a hardfork, why does p2pool still connect to clients on sharechain 9 after the fork?

i've updated from Ubuntu Server x64 12.04 LTS to 12.10 and I'm still seeing the memory leak and increased orphaned/dead as i approach a day of node uptime. The leak appears to start after about 12 hour, although it's not as pronounced as on 12.04 LTS.

[forrestv]

obviously, but what are the effects on p2pool as a whole? does it report orphaned shares correctly in this scenario, are there other effects?

% of orphan increases @ stats?! yes it does "report" them correctly. a side effect would be the wasted traffic, altough this isnt much.

well they certainly aren't reported on the local graphs, otherwise it would show a much higher waste rate in the mining graphs, so that's one of the reasons I ask. i suppose it makes sense since you can't fully verify a share until it's been included in the sharechain. the other reason I ask is the variance we see when there are problems with the nodes/sharechain seem to imply that the orphan/dead rate perhaps isn't reported correctly.

another question I had was if sharechain 11 is a hardfork, why does p2pool still connect to clients on sharechain 9 after the fork?

i've updated from Ubuntu Server x64 12.04 LTS to 12.10 and I'm still seeing the memory leak and increased orphaned/dead as i approach a day of node uptime. The leak appears to start after about 12 hour, although it's not as pronounced as on 12.04 LTS.

Versions 10 and 11 were not hardforks. They triggered the upgrade notifications, but there was no switchover to cut version 9's off.

I'm investigating the memory leak; one person experiencing it gave me SSH access and I'm waiting for it to occur. If anyone else wants to lend SSH access, that would be helpful too.

[zvs]

obviously, but what are the effects on p2pool as a whole? does it report orphaned shares correctly in this scenario, are there other effects?

% of orphan increases @ stats?! yes it does "report" them correctly. a side effect would be the wasted traffic, altough this isnt much.

well they certainly aren't reported on the local graphs, otherwise it would show a much higher waste rate in the mining graphs, so that's one of the reasons I ask. i suppose it makes sense since you can't fully verify a share until it's been included in the sharechain. the other reason I ask is the variance we see when there are problems with the nodes/sharechain seem to imply that the orphan/dead rate perhaps isn't reported correctly.

another question I had was if sharechain 11 is a hardfork, why does p2pool still connect to clients on sharechain 9 after the fork?

i've updated from Ubuntu Server x64 12.04 LTS to 12.10 and I'm still seeing the memory leak and increased orphaned/dead as i approach a day of node uptime. The leak appears to start after about 12 hour, although it's not as pronounced as on 12.04 LTS.

Versions 10 and 11 were not hardforks. They triggered the upgrade notifications, but there was no switchover to cut version 9's off.

I'm investigating the memory leak; one person experiencing it gave me SSH access and I'm waiting for it to occur. If anyone else wants to lend SSH access, that would be helpful too.

well, I know if you start p2pool with tons of old share files, it'll start you out at like 500MB+ memory usage.   it'll say something like 35000/35000 shares verified and it'll gradually start removing the old share files, but your memory usage will still stay at 500MB

[spiccioli]

I'm investigating the memory leak; one person experiencing it gave me SSH access and I'm waiting for it to occur. If anyone else wants to lend SSH access, that would be helpful too.

forrestv,

this is my public p2pool entry point at p2pool.soon.it:9332 after 10 days

Code:

Date	Memory Usage/(B)
Wed Jan 23 2013 07:00:00 GMT+0100 (ora solare Europa occidentale)	576M
Tue Jan 22 2013 14:12:00 GMT+0100 (ora solare Europa occidentale)	578M
Mon Jan 21 2013 21:24:00 GMT+0100 (ora solare Europa occidentale)	578M
Mon Jan 21 2013 04:36:00 GMT+0100 (ora solare Europa occidentale)	570M
Sun Jan 20 2013 11:48:00 GMT+0100 (ora solare Europa occidentale)	570M
Sat Jan 19 2013 19:00:00 GMT+0100 (ora solare Europa occidentale)	570M
Sat Jan 19 2013 02:12:00 GMT+0100 (ora solare Europa occidentale)	570M
Fri Jan 18 2013 09:24:00 GMT+0100 (ora solare Europa occidentale)	570M
Thu Jan 17 2013 16:36:00 GMT+0100 (ora solare Europa occidentale)	570M
Wed Jan 16 2013 23:48:00 GMT+0100 (ora solare Europa occidentale)	570M
Wed Jan 16 2013 07:00:00 GMT+0100 (ora solare Europa occidentale)	580M
Tue Jan 15 2013 14:12:00 GMT+0100 (ora solare Europa occidentale)	518M
Mon Jan 14 2013 21:24:00 GMT+0100 (ora solare Europa occidentale)	518M
Mon Jan 14 2013 04:36:00 GMT+0100 (ora solare Europa occidentale)	511M
Sun Jan 13 2013 11:48:00 GMT+0100 (ora solare Europa occidentale)	416M
Sat Jan 12 2013 19:00:00 GMT+0100 (ora solare Europa occidentale)	335M
Sat Jan 12 2013 02:12:00 GMT+0100 (ora solare Europa occidentale)	275M
Fri Jan 11 2013 09:24:00 GMT+0100 (ora solare Europa occidentale)	276M
Thu Jan 10 2013 16:36:00 GMT+0100 (ora solare Europa occidentale)	178M
Wed Jan 09 2013 23:48:00 GMT+0100 (ora solare Europa occidentale)	0.00
Wed Jan 09 2013 07:00:00 GMT+0100 (ora solare Europa occidentale)	0.00

as you can see memory seems to have reached a maximum around 580 Mb.

I'm using python here but I've also used pypy in the past when I was experiencing high memory usage.

I'm going to restart it with pypy just to see if it makes any difference at all.

This is a fedora 16, 32 bit system with PAE and 6 GB of ram.

Regards.

spiccioli.

ps. memory usage does not work on freebsd (I've got a system running because I really like the zfs filesystem )

[spiccioli]

I agree, my problems started with v10 also, and got worse with v11 - which also matches up with the beginning of the bad luck streak. It's just too coincidental me thinks........everything before v10 was grand.......but hey, I'm a noob, and I'm not kidding when I say I still have a lot to learn about this. But just look at that chart - something's wrong.

PatMan,

still so sure something is wrong?

peace.

spiccioli

[stevegee58]

I agree, my problems started with v10 also, and got worse with v11 - which also matches up with the beginning of the bad luck streak. It's just too coincidental me thinks........everything before v10 was grand.......but hey, I'm a noob, and I'm not kidding when I say I still have a lot to learn about this. But just look at that chart - something's wrong.

PatMan,

still so sure something is wrong?

peace.

spiccioli

Beware of people who use phrases like "me thinks" 

[organofcorti]

I agree, my problems started with v10 also, and got worse with v11 - which also matches up with the beginning of the bad luck streak. It's just too coincidental me thinks........everything before v10 was grand.......but hey, I'm a noob, and I'm not kidding when I say I still have a lot to learn about this. But just look at that chart - something's wrong.

PatMan,

still so sure something is wrong?

peace.

spiccioli

Beware of people who use phrases like "me thinks" 

Because they're pirates, right?

[BitcoinOxygen]

I agree, my problems started with v10 also, and got worse with v11 - which also matches up with the beginning of the bad luck streak. It's just too coincidental me thinks........everything before v10 was grand.......but hey, I'm a noob, and I'm not kidding when I say I still have a lot to learn about this. But just look at that chart - something's wrong.

PatMan,

still so sure something is wrong?

peace.

spiccioli

Beware of people who use phrases like "me thinks" 

Because they're pirates, right?

[BitcoinOxygen]

[Aseras]

I agree, my problems started with v10 also, and got worse with v11 - which also matches up with the beginning of the bad luck streak. It's just too coincidental me thinks........everything before v10 was grand.......but hey, I'm a noob, and I'm not kidding when I say I still have a lot to learn about this. But just look at that chart - something's wrong.

PatMan,

still so sure something is wrong?

peace.

spiccioli

One does not even infer mentioning the L word. Even indirectly. Silence.

[organofcorti]

I agree, my problems started with v10 also, and got worse with v11 - which also matches up with the beginning of the bad luck streak. It's just too coincidental me thinks........everything before v10 was grand.......but hey, I'm a noob, and I'm not kidding when I say I still have a lot to learn about this. But just look at that chart - something's wrong.

PatMan,

still so sure something is wrong?

peace.

spiccioli

One does not even infer mentioning the L word. Even indirectly. Silence.

You mean "landlubber", right?