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

[KyrosKrane]

yes of course, running a second is impossible
[ /quote]

What about chrooted bitcoind? Put it in jail perhaps

Why would you want two separate bitcoind's on the same machine? What problem are you trying to solve?

[1714216978]

1714216978

[1714216978]

1714216978

[1714216978]

1714216978

[1714216978]

1714216978

[1714216978]

1714216978

[HellDiverUK]

So, I can use one bitcoind to both run as a full Bitcoin node, AND also run a p2pool node? 

[jedimstr]

So, I can use one bitcoind to both run as a full Bitcoin node, AND also run a p2pool node? 

Yup

[mdude77]

Another thing I'd add to the list...

Fix being able to get lots of transactions without GetBlocktemplate Latency going through the roof.  OR something that alleviates the problem.  Long term p2pool isn't going to cut it if it can't get transactions.

M

Is that reliant on bitcoind only or also peers? I've been doing some tuning of bitcoind but struggle to keep it below 0.5 secs and not topping 1s.
Is that a bitcoind issue or a p2pool issue?

Its not p2pool issue, use ssd disk and should be able to put
blockprioritysize=0
#blockminsize=2000
blockmaxsize=1000000
mintxfee=0.00001
minrelaytxfee=0.00001

With just 0.2s, with merged mining namecoin, fusioncoin, ixcoin and devcoin

I don't have control over the disk being used, as I'm using a VPS.  My maxconn is at 50, though, maybe that's my issue.  I'll tweak it and see what happens.

Thanks!

M

[nreal]

yes of course, running a second is impossible
[ /quote]

What about chrooted bitcoind? Put it in jail perhaps

Why would you want two separate bitcoind's on the same machine? What problem are you trying to solve?

You can run one instance for mining --without-wallet and other for coins maybe, security..

[jedimstr]

yes of course, running a second is impossible
[ /quote]

What about chrooted bitcoind? Put it in jail perhaps

Why would you want two separate bitcoind's on the same machine? What problem are you trying to solve?

You can run one instance for mining --without-wallet and other for coins maybe?

1. Why?
2. Port contention issues.
3. Space Issues (inefficient use of space to have two Blockchains stored and sharing a Blockchain between two daemons is not advisable)
3. Why again?

Just run one... there's no reason to run two instances of Bitcoin Core on same box.

Usual caveats apply regarding Merged Coins and co-existing *coind instances...blah blah..

[nreal]

"Just run one... there's no reason to run two instances of Bitcoin Core on same box."

Theres plenty of reasons, but it can be done with just one...

[jedimstr]

"Just run one... there's no reason to run two instances of Bitcoin Core on same box."

Theres plenty of reasons, but it can be done with just one...

So... what are they?  If it can be done with just one, then it really isn't a reason to run two or more.

[jedimstr]

So now that there are more eyes looking at P2Pool's code... and talk of brainstorming the BIG fix items like variance for smaller miners...

I'd like to make a teensy tiny request... from forrestv, the Templar Crypto Research team, or anyone really...

Could someone fix the Memory Usage graph so that it can actually work on anything other than Linux? 

This is what it looks like on a Mac and Windows (minus my big red arrow and commentary):

[norgan]

So now that there are more eyes looking at P2Pool's code... and talk of brainstorming the BIG fix items like variance for smaller miners...

I'd like to make a teensy tiny request... from forrestv, the Templar Crypto Research team, or anyone really...

Could someone fix the Memory Usage graph so that it can actually work on anything other than Linux? 

This is what it looks like on a Mac and Windows (minus my big red arrow and commentary):

Haha I run windows servers and have the same issue. I'm also lucky enough to not really be resource restrained so not a huge issue for me. I agree it would be nice but you'd have to write WMI for windows and god knows what for mac. Essentially though mac is Linux, well close enough, so the task should be somewhat easier.

I was looking at some powershell stuff to feed into the p2pool front end to report on server stats but my coding knowledge just isn't that great.

[cathoderay]

This was supposedly fixed April 2013 - I'd check your setup:

https://bitcointalk.org/index.php?topic=18313.msg1978587#msg1978587

[norgan]

This was supposedly fixed April 2013 - I'd check your setup:

https://bitcointalk.org/index.php?topic=18313.msg1978587#msg1978587

it obviously got broken again or there is some requirement we are missing.

[jedimstr]

This was supposedly fixed April 2013 - I'd check your setup:

https://bitcointalk.org/index.php?topic=18313.msg1978587#msg1978587

it obviously got broken again or there is some requirement we are missing.

Yup, that fix didn't stay fixed.  And it was only for windows.  Mac nodes are still sans memory usage graph. 

Not a huge deal for me either.... I've got 32GB on the box running my node. I just hate seeing a blank graph. Hence the "teensy tiny" request

