The power of the pool.

[Holliday]

.

[1713556664]

1713556664

[Meni Rosenfeld]

I think the most stable configuration is when the vast majority of mining capacity is in the hands of many (~100) pools, which are used by at-home miners and small mining businesses. Big mining corporations are ok too as long as they total <30% capacity.

There is indeed a problem that the desire to minimize variance will lead those small miners to seek the largest pool, thus forming few big pools.

I think a possible solution is meta-pools. I haven't yet ironed out the details, but basically they would match miners to pools while absorbing most of the variance. There will be a few big meta-pools, but they don't decide themselves which blocks to build on so they can't easily be corrupted.

[abracadabra]

The recent DDOS attacks on deepbit, slush, and btcguild should reinforce the ideas in this thread.
It's a shame people don't realize this more.

[Meni Rosenfeld]

The recent DDOS attacks on deepbit, slush, and btcguild should reinforce the ideas in this thread.
It's a shame people don't realize this more.

And, the solutions to the problem are much better understood now. You have p2pool (which can be used as a variance-reduction substrate for small pools), and there's been discussions of pools accepting shares constructed by the miner as long as the generation transaction credits the pool.

The network is probably safer with Deepbit and Slush's down than otherwise. Much ado about nothing.

To the extent that this is true, that's exactly what the ado is about - that there's a large bulk of miners who harm network security instead of improving it.

[DeathAndTaxes]

The problem is merely in the way that pools are constructed.

Take p2pool for example.  If could have 100% of the hashing power, result in essentially 0% variance and would present no risk to the network.

Most pools currently operate in a "miner dumb" model.  The miners are dumb hashing workers for the smart pool.  It works fine if you trust the pool BUT if the pool is doing something malicious (or becomes compromised) those same dumb miners will gadly work to destroy bitcoin.

The solution is a "miners smart" model.  Where each miner is independent, verifies its own blocks, and simply shares rewards with other miners.  It is more complex and requires more "thinking" which explains why the "miner dumb" model came first.

The p2pool model could be used for non-distributed pools also and at the same time protect the network from the size of the pool.

[DeathAndTaxes]

The problem is merely in the way that pools are constructed.

Take p2pool for example.  If could have 100% of the hashing power, result in essentially 0% variance and would present no risk to the network.

Most pools currently operate in a "miner dumb" model.  The miners are dumb hashing workers for the smart pool.  It works fine if you trust the pool BUT if the pool is doing something malicious (or becomes compromised) those same dumb miners will gadly work to destroy bitcoin.

The solution is a "miners smart" model.  Where each miner is independent, verifies its own blocks, and simply shares rewards with other miners.  It is more complex and requires more "thinking" which explains why the "miner dumb" model came first.

The p2pool model could be used for non-distributed pools also and at the same time protect the network from the size of the pool.

I can see the value in that but how would it be implemented? We would need an officially released miner like the current client and have no independent development of "rogue" miners in the wild that offer hashing benefits over the official one. Not an easy task.

No p2pool works with any miner.  It simply has a local host daemon which creates creates the blockheaders, and creates the hash chain (a parallel but independent chain recording POW to split rewards).  If a pool wanted to adopt a similar structure but was centrally controlled they would simply need to develop that open source local daemon.  It would created block headers locally from the bitcoin network bypassing the pool as the "source of information" and avoiding that conflict on interest.  Any miner could be pointed to localhost and work w/ p2pool or any other pool adopting a similar structure.

[DeathAndTaxes]

I like Bitminter.  Very low stale (<0.1%).  I don't use their custom Miner though I use cgminer.

Still using a smaller pool or medium sized pools is an incomplete solution.  The real solution is "smart" mining pools where pool operators can grow their "membership" as big as that doesn't grow their power.

You are right about the fact that if miner's don't choose alternatives them it doesn't matter.   If every pool except deepbit implements smart miner protocols but miners stay with deepbit (despite the potential risk) it doesn't do much good.

[Meni Rosenfeld]

Pardon me for necroing my own thread, but I wanted to add something.

You are a great necromancer. Not every day I see in "Updated Topics" a thread title I don't recognize.

P2Pool. That is all.

As I said before, p2pool is a solution but not the only solution, you can also have split pools. And p2pool isn't really good for at-home miners, it's more suitable for large miners and proxy pools.

[Meni Rosenfeld]

Are there any pools currently using a split pool implementation?

None that I know of. Maybe it's time to start lobbying for one.

[DeathAndTaxes]

Are there any pools currently using a split pool implementation?

None that I know of. Maybe it's time to start lobbying for one.

