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

[Richy_T]

I'm not sure there'd be much benefit to C compared to some other languages which are more easily cross-platform such as Perl or Java. More power to the elbow of anyone who wants to though.

[1713933728]

1713933728

[1713933728]

1713933728

[Soros Shorts]

I'm not sure there'd be much benefit to C compared to some other languages which are more easily cross-platform such as Perl or Java. More power to the elbow of anyone who wants to though.

There is a benefit in using a compiled language that does not have garbage collection and gives you access to low-level OS primitives - you can write really tight high performance code. I think that C++ would be a better choice over C, though.

[Richy_T]

I'm not sure there'd be much benefit to C compared to some other languages which are more easily cross-platform such as Perl or Java. More power to the elbow of anyone who wants to though.

There is a benefit in using a compiled language that does not have garbage collection and gives you access to low-level OS primitives - you can write really tight high performance code. I think that C++ would be a better choice over C, though.

Don't get me wrong, I'm a long time C/C++ advocate and user. But is something like this really in that much need of that level tight, high-performance code? (Maybe it is, I just don't know that much about it).

[davidkassa]

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

My 11.3 was at ~0.2-0.3 and my 11.4 seems to be at ~0.5-0.6.

I'm out of town this week, but will downgrade to see if it helps when I get back.

[sdczen]

Could you post the line from the p2pool program feed that looks like:
New work for worker! Difficulty: 0.000200 Share difficulty: 0.994552 Total block value: 50.210500 LTC including 10 transactions

It's still the same as mentioned above:  "New work for worker! Difficulty: 0.232827 Share difficulty: 5.000000 Total block value: 53.123000 LTC including 45 transactions"  This is using: Usrnme/5+5

P2pool version is: 11.3 (I tried 11.4, that seemed to decrease my share rate further)  Cgminer version: 3.1.0.

I'm receiving payouts.  The odd behavior is receiving consistent share/payout per block of .45 LTC for 12+ hours, then it drops to .10 for another 12 + hours.  This happens when the p2pool node has been operating fine, along with all the miners connected.  Smooth & even hashrates.  The overall pool hashrate has a mean score of 580MH/s.  I would anticipate a much lower payout if the pool hashrate jumped to 1,200MH/s, but it stays within 100-150+- MH/s variance of the mean score.  My efficiency is normally between 110%-120%.

Thank you for the reply. 

Thanks - I think this shows what's wrong:

1) your +5 difficulty is way to high so p2pool has already reduced it down to .232 (otherwise it would get no statistics)
2) the /5 difficulty is causing 200% higher variance than is typical. The payouts change so much because you are only submitting a rare high difficulty share instead of frequent low difficulty shares. p2pool is not a PPS payout system, but a PPLNS. When you find a share, you will get paid out every time p2pool finds a block for some period of time. If you find shares infrequently, there will be much variance. With a /5 difficulty, you'll find shares infrequently.

Both of those settings won't affect your expected or average payout, just change the variance and frequency of payouts.

i'd try one of these two:
1) don't use /difficulty+difficulty at all and let p2pool tune it for you (especially good if you're a small miner)
2) If you're a bigger miner and want to tune your difficulty, perhaps trying /2+.0002 as a starting point and tune as you see fit. If you're payout variance is too high, get rid of the /2. If you're statistics reporting to p2pool is too much (crashing the server) then increase +.0002 to something higher (or lower if you want more accurate statistics)