[mdude77]

I updated the front end to my p2pool node to use Norgan's code.  Looks good, thank you Norgan!

M

[zvs]

"Just run one... there's no reason to run two instances of Bitcoin Core on same box."

Theres plenty of reasons, but it can be done with just one...

So... what are they?  If it can be done with just one, then it really isn't a reason to run two or more.

Modifications to the conf file (and/or source code) for p2pool purposes only, i.e. limitfreerelay, changes to mintxfee, etc.  If you have enough memory on your system, there are lots of things you could do to make it run faster.

Also, a p2pool bitcoind only needs 2 connections, one to your p2pool and the other to a single node.  I used to connect my p2pool bitcoind to 5.9.24.81 only.

Sun Jun 22 2014 11:59:24 GMT+0300 (EEST)   0.0489
Sun Jun 22 2014 11:56:36 GMT+0300 (EEST)   0.0662
Sun Jun 22 2014 11:53:48 GMT+0300 (EEST)   0.0334
Sun Jun 22 2014 11:51:00 GMT+0300 (EEST)   0.0242
Sun Jun 22 2014 11:48:12 GMT+0300 (EEST)   0.0162
Sun Jun 22 2014 11:45:24 GMT+0300 (EEST)   0.0175

This is getblocktemplate latency with 0.0001 fees...

Turn off all free transactions if they aren't already & increase fees to .00011.  Seems like a decent compromise to me.

Getblocktemplate latency isn't a huge deal, anyway... err, well, it is if those numbers are in seconds.  Shouldn't worry about it if it's 500ms or less, though.

ed:  Oh, and you do want minblocksize (or blockminsize?  been a while) set to 0, to get rid of all the free transactions.

I don't have control over the disk being used, as I'm using a VPS.  My maxconn is at 50, though, maybe that's my issue.  I'll tweak it and see what happens.

Thanks!

M

I already told you to do all that stuff a month or two ago, if it's the same project we're talking about, heh..  It won't have any impact on memory usage really, but you only need 2 connections on your bitcoind.

[Collider]

Hey guys, i have a technical question concerning p2pool.

While shares can quite easily be DOA because of the ~60times faster sharechain, found bitcoin blocks shouldn´t become dead/orphaned that quickly, as they are then broadcast on to the Bitcoin network.

So what happens, when my found share would be a Bitcoin block but the p2pool node considers it a "late" share? Is it still passed on to the Bitcoin network?

[zvs]

Hey guys, i have a technical question concerning p2pool.

While shares can quite easily be DOA because of the ~60times faster sharechain, found bitcoin blocks shouldn´t become dead/orphaned that quickly, as they are then broadcast on to the Bitcoin network.

So what happens, when my found share would be a Bitcoin block but the p2pool node considers it a "late" share? Is it still passed on to the Bitcoin network?

Yes, but it won't show up in the p2pool block list, either.... and you won't get the .5% bonus for it, just the "normal" amount earned.

... also why no-submit-stale is bad to use with p2pool.

[Collider]

Thanks, so if you had the no-submit-stale option turned on, it wouldn´t submit valid Bitcoin blocks that are not considered a valid share?

Isn´t there some mechanism every node immediatly recognizes a valid block as such, as every node runs the full Bitcoin client?

[zvs]

Thanks, so if you had the no-submit-stale option turned on, it wouldn´t submit valid Bitcoin blocks that are not considered a valid share?

Isn´t there some mechanism every node immediatly recognizes a valid block as such, as every node runs the full Bitcoin client?

I could be wrong here since it's been so long since I've mined on a p2pool with block times (ed: *over* a minute that is) under a minute, but I think it only detects the stale shares after a block.... but all shares should be submitted, as some share that's detected as stale (say, 1ms to 500ms late) could easily win an orphan race, esp. vs some of the pools that aren't set up quite right (propagate their blocks slowly).

from personal experience, I've had a share that was detected as DOA solve a bitcoin block, back in 2012

[Collider]

Thanks, so if you had the no-submit-stale option turned on, it wouldn´t submit valid Bitcoin blocks that are not considered a valid share?

Isn´t there some mechanism every node immediatly recognizes a valid block as such, as every node runs the full Bitcoin client?

I could be wrong here since it's been so long since I've mined on a p2pool with block times (ed: *over* a minute that is) under a minute, but I think it only detects the stale shares after a block.... but all shares should be submitted, as some share that's detected as stale (say, 1ms to 500ms late) could easily win an orphan race, esp. vs some of the pools that aren't set up quite right (propagate their blocks slowly).

from personal experience, I've had a share that was detected as DOA solve a bitcoin block, back in 2012

Thanks again. Is the option to not send invalid shares in your miner or on the node?
It seems like it should be a setting in the miner...