Think I just solved the pool problem.

[cuddlefish]

The current system goes something like this:

1. Register for a pool
2. Plug username/pass into miner
3. Miner gets block template from pool, tries random nonces.
4. Miner finds share, sends it to pool. If the share turns out to be a valid block, pool distributes winnings.

But a far better way would be:

1. Register for a pool.
2. Get Bitcoin address for the pool.
3. You run miner on your own local bitcoind.
4. Miner calls getwork on your bitcoind, gets block template YOU create locally! However, it gets the difficulty and generation address from the pool (to allow share-based mining, and to make sure the pool gets paid.)
5. Miner tries random nonces.
6. Miner finds share! Sends it to pool. If the share turns out to be a valid block, pool distributes winnings.

Ta-da. Now, all block generation is done by miners, not by pools, as Satoshi intended. In other words, the pool has /no/ control over the content of blocks! But pools still get block/share based mining, as pools want.

Don't thank me, send me BTC.

Too many pool members would be randomly working on the very same shares ... no good.  That is why it is sent out the way it is.

Nope, different BTC addresses for each user.

[1713442778]

1713442778

[1713442778]

1713442778

[1713442778]

1713442778

[cuddlefish]

What problem does it solve exactly?

If you're still communicating with a remote server and doing shared work and the server goes down, how is it any different than the current scheme? You won't be able to communicate with the server to submit work and all client will basically be orphaned.

The fact that a pool operator with > 50% of hashing power can double-spend.

[xenon481]

The current system goes something like this:

1. Register for a pool
2. Plug username/pass into miner
3. Miner gets block template from pool, tries random nonces.
4. Miner finds share, sends it to pool. If the share turns out to be a valid block, pool distributes winnings.

But a far better way would be:

1. Register for a pool.
2. Get Bitcoin address for the pool.
3. You run miner on your own local bitcoind.
4. Miner calls getwork on your bitcoind, gets block template YOU create locally! However, it gets the difficulty and generation address from the pool (to allow share-based mining, and to make sure the pool gets paid.)
5. Miner tries random nonces.
6. Miner finds share! Sends it to pool. If the share turns out to be a valid block, pool distributes winnings.

Ta-da. Now, all block generation is done by miners, not by pools, as Satoshi intended. In other words, the pool has /no/ control over the content of blocks! But pools still get block/share based mining, as pools want.

Don't thank me, send me BTC.

Too many pool members would be randomly working on the very same shares ... no good.  That is why it is sent out the way it is.

No, they wouldn't. They'd all have different seeds randomly given to them by their own bitcoind.

[Veldy]

Too many pool members would be randomly working on the very same shares ... no good.  That is why it is sent out the way it is.

Nope, different BTC addresses for each user.

Precisely ... and the miner must get the block from the pool.  The miner therefor is not building the block.  Basically, you can't solo mine, find the result and submit it to a pool.  That is the gist of what you seem to be proposing.

[Steve]

This is a really great idea!  I think it's a good step even considering the longer term costs of transaction signature verification and maintaining the full block chain.  In the future, miners could pick and choose how they want to operate...they could have their own TX policies, but they could also be given transactions by the pool or even by another third party.  They could opt to do transaction verification themselves, or purchase that service from someone else (who would get economies of scale by having many customers requesting verification of the same transactions).  They could maintain a full block chain themselves, or use the services of someone else that charges a fee for it.  And the pool itself could also bundle these services.  But what this does right now is make it so that pools can operate without forcing their TX acceptance policies on their members (although, I suppose the pool could still set some rules by rejecting blocks that violate their rules...but at least the miners have a larger say in the matter).

[cuddlefish]

Too many pool members would be randomly working on the very same shares ... no good.  That is why it is sent out the way it is.

Nope, different BTC addresses for each user.

Precisely ... and the miner must get the block from the pool.  The miner therefor is not building the block.  Basically, you can't solo mine, find the result and submit it to a pool.  That is the gist of what you seem to be proposing.

Noo.
The miner only gets the difficulty and the address from the pool.

read the OP.

[Veldy]

Too many pool members would be randomly working on the very same shares ... no good.  That is why it is sent out the way it is.

Nope, different BTC addresses for each user.

Precisely ... and the miner must get the block from the pool.  The miner therefor is not building the block.  Basically, you can't solo mine, find the result and submit it to a pool.  That is the gist of what you seem to be proposing.

Noo.
The miner only gets the difficulty and the address from the pool.

read the OP.

