P2Pool Server List

[kano]

furball:  the latency is (from my experience) mostly determined by your maxblocksize.  set it to 5000 (so you can catch a few transactions that might have bloated fees)  and your latency should drop a lot.  less transactions = lower latency.   also less orphans

Thanks so much for the tip zvs, will definitely give that a go.

... and another p2pooler makes p2pool 100 times worse than using any of the top pools ...

He might well lose a bit of money with a maxblocksize so low but it's better than almost any other pool. If income is better on p2pool, the market decides to switch to p2pool.

So Kano, why don't you patch bitcoin for speeding up getblocktemplate to avoid this instead of harassing miners who don't have the knowledge to do it themselves?

No the problem is people using crap hardware and crap internet connections and then blaming bitcoin and setting their bitcoin setting 100x worse than the top pools.
Why don't the pools have this problem? Coz they don't use crap setups.
i.e. p2pool is way worse for bitcoin than the top pools ... for those doing this ... and everyone else also mining on p2pool is supporting those doing this by paying them in the share chain ...

[1713576783]

1713576783

[1713576783]

1713576783

[1713576783]

1713576783

[rdponticelli]

furball:  the latency is (from my experience) mostly determined by your maxblocksize.  set it to 5000 (so you can catch a few transactions that might have bloated fees)  and your latency should drop a lot.  less transactions = lower latency.   also less orphans

Thanks so much for the tip zvs, will definitely give that a go.

... and another p2pooler makes p2pool 100 times worse than using any of the top pools ...

Just for the record: It's not another, it's always the same one....

[gyverlb]

furball:  the latency is (from my experience) mostly determined by your maxblocksize.  set it to 5000 (so you can catch a few transactions that might have bloated fees)  and your latency should drop a lot.  less transactions = lower latency.   also less orphans

Thanks so much for the tip zvs, will definitely give that a go.

... and another p2pooler makes p2pool 100 times worse than using any of the top pools ...

He might well lose a bit of money with a maxblocksize so low but it's better than almost any other pool. If income is better on p2pool, the market decides to switch to p2pool.

So Kano, why don't you patch bitcoin for speeding up getblocktemplate to avoid this instead of harassing miners who don't have the knowledge to do it themselves?

No the problem is people using crap hardware and crap internet connections and then blaming bitcoin and setting their bitcoin setting 100x worse than the top pools.
Why don't the pools have this problem? Coz they don't use crap setups.

Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.

[maqifrnswa]

furball:  the latency is (from my experience) mostly determined by your maxblocksize.  set it to 5000 (so you can catch a few transactions that might have bloated fees)  and your latency should drop a lot.  less transactions = lower latency.   also less orphans

Thanks so much for the tip zvs, will definitely give that a go.

... and another p2pooler makes p2pool 100 times worse than using any of the top pools ...

He might well lose a bit of money with a maxblocksize so low but it's better than almost any other pool. If income is better on p2pool, the market decides to switch to p2pool.

So Kano, why don't you patch bitcoin for speeding up getblocktemplate to avoid this instead of harassing miners who don't have the knowledge to do it themselves?

No the problem is people using crap hardware and crap internet connections and then blaming bitcoin and setting their bitcoin setting 100x worse than the top pools.
Why don't the pools have this problem? Coz they don't use crap setups.

Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.

I agree, it has nothing to do with crap set us but simply the behavioural economics of  mining. Even someone with the best set-up in the world would do better with a zero transaction block than not.

Galvin has shown that for big pools it is more profitable to take more transactions (and transaction fees) at a risk of higher orphans than it would be to take zero transactions and lower orphans.

However, with p2pool, it is more profitable to make 0 transaction blocks and have lower sharechain orphans than it is to have more transactions in a block. This is because if I choose to include transactions in a block, I don't see the profit since it is shared amongst the pool. If I choose to make 0 transaction blocks, I see an increase in profit but the rest of the pool sees a drop.

This assumes extreme selfishness (ignoring effects on the larger bitcoin network), which implies optimal efficiency.

[kano]

...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.

What has that to do with orphans?
The actual risk of having an orphan is only your bitcoind.
p2pool sends the blocks directly to bitcoind - that's why p2pool doesn't throw away valid blocks when they are rejected by the share chain.

[Smoovious]

:facepalm:

and people wonder why we have a backlog of transactions...

it is because of people NOT PROCESSING TRANSACTIONS LIKE THEY'RE SUPPOSED TO BE DOING!!!

they're getting paid to do a job they're not doing...

-- Smoov

[gyverlb]

...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.

What has that to do with orphans?

If you want to put the blame on p2pool users instead of the slow bitcoin RPC interface you might want to learn what an orphaned share in P2Pool is and what its consequences are. You can read the guide in my signature to understand this and related information about P2Pool.

