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

[mdude77]

good discussion,
I say'd there must be at  problem but
Everybody say'd theres no problem with p2pool...

Fix the Problem....

I was using p2pool for the last couple weeks with no issues whatsoever with my measly 7.6gh.  On a different coin atm.

EDIT: I'm of the opinion that p2pool is more bandwidth constrained that one might think.  I was running below pool stale rate the whole time by running p2pool and bitcoin on an SSD and having ALL port forwarding turned off, default settings everywhere else.  The only time my stale rate started to climb is when I was downloading something for an extended period of time that saturated my bandwidth.  I have 3mb down and 768kb up (adsl).

On the other coin I'm using atm, I'm seeing the same, I'm below pool stale rate, regularly significantly lower.

M

[1714205750]

1714205750

[1714205750]

1714205750

[1714205750]

1714205750

[gyverlb]

Agreed. One shouldn't have to start tampering with the transaction settings to get p2pool working optimally, but at the detriment of bitcoin itself, it should just work properly out of the box. I believe if p2pool was rewritten in C or C++ it would not only be more cross platform compatible than python, but it would also definitely make it easier to pinpoint the stratum issue that I have been banging on about ever since it's introduction, simply because it is more widely understood and used by programmers/coders. Of which I am not one 

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

[Searinox]

I always find it weird how my P2Pool hashrate keeps fluctuating even in idle, sometimes reaching as high as 280Mh/s or dropping as low as 110Mh/s. I have my miner set up as recommended for my card. Is there anything I can do about it or is this not the miner/setup's fault and rather p2pool's?

[daemondazz]

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

In any event, you do not need to rewrite the entire application in C/C++, just the module(s) that are time critical and then you can import the compiled C/C++ module into Python using Swig.

[PatMan]

Agreed. One shouldn't have to start tampering with the transaction settings to get p2pool working optimally, but at the detriment of bitcoin itself, it should just work properly out of the box. I believe if p2pool was rewritten in C or C++ it would not only be more cross platform compatible than python, but it would also definitely make it easier to pinpoint the stratum issue that I have been banging on about ever since it's introduction, simply because it is more widely understood and used by programmers/coders. Of which I am not one  

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

With respect, you've never seen any problems. That does not mean that there aren't any.

[mdude77]

Agreed. One shouldn't have to start tampering with the transaction settings to get p2pool working optimally, but at the detriment of bitcoin itself, it should just work properly out of the box. I believe if p2pool was rewritten in C or C++ it would not only be more cross platform compatible than python, but it would also definitely make it easier to pinpoint the stratum issue that I have been banging on about ever since it's introduction, simply because it is more widely understood and used by programmers/coders. Of which I am not one 

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

There is also an issue with p2pool not being to work properly with ASICs, even as small as a jalapeno.

M

[PatMan]

Agreed. One shouldn't have to start tampering with the transaction settings to get p2pool working optimally, but at the detriment of bitcoin itself, it should just work properly out of the box. I believe if p2pool was rewritten in C or C++ it would not only be more cross platform compatible than python, but it would also definitely make it easier to pinpoint the stratum issue that I have been banging on about ever since it's introduction, simply because it is more widely understood and used by programmers/coders. Of which I am not one 

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

There is also an issue with p2pool not being to work properly with ASICs, even as small as a jalapeno.

M

Which highlights the desperate need of a complete rework.

[Amph]

still the best duo for me is cgminer 3.0.1 and p2pool 11.2, much more efficiency and less reject than other

[maqifrnswa]

regarding custom compiled bitcoind for "optimal" p2pool operation

he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu

This is an interesting point: should p2pool be changed so that we take away a miner's freedom to choose what transactions to accept in order to help the bitcoind network?

Summary: by custom tweaking bitcoin code, you can create 0 transaction blocks with tiny p2pool latency. That is great for the individual miner that does it (higher efficiency) but horrible for the bitcoind network (and for other p2pool miners who are "honest"). Galvin Anderson did some calculations to show that the 0 tx strategy is not profitable compared to accepting transactions for solo (or regular pooled) bitcoind mining. I wonder if it's true for p2pool...