I did, but the only reason you are part of the pool is to reduce variability and get a more constant payout [or with low hash rates, ever get a payout].  How is that handled if all shares are not submitted back to the pool?  Sorry, this just comes across as seriously flawed to me.  I like the idea, but it seems to be missing the key cog.

[rezin777]

How is that handled if all shares are not submitted back to the pool? I like the idea, but it seems to be missing the key cog.

6. Miner finds share! Sends it to pool. If the share turns out to be a valid block, pool distributes winnings.

[xenon481]

Too many pool members would be randomly working on the very same shares ... no good.  That is why it is sent out the way it is.

Nope, different BTC addresses for each user.

Precisely ... and the miner must get the block from the pool.  The miner therefor is not building the block.  Basically, you can't solo mine, find the result and submit it to a pool.  That is the gist of what you seem to be proposing.

Noo.
The miner only gets the difficulty and the address from the pool.

read the OP.

I did, but the only reason you are part of the pool is to reduce variability and get a more constant payout [or with low hash rates, ever get a payout].  How is that handled if all shares are not submitted back to the pool?  Sorry, this just comes across as seriously flawed to me.  I like the idea, but it seems to be missing the key cog.

All shares are submitted back to the pool.

6. Miner finds share! Sends it to pool. If the share turns out to be a valid block, pool distributes winnings.

[Dusty]

Could someone be kind enough to explain me (or point me at some page) to what is composed a share by, exactly?

Thanks, and sorry for still being a n00b...

[BitterTea]

You have found a valid block when the hash of the block header is less than the current target.

You have found a valid share when the hash of the block header is less than the maximum target.

The current difficulty is (something like) maximum target divided by current target.

[Dusty]

You have found a valid block when the hash of the block header is less than the current target.
You have found a valid share when the hash of the block header is less than the maximum target.

I finally managed to understand the bit I was missing!

Thank you very much, BitterTea.

[Ian Maxwell]

@Dusty: When you're mining, you're trying to find a 256-bit hash that is less than or equal to a certain value, the 'target'. The maximum target is hardcoded into the client as 0x00000000ffff0000000000000000000000000000000000000000000000000000, and the difficulty is actually maxTarget / currentTarget.

A 'share' is a hash that is less than or equal to maxTarget. It's not actually useful to the pool, except as proof that you're really working. They're also useful for calculations: at difficulty 244139.48158254, you should find that the pool generates blocks at an average rate of one per 244139.48158254 shares submitted.

[fergalish]

If I'm understanding everything correctly, this is fantastic.

Wise man once say - man who thinks everything ok, doesn't understand anything.

[xenon481]

If I'm understanding everything correctly, this is fantastic.

Wise man once say - man who thinks everything ok, doesn't understand anything.

Man who stand on toilet, high on pot.

[goatpig]

So far it looks sound. Good find.

One question: In the long term, how do you manage transaction inclusion rules?

Technically, miners only take the pool's address and build up the block header on their own, so they can include any transaction they want.

[cuddlefish]

Technically, miners only take the pool's address and build up the block header on their own, so individual miners can include/exclude any transaction they want.

Technically, the pool builds the block header, so the pool owner can include/exclude any transaction they want, or start a giant chain fork if the pool has a majority of power ([Tycho], I'm looking at you.)

Pick one.

[Steve]

Technically, miners only take the pool's address and build up the block header on their own, so individual miners can include/exclude any transaction they want.

Technically, the pool builds the block header, so the pool owner can include/exclude any transaction they want, or start a giant chain fork if the pool has a majority of power ([Tycho], I'm looking at you.)

Pick one.

Currently, the miners just issue a getwork request, which includes the merkle hash of the transactions (among other things)...hence it is the pool that determines which transactions are included in a block.

[molecular]

That's fucking genius!

Don't thank me, send me BTC.

Doing both: Thanks!

[Maged]

One question: In the long term, how do you manage transaction inclusion rules?

Technically, miners only take the pool's address and build up the block header on their own, so they can include any transaction they want.

Unlike now where pools can use any rules they want and their miners wouldn't easily know, this would REQUIRE the pool to publish their rules. The pool can then simply reject any shares that don't follow their rules.

A VERY nice side-effect of this publishing requirement is that bitcoin clients can directly fetch these rules from large mining pools and use the information to more accurately predict what fees are needed to get a certain transaction in a block within a certain timeframe if a majority of the network's hashing power is coming from these pools.

Two birds, one stone.