The actual risk of having an orphan is only your bitcoind.

Not relevant to the problem some p2pool miners try to solve by lowering their block size.

[gyverlb]

:facepalm:

and people wonder why we have a backlog of transactions...

it is because of people NOT PROCESSING TRANSACTIONS LIKE THEY'RE SUPPOSED TO BE DOING!!!

they're getting paid to do a job they're not doing...

Actually they don't or Kano wouldn't throw a fit each time he reads about yet another p2pool miner lowering the max block size.

[kano]

...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.

What has that to do with orphans?

If you want to put the blame on p2pool users instead of the slow bitcoin RPC interface you might want to learn what an orphaned share in P2Pool is and what its consequences are. You can read the guide in my signature to understand this and related information about P2Pool.

The actual risk of having an orphan is only your bitcoind.

Not relevant to the problem some p2pool miners try to solve by lowering their block size.

So what you are trying to tell me is that it's not orphan blocks that you are trying to reduce but orphan shares in the p2pool share-chain?
Seriously?
It's even worse?
You are trying to increase your share count at the detriment of the bitcoin network?

[maqifrnswa]

...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.

What has that to do with orphans?

If you want to put the blame on p2pool users instead of the slow bitcoin RPC interface you might want to learn what an orphaned share in P2Pool is and what its consequences are. You can read the guide in my signature to understand this and related information about P2Pool.

The actual risk of having an orphan is only your bitcoind.

Not relevant to the problem some p2pool miners try to solve by lowering their block size.

So what you are trying to tell me is that it's not orphan blocks that you are trying to reduce but orphan shares in the p2pool share-chain?
Seriously?
It's even worse?
You are trying to increase your share count at the detriment of the bitcoin network?

exactly - this is the problem. Like I just posted above, there is no financial incentive for a single p2pool user to include transactions in their p2pool share.
It's game theory: if everyone includes transactions, everyone wins. But if one person chooses to make zero transaction p2pool shares, and everyone else chooses to make normal shares - the zero transaction share person wins.

EDIT: this is selfish, but it is the way it is. Pools do have a financial incentive to include transactions since transaction fees offset the increase in orphan rate. p2pool nodes, however, do not see the transaction fees they include (but only a tiny fraction of the fees), so there is more of an incentive to have lower latency than higher transaction fees.

[gyverlb]

...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.

What has that to do with orphans?

If you want to put the blame on p2pool users instead of the slow bitcoin RPC interface you might want to learn what an orphaned share in P2Pool is and what its consequences are. You can read the guide in my signature to understand this and related information about P2Pool.

The actual risk of having an orphan is only your bitcoind.

Not relevant to the problem some p2pool miners try to solve by lowering their block size.

So what you are trying to tell me is that it's not orphan blocks that you are trying to reduce but orphan shares in the p2pool share-chain?

Yes, although I don't use an extremely low blocksize: it's 100 000 in my configuration instead of 5 000 reported earlier because this is where bitcoind slows down enough for me to impact my mining efficiency noticeably.

Seriously?
It's even worse?
You are trying to increase your share count at the detriment of the bitcoin network?

Mining is a business for some, not a charity and I don't see any problem with that (in fact I think it's probably good and decentralizing mining power by using p2pool in the process is even better).

Don't remember the time before bitcoin 0.8 when some pools started reducing their own max blocksize or ignoring low fee transactions to deal with an orphans problem? It's the same problem on a different scale and the solution is the same: speed up the bitcoin RPC interface.

Jumping on anybody reducing the max blocksize accusing him/her of antisocial behaviour is a waste of time, most will simply ignore you.
The only productive action is studying why the software takes more than 0.01s transmitting 100kB of data locally and bog down the CPU in the process (that's not like p2pool users run their nodes on 8086 CPUs...).

If you really think that ignoring what's probably a performance bug to pester users go ahead and waste your time: users always find ways to circumvent software limitations. That's real life, deal with it.

[zvs]

...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.

What has that to do with orphans?

If you want to put the blame on p2pool users instead of the slow bitcoin RPC interface you might want to learn what an orphaned share in P2Pool is and what its consequences are. You can read the guide in my signature to understand this and related information about P2Pool.

The actual risk of having an orphan is only your bitcoind.

Not relevant to the problem some p2pool miners try to solve by lowering their block size.

So what you are trying to tell me is that it's not orphan blocks that you are trying to reduce but orphan shares in the p2pool share-chain?
Seriously?
It's even worse?
You are trying to increase your share count at the detriment of the bitcoin network?

exactly - this is the problem. Like I just posted above, there is no financial incentive for a single p2pool user to include transactions in their p2pool share.
It's game theory: if everyone includes transactions, everyone wins. But if one person chooses to make zero transaction p2pool shares, and everyone else chooses to make normal shares - the zero transaction share person wins.

EDIT: this is selfish, but it is the way it is. Pools do have a financial incentive to include transactions since transaction fees offset the increase in orphan rate. p2pool nodes, however, do not see the transaction fees they include (but only a tiny fraction of the fees), so there is more of an incentive to have lower latency than higher transaction fees.

that's not true, either.   people with better systems win out in the 'everyone includes every transaction' theoretical.

i'll throw this out there:  people saying to include all these transactions are being greedy.  you want to increase your own "efficiency" rate at the expense of people with slower systems.  for someone to have >100%, someone else has to have <100%

[maqifrnswa]

that's not true, either.   people with better systems win out in the 'everyone includes every transaction' theoretical.

i'll throw this out there:  people saying to include all these transactions are being greedy.  you want to increase your own "efficiency" rate at the expense of people with slower systems.  for someone to have >100%, someone else has to have <100%

In the presence of a health p2pool network strength, the theoretical optimal strategy of a p2pool node operator is to have the have the best system, lowest latency, you can get. That includes:
1) have a top notch fast system
2) limit transactions