Can you provide an explanation of a "split pool"?

[Meni Rosenfeld]

Are there any pools currently using a split pool implementation?

None that I know of. Maybe it's time to start lobbying for one.

Can you provide an explanation of a "split pool"?

In a nutshell, a pool which doesn't submit block headers to its miners, rather submits an address and accepts as shares any block header (with low enough hash) which credits this address in the generation transaction (with a Merkle branch to prove it). The miner can either construct the block locally or get it from an unrelated getwork server. Hence the pool, which handles rewards and can reduce variance more effectively if it is large, is split from the agent responsible to decide what is being hashed.

[DeathAndTaxes]

Are there any pools currently using a split pool implementation?

None that I know of. Maybe it's time to start lobbying for one.

Can you provide an explanation of a "split pool"?

In a nutshell, a pool which doesn't submit block headers to its miners, rather submits an address and accepts as shares any block header (with low enough hash) which credits this address in the generation transaction (with a Merkle root to prove it). The miner can either construct the block locally or get it from an unrelated getwork server. Hence the pool, which handles rewards and can reduce variance more effectively if it is large, is split from the agent responsible to decide what is being hashed.

Gotcha I always called that a "smart miner" never thought of a better way to describe it.  Yeah split pools are likely the best solution.  It has all the advantages of a traditional pool without the risks of operator abuse.

[ThiagoCMC]

Are there any pools currently using a split pool implementation?

None that I know of. Maybe it's time to start lobbying for one.

Can you provide an explanation of a "split pool"?

In a nutshell, a pool which doesn't submit block headers to its miners, rather submits an address and accepts as shares any block header (with low enough hash) which credits this address in the generation transaction (with a Merkle root to prove it). The miner can either construct the block locally or get it from an unrelated getwork server. Hence the pool, which handles rewards and can reduce variance more effectively if it is large, is split from the agent responsible to decide what is being hashed.

Gotcha I always called that a "smart miner" never thought of a better way to describe it.  Yeah split pools are likely the best solution.  It has all the advantages of a traditional pool without the risks of operator abuse.

Okay! Let's build the first split pool!?

I have two servers that can be used for free.

I have two Dell R410 with 8G of RAM each, 3G RAM free for this.

I have two Internet connections, 100M fiber and 4M dedicate line.

What we need to start?!

* Ubuntu Linux 64 bits 11.10;
* Bitcoin 0.5.1 installed;
* ?

Best!
Thiago

[tiberiandusk]

I switch pools every few months. I left slush's pool when deepbit came out. I left deepbit when they got too big for my tastes. I then used eligius for a while until the whole putting bible verses in the blockchain thing. I'm currently on eclipse.

[disclaimer201]

I switch pools every few months. I left slush's pool when deepbit came out. I left deepbit when they got too big for my tastes. I then used eligius for a while until the whole putting bible verses in the blockchain thing. I'm currently on eclipse.

Why in the world would you leave slush for deepbit? This makes absolutely no sense. Was it worth paying 8% more for a little less variance?

[tiberiandusk]

I don't think Slush had longpolling at the time.

[DeepBit]

I switch pools every few months. I left slush's pool when deepbit came out. I left deepbit when they got too big for my tastes. I then used eligius for a while until the whole putting bible verses in the blockchain thing. I'm currently on eclipse.

Why in the world would you leave slush for deepbit? This makes absolutely no sense. Was it worth paying 8% more for a little less variance?

It's 1% more, not 8% :)
And considering LP, it was even less sometimes.

[disclaimer201]

OK, sorry. Thought it was 10% somehow... my bad.

[Meni Rosenfeld]

OK, sorry. Thought it was 10% somehow... my bad.

Deepbit has proportional and PPS options, proportional is 3%, PPS is 10%.

[Meni Rosenfeld]

Blocking possible client changes because you disagree with them and have a large percentage of the networks hashing power.

Is this OK for the Bitcoin network? Allowing one person's vote to influence the entire network?

The real problem here is that miners are being assigned to vote on protocol changes in the first place. This I think is not how Bitcoin was designed to work, and sets a very dangerous precedent. Decisions should be made by majority of users weighted by their economic power. If you break compatibility and convince the typical users, the exchanges and other big players to switch, then it doesn't matter what the majority of miners have to say, they'll have to switch if they don't want their mined coins to be worthless.

This is a special case of the more general problem that someone with a certain share of the hashrate doesn't have his incentives as strongly aligned with the well-being of Bitcoin as someone who has a similar share in the entire economy, simply because going forward mining is supposed to be only a small part of the economy.