Quote from: kano on May 05, 2013, 09:11:56 PM

Quote from: zvs on May 05, 2013, 10:24:07 AM

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