Following (2) to its logical conclusion (i.e. zero transaction blocks) is bad for the network. Following (1) isn't necessarily bad for the network (unless you say it discourages smaller p2pool nodes, but they can just mine the bigger/faster public ones if it gets bad). However, I think there is some happy medium where (2) could be beneficial for the bitcoin network. In exchange for adding the hashrate of many small p2pool miners you get some smaller blocks. That is could be an acceptable trade-off. Going to zero-transactions, however, is not acceptable.

My point is that the optimal p2pool strategy is bad for the bitcoin network. Is there something that can be done? Force p2pool shares to contain a certain number of transactions? A number small enough that doesn't kill small pool latency but big enough to help the network?

[gyverlb]

Is there something that can be done? Force p2pool shares to contain a certain number of transactions? A number small enough that doesn't kill small pool latency but big enough to help the network?

See my previous posts...

If nothing can be done to speed up bitcoind which would clearly be the better solution as it would benefit everyone, there are at least several relatively complicated approach p2pool could use:

• allow a share to "adopt" an orphan share (ie: reference two shares instead of one), which would greatly reduce latency impacts on the miner's efficiency, this has often been discussed but never been implemented, probably quite complex
• for each miner, compute the fees associated with each share and distribute fees proportionately to all submitted shares (unlike the block reward itself which would remain in proportion to the number*complexity of shares submitted). I'm not sure if it's doable in a secure way, I'm not familiar enough with the sharechain implementation, but if it's doable it's probably not trivial to get right.
• the simplest would be to punish shares with fewer transactions when a fork happens in the sharechain by always building on the share with the largest number of transactions but I'm not sure it would be enough

[zvs]

#2, not sure.  Also I don't think that'd be incentive enough to risk p2pool orphans with.

#1 and #3, I think would cause problems for people using p2pool with high latency. 

The current reward for solving a share is .5%, right?  So .125 (+ some small bit from transaction fees)?  Average block has maybe .2 to .5 in transaction fees?  I still just think changing the reward to the transactions is the best way to solve the problem.

... and it can be changed if and when transaction fees become a more significant portion of blocks (when reward drops to 12.5, or some other event)

I don't see why ppl complain about that

[gyverlb]

#2, not sure.  Also I don't think that'd be incentive enough to risk p2pool orphans with.

#1 and #3, I think would cause problems for people using p2pool with high latency.

I don't see why #1 would, it would allow a window averaging 10s after a share to submit a share based on the previous one. Unless your latency is several seconds larger than the other miners you shouldn't be penalized by your latency in any noticeable way.

[chances]

Hey all,
Just opening up our new p2pool to everyone. My buddy and I have been testing it and everything is working great.
There is 0% fee at the moment and only LTC mining.
We're working on adding many more scrypt coins to the server in the very near future.
The server is hosted on the east coast of Australia in a data center, connection and ping for Aussies should be ideal!

Address is - p2pool.net.au

Brisbane::Australia::http://p2pool.net.au:9327/::0%::LTC::p2pool.net.au::chances

Username is your wallet address and password is anything.

By the end of next week we should have some more coins available and a frontpage for all the pools.

Any suggestions would be appreciated

[Smoovious]

(deleted response, as it was unclear if the fees to what I was replying to, were also going to be paid out PPLNS or Proportional, and if Proportional, then that negated the assumption of PPLNS I was making)

-- Smoov

[nesociety]

Montreal::Quebec::Canada::http://mine-a-coin.com:9327/::1%::LTC::Mine-a-coin.com::NS

[PatMan]

Montreal::Quebec::Canada::http://mine-a-coin.com:9327/::1%::LTC::Mine-a-coin.com::NS

Cool avatar my man - Pans Labyrinth - a classic