Whether it was written in C or python (or intercal), this would be a problem and is a fundamental question.

[gyverlb]

regarding custom compiled bitcoind for "optimal" p2pool operation

he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu

This is an interesting point: should p2pool be changed so that we take away a miner's freedom to choose what transactions to accept in order to help the bitcoind network?

Summary: by custom tweaking bitcoin code, you can create 0 transaction blocks with tiny p2pool latency. That is great for the individual miner that does it (higher efficiency) but horrible for the bitcoind network (and for other p2pool miners who are "honest"). Galvin Anderson did some calculations to show that the 0 tx strategy is not profitable compared to accepting transactions for solo (or regular pooled) bitcoind mining. I wonder if it's true for p2pool...

Whether it was written in C or python (or intercal), this would be a problem and is a fundamental question.

Simply fix bitcoind instead of focusing on p2pool. Giving a block template for p2pool to use should be nearly instantaneous. The problem seems to be that bitcoind rebuilds the whole block template from scratch on each request instead of preparing it in the background. Fix that and nobody will have to tune bitcoind anymore.

[Amph]

the pool is growing pretty well

[wtogami]

A mean average of 0.1 went up to a mean average of over 0.3.....

Which measure is this, the "Bitcoind GetBlockTemplate Latency"?  11.4 here with a mean of 0.0606s over the past 24 hours.

[kano]

...
he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu

Of course he can.

But it also means that what is best for bitcoin is to NOT use p2pool.
The opposite of what is commonly argued.

As the thread title says: Decentralized, DoS-resistant, Hop-Proof pool

Pool mining on a pool that has a block size limit of 500k or 5k, which is better for bitcoin?

So the answer to that is ... it is better for bitcoin to NOT use p2pool since p2pool seems to require it's users to restrict transactions dramatically.

It's a very simple argument.

[mdude77]

...
he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu

Of course he can.

But it also means that what is best for bitcoin is to NOT use p2pool.
The opposite of what is commonly argued.

As the thread title says: Decentralized, DoS-resistant, Hop-Proof pool

Pool mining on a pool that has a block size limit of 500k or 5k, which is better for bitcoin?

So the answer to that is ... it is better for bitcoin to NOT use p2pool since p2pool seems to require it's users to restrict transactions dramatically.

It's a very simple argument.

I function just fine w/o having to restrict transactions at all.  Must be something with his environment.

M

[Krak]

I function just fine w/o having to restrict transactions at all.  Must be something with his environment.

M

He seems to think there's an orphan problem. There's only been 2 orphans in the past 3 months.

[Smoovious]

...
he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu

Of course he can.

But it also means that what is best for bitcoin is to NOT use p2pool.
The opposite of what is commonly argued.

As the thread title says: Decentralized, DoS-resistant, Hop-Proof pool

Pool mining on a pool that has a block size limit of 500k or 5k, which is better for bitcoin?

So the answer to that is ... it is better for bitcoin to NOT use p2pool since p2pool seems to require it's users to restrict transactions dramatically.

It's a very simple argument.

Honestly, the orphan thing has more to do with too many connections on bitcoind than it does on p2pool...

p2pool already goes out of its way to help facilitate found blocks getting distributed as fast as possible, but there is no way you're going to be 100% orphan free with the way the bitcoin network itself operates.

Processing transactions is what mining is all about. Too many have forgotten that, believing that mining is about getting coin, and if you can throw in some transactions while you do it, why not.

But... processing the transactions is what our sole purpose as miners, actually is.

Probably be better off to keep the connection counts down to 2-4 on bitcoind, and low connections on p2pool as well, so we're sending data to less people, allowing them to be sent, faster, and let the meganodes with the bandwidth to handle it, focus on the wide redistribution.

