Topic: P2Pool Server List - page 8. (Read 106711 times)

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

gyverlb

hero member

Activity: 896

Merit: 1000

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

maqifrnswa

sr. member

Activity: 454

Merit: 252

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

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

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

Quote from: Smoovious on May 07, 2013, 06:20:29 PM

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?

gyverlb

hero member

Activity: 896

Merit: 1000

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

gyverlb

hero member

Activity: 896

Merit: 1000

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

Smoovious

hero member

Activity: 504

Merit: 500

Scattering my bits around the net since 1980

: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

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

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

maqifrnswa

sr. member

Activity: 454

Merit: 252

Quote from: kano on May 07, 2013, 07:50:51 AM

Quote from: kano on May 07, 2013, 07:50:51 AM

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.

gyverlb

hero member

Activity: 896

Merit: 1000

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.

rdponticelli

sr. member

Activity: 325

Merit: 250

Our highest capital is the Confidence we build.

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

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

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

furball

full member

Activity: 172

Merit: 100

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?

Just for the record...I made the change that ZVS suggested and my latency has gone to sub 0.05 and my efficiency is at 120%, so I'm a happy camper! Thanks ZCS, appreciate the help.

I'm no genius when it comes to these things and always open to people's opinions...I'm just grateful I got an answer to my question...great Bitcoin community!

gyverlb

hero member

Activity: 896

Merit: 1000

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?

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

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

furball

full member

Activity: 172

Merit: 100

Quote from: zvs on May 05, 2013, 05:28:35 AM

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.

gyverlb

hero member

Activity: 896

Merit: 1000

Quote from: gyverlb on May 05, 2013, 05:26:36 AM

Quote from: kano on May 05, 2013, 01:49:04 AM

Quote from: gyverlb on May 05, 2013, 05:26:36 AM

http://5.9.24.81:9332/static/ for Bitcoins, 0.1 donation, 0.0 fee

http://5.9.24.81:19327/static/ for Clownshoe coins, 0.0 donation, 1.0 fee, subject to being dismantled at any moment

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

Sigh, why do people do that?

greed. Three ways to improve the situation:

speedup bitcoind rpc interfaces so that they can handle large blocks without slowing down
track the amount of transactions included in P2Pool shares for each miner and make P2Pool distribute the transactions fees proportionally
let the market decide: when transactions are piling up, there's motivation to increase the block size

Note that the first one would be useful for every pool and may be the simplest to implement: I'm not familiar with the code but I don't see why the interface needs to slow down with block size. bitcoind could maintain a cache of block templates and serve requests from it, updating this cache asynchronously according to incoming transactions and block generations.

greed? so is that why people send out transactions with 10000 fee?

what if i didn't think they were worth including in my blocks?

I don't get your point.

zvs

legendary

Activity: 1680

Merit: 1000

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

Quote from: kano on May 05, 2013, 01:49:04 AM

Quote from: kano on May 05, 2013, 01:49:04 AM

http://5.9.24.81:9332/static/ for Bitcoins, 0.1 donation, 0.0 fee

http://5.9.24.81:19327/static/ for Clownshoe coins, 0.0 donation, 1.0 fee, subject to being dismantled at any moment

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

Sigh, why do people do that?

greed. Three ways to improve the situation:

speedup bitcoind rpc interfaces so that they can handle large blocks without slowing down
track the amount of transactions included in P2Pool shares for each miner and make P2Pool distribute the transactions fees proportionally
let the market decide: when transactions are piling up, there's motivation to increase the block size

Note that the first one would be useful for every pool and may be the simplest to implement: I'm not familiar with the code but I don't see why the interface needs to slow down with block size. bitcoind could maintain a cache of block templates and serve requests from it, updating this cache asynchronously according to incoming transactions and block generations.

greed? so is that why people send out transactions with 10000 fee?

what if i didn't think they were worth including in my blocks?

gyverlb

hero member

Activity: 896

Merit: 1000