Thank you, I'm starting to get a better understanding of how P2pool LTC difficulty works now.  There isn't much info regarding the subject (at least that I've found).  It's still a bit murky on how p2pool assigns shares & what the requirement/per difficulty setting.  Ideally, it would be nice to know that I'm only submitting hashes that meet the difficulty requirement to receive a share from p2pool.  For example:

usrnme/2 = would require 200k share (cgminer etc..) to receive a share from P2pool.
usrnme/3 = would require 300k share
usrnme/4 = etc....

I've used the usrnme/2 difficulty and submitted (accepted) a 250K share from cgminer, and looked in P2pool to see if it counted, and it was not counted.  Me being a pain in the arse, I like to understand how things work, so that I can apply them to my needs as best I can. 

I really appreciate you sharing your knowledge, it's been a wealth of information!

[Subo1977]

Have a look at my latency Graph....

http://p2pool-cologne.dyndns.org:9332/static/graphs.html?Hour

is it nice? 

[rav3n_pl]

WOW! How?

[Subo1977]

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;





3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

[Amph]

can anyone give me the link for 11.3 version?

thank you

[Searinox]

100% agreed. A few pages back I posted I was having trouble with p2pool's latency going up over time, now it seems more and more people are reporting it. Reverting to 11.3.

Something that might help you debug it: I found that p2pool returns to normal latency not when you restart it, but when you restart the bitcoin daemon. It might not be purely a latency issue with p2pool itself but rather the way it communicates with bitcoind.

Old P2Pool: http://u.forre.st/u/drxlzowj/p2pool_win32_11.3.zip

PS: Forrestv it really doesn't help that your binaries repository donesn't have a standardized folder structure and the builds are inside random-named folders whose root is unbrowsable. I had to use google's cache. Just sayin.

[kano]

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;





3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

[mdude77]

I'm not sure there'd be much benefit to C compared to some other languages which are more easily cross-platform such as Perl or Java. More power to the elbow of anyone who wants to though.

There is a benefit in using a compiled language that does not have garbage collection and gives you access to low-level OS primitives - you can write really tight high performance code. I think that C++ would be a better choice over C, though.

Don't get me wrong, I'm a long time C/C++ advocate and user. But is something like this really in that much need of that level tight, high-performance code? (Maybe it is, I just don't know that much about it).

It seems to me there's a scaling issue, which is why it isn't working properly with an asic as small as a jalapeno.  I'm concerned about cross platform compatibility too.

M

[Subo1977]

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;





3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

I wouldn start a discussion over the pro and cons of TX handling with P2pool.

i  would only show the impact of TX integration on the Performance in an actual setup.

[mdude77]

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;


3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

I wouldn start a discussion over the pro and cons of TX handling with P2pool.

i  would only show the impact of TX integration on the Performance in an actual setup.

No transactions == bad idea.  No discussion needed.

M

[zvs]

going back about 3 or 4 pages

i sent him a custom copy of bitcoind on tues, now he runs around a constant 3.5-4ms latency.  this is on some cheap $40 OVH machine.  8GB RAM and some semi-junk CPU.   this was accomplished essentially by just raising the tx fee to 100000.  at that rate, you'll only get tx'es that'll clear out on the next block.   he's also set to 5000 max blocksize.   though, you'd start to notice the ramdrive a lot more once you start raising the blocksize.  the problem I have with it is that it also increases the # of orphans..

i think it'd be much better if the block solver got all the TX fees instead of however the reward system works now (and, no, this isn't favoring someone that's 60ghash, because like the share difficulty, in the long run it would all even out).

it does bother me when people have the maxblocksize set to <1000, though.... because occasionally you will get that transaction with the 5 BTC fee and it only takes a few KB to get it in a block...  lenny solved one of those just about a week or two ago (block was worth 33, I believe)

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;





3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

...
Yeah, so there's really no reason not to just change it over to the TX'es.     Add them to your blocks, take the risk of having a few more orphans, but get the whole TX amt if you solve it

Except that is the exact opposite of the BTC design.
BTC design is to halve every 4 years coz transaction fees will 'supposedly' cover this over time.
So doing it that way means to head in the direction of giving all the reward to the block finder ... i.e. the opposite of being a pool.

so obtuse

i'm not helping propagate your share full of transactions, because it gets orphaned

if a large amount of transactions still cause shares to have an increased chance of being orphaned and assuming people still use p2pool when this may matter, in 4, 8, or 12 years, then i suspect it would be wise to then do a rethink. 

oh, assuming the issue w/ the increased orphans isnt solved by then, in a decade or whatever.

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

[PatMan]

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;





3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

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 

[PatMan]

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;


3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

I wouldn start a discussion over the pro and cons of TX handling with P2pool.

i  would only show the impact of TX integration on the Performance in an actual setup.

No transactions == bad idea.  No discussion needed.

M

+1

[zvs]

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;


3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

I wouldn start a discussion over the pro and cons of TX handling with P2pool.

i  would only show the impact of TX integration on the Performance in an actual setup.

No transactions == bad idea.  No discussion needed.

M

+1

I mean, you can all pat yourselves on the back and give the +1's and the high fives for Bitcoin The Way It's Meant To Be Run and glory be to Shitloads of Transactions....

But why not fix p2pool, instead?

[PatMan]

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;


3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

I wouldn start a discussion over the pro and cons of TX handling with P2pool.

i  would only show the impact of TX integration on the Performance in an actual setup.

No transactions == bad idea.  No discussion needed.

M

+1

I mean, you can all pat yourselves on the back and give the +1's and the high fives for Bitcoin The Way It's Meant To Be Run and glory be to Shitloads of Transactions....

But why not fix p2pool, instead?

I've been asking that to be done for months now.......as you know.

[Subo1977]

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;


3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets

Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

I wouldn start a discussion over the pro and cons of TX handling with P2pool.

i  would only show the impact of TX integration on the Performance in an actual setup.

No transactions == bad idea.  No discussion needed.

M

+1

I mean, you can all pat yourselves on the back and give the +1's and the high fives for Bitcoin The Way It's Meant To Be Run and glory be to Shitloads of Transactions....

But why not fix p2pool, instead?

I've been asking that to be done for months now.......as you know.

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

Fix the Problem....