It does no good for a node with a residential-quality upstream, to pass along block data to 50 nodes, if it takes 10 seconds to do it.

The torrent community fights about this too, and the best nodes you find that are sending to you fast, are the ones who aren't trying to keep 500 connections open, giving each peer just a few kB/s at a time, making block propagation just drag out forever, much longer than it should, with extra wasted overhead.

Block propagation suffers the same way. Less really is sometimes more.

-- Smoov

[kano]

...
he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu

Of course he can.

But it also means that what is best for bitcoin is to NOT use p2pool.
The opposite of what is commonly argued.

As the thread title says: Decentralized, DoS-resistant, Hop-Proof pool

Pool mining on a pool that has a block size limit of 500k or 5k, which is better for bitcoin?

So the answer to that is ... it is better for bitcoin to NOT use p2pool since p2pool seems to require it's users to restrict transactions dramatically.

It's a very simple argument.

I function just fine w/o having to restrict transactions at all.  Must be something with his environment.

M

Good counter argument

Edit: meaning - then - that the problem is him and being detrimental to bitcoin to solve his problem and advertising others to do that is really ... not ideal at all.

[centove]

For what it's worth...

My node (http://ask.gxsnmp.org:9332/) has:
P2Pool - Peers   8 out, 29 in
Bitcoind:  "connections" : 51,
             "currentblocksize" : 66063,

Getwork Latency -Mean: 0.695s

And it seems to be doing fine.

Uptime: 11.257 days.

That's @ all the 'default' settings

Could it be better? Probably.. I'm just not really sure what to tweak to make it better, it seems to be working and I get payouts whenever a block is found.

[mdude77]

Processing transactions is what mining is all about. Too many have forgotten that, believing that mining is about getting coin, and if you can throw in some transactions while you do it, why not.

But... processing the transactions is what our sole purpose as miners, actually is.

Probably be better off to keep the connection counts down to 2-4 on bitcoind, and low connections on p2pool as well, so we're sending data to less people, allowing them to be sent, faster, and let the meganodes with the bandwidth to handle it, focus on the wide redistribution.

It does no good for a node with a residential-quality upstream, to pass along block data to 50 nodes, if it takes 10 seconds to do it.

The torrent community fights about this too, and the best nodes you find that are sending to you fast, are the ones who aren't trying to keep 500 connections open, giving each peer just a few kB/s at a time, making block propagation just drag out forever, much longer than it should, with extra wasted overhead.

Block propagation suffers the same way. Less really is sometimes more.
-- Smoov

+1

I was trying to indicate bandwidth limitations earlier.  I don't have any ports forwarded at all, to p2pool or bitcoind.  I get 8 in on p2pool, and 9 in on bitcoind (atm).  I'm also running namecoind and ixcoin for merged mining, I'd imagine they have 8 each as well.  No problems at all, and my stale rate is usually lower than the pool, sometimes significantly moreso.  When I start forwarding ports, that's when things get out of control.

M

[maqifrnswa]

For what it's worth...

My node (http://ask.gxsnmp.org:9332/) has:
P2Pool - Peers   8 out, 29 in
Bitcoind:  "connections" : 51,
             "currentblocksize" : 66063,

Getwork Latency -Mean: 0.695s

And it seems to be doing fine.

Uptime: 11.257 days.

That's @ all the 'default' settings

Could it be better? Probably.. I'm just not really sure what to tweak to make it better, it seems to be working and I get payouts whenever a block is found.

you're doing fine, but your efficiency is not has high as someone with 0.003 s getwork latency.
Your expected DOA due to getblocktemplate latency: .7/10 = 7%
Someone with a 0 tx fee blocks (3ms) .003/10= 0.03%

assuming everything else equal: if your efficiency is 100%, theirs can be 107%.

They get 7% more profit than you by choosing to not process any transactions at all.

Thus Kano's argument that if the optimal p2pool setup is to process 0 tx, then p2pool (as it stands with standard bitcoind) hurts the network