Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 552. (Read 2591920 times)

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 Wink

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.

mdude77

legendary

Activity: 1540

Merit: 1001

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 Wink

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

hero member

Activity: 924

Merit: 1000

Watch out for the "Neg-Rep-Dogie-Police".....

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 Wink

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.

daemondazz

sr. member

Activity: 448

Merit: 250

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.

Searinox

full member

Activity: 147

Merit: 100

Do you like fire? I'm full of it.

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?

gyverlb

hero member

Activity: 896

Merit: 1000

Quote from: Subo1977 on May 05, 2013, 06:06:59 AM

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 Wink

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

mdude77

legendary

Activity: 1540

Merit: 1001

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

Subo1977

sr. member

Activity: 344

Merit: 250

Flixxo - Watch, Share, Earn!

Quote from: PatMan on May 05, 2013, 05:45:39 AM

Quote from: zvs on May 05, 2013, 05:42:40 AM

Quote from: PatMan on May 05, 2013, 05:39:43 AM

Quote from: zvs on May 05, 2013, 05:42:40 AM

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....

PatMan

hero member

Activity: 924

Merit: 1000

Watch out for the "Neg-Rep-Dogie-Police".....

Quote from: PatMan on May 05, 2013, 05:39:43 AM

Quote from: PatMan on May 05, 2013, 05:39:43 AM

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.

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

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

hero member

Activity: 924

Merit: 1000

Watch out for the "Neg-Rep-Dogie-Police".....

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

PatMan

hero member

Activity: 924

Merit: 1000

Watch out for the "Neg-Rep-Dogie-Police".....

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 Wink

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

going back about 3 or 4 pages

Quote from: kano on May 01, 2013, 04:54:02 AM

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.

Quote from: zvs on May 01, 2013, 03:56:03 AM

...
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.

Quote from: zvs on May 01, 2013, 10:25:23 AM

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

mdude77

legendary

Activity: 1540

Merit: 1001