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.

[1714921900]

1714921900

[1714921900]

1714921900

[1714921900]

1714921900

[1714921900]

1714921900

[1714921900]

1714921900

[AntiVigilante]

Don't thank me, send me BTC.

I came.

Holy fuck.

NICE!

[BitterTea]

Interesting, but wouldn't that method allow for miners to withhold valid blocks from the pool?

As I understand it, that can't happen today because the miner doesn't have all of the information about the block. In this case, they would, no?

[cuddlefish]

Interesting, but wouldn't that method allow for miners to withhold valid blocks from the pool?

As I understand it, that can't happen today because the miner doesn't have all of the information about the block. In this case, they would, no?

They can withhold them, but they don't get the coins in them if they do.

[bullox]

Interesting, but wouldn't that method allow for miners to withhold valid blocks from the pool?

As I understand it, that can't happen today because the miner doesn't have all of the information about the block. In this case, they would, no?

This.
You could under this situation publish your 50BTC blocks on a local daemon and then still reap the benefit of those publishing them to the pool.

[gigitrix]

I don't know much about the Crypto, but someone please explain what is wrong with this

[BitterTea]

Interesting, but wouldn't that method allow for miners to withhold valid blocks from the pool?

As I understand it, that can't happen today because the miner doesn't have all of the information about the block. In this case, they would, no?

They can withhold them, but they don't get the coins in them if they do.

Ok, I think I see...

The miner could substitute their own public key during the generation process, but the pool would not recognize those shares. If they find a valid block and substitute their own public key, it's no longer a valid block.

[cuddlefish]

Interesting, but wouldn't that method allow for miners to withhold valid blocks from the pool?

As I understand it, that can't happen today because the miner doesn't have all of the information about the block. In this case, they would, no?

This.
You could under this situation publish your 50BTC blocks on a local daemon and then still reap the benefit of those publishing them to the pool.

Interesting, but wouldn't that method allow for miners to withhold valid blocks from the pool?

As I understand it, that can't happen today because the miner doesn't have all of the information about the block. In this case, they would, no?

They can withhold them, but they don't get the coins in them if they do.

Ok, I think I see...

The miner could substitute their own public key during the generation process, but the pool would not recognize those shares. If they find a valid block and substitute their own public key, it's no longer a valid block.

Yup!

[nanotube]

great idea.
pool allocates a new address to each participant, and participant uses that address in the coinbase (so not possible to 'steal' coins).

The benefits i see:

1. there's no more getwork network overhead for the pool (therefore fewer resources needed to run a pool). all we send are completed diff1 (or greater) shares that the pool needs to verify.

2. no more pools being able to decide what transactions to include or not (see eligius and its policy of charging fees for all tx), or to try to create blockchain forks for double spending if they get too powerful (this hasn't happened yet, but it /could/, theoretically.)

The only thing needed is to write some code for sending the shares to the pool.

As i see it, this scheme does not introduce any downsides.  miners cannot 'steal' blocks, if they withhold a good block, they don't get the coins, since the coinbase address used is one belonging to pool owner.

[Stefan Thomas]

Brilliant idea.

In the far future, these pools might not be competitive though due to the costs from every miner having to verify signatures. Maybe there is a solution for that?

Still, that's a ways away and for now it sounds like a great idea.

[cuddlefish]

In the far future, these pools might not be competitive though due to the costs from every miner having to verify signatures. Maybe there is a solution for that?

Well, the pool could also provide transactions to the miner; that still stops double-spending.

[grndzero]

All work is done locally ...

1) If you're doing all the work local then why bother sending it to a pool?
2) Why should the pool trust the number of shares you worked on? Hack the bitcoin program so that your Pentium III reports the same shares processed as the guy with 5 GH/s.

[cuddlefish]

All work is done locally ...

1) If you're doing all the work local then why bother sending it to a pool?

For the same reasons people use pools in the first place (insurance).

2) Why should the pool trust the number of shares you worked on? Hack the bitcoin program so that your Pentium III reports the same shares processed as the guy with 5 GH/s.

You still send each share to the pool.

[gmaxwell]

2. Get Bitcoin address for the pool.

The pool should give you N addresses:

One for D=1 work, one for D=6 work, one for D=12 work. etc.

D=6 work pays 6 shares. Etc.  The reason for this is because your scheme uses a lot more bandwidth to transmit shares, but this is trivially corrected by increasing difficulty. But that would increase variance to unacceptable levels for slow miners.  By changing the address they pre-commit to a target difficulty and the shares will be credited accordingly.

The miner software can then bet setup so that it picks the diff that gets it close to 1 share per minute...which should end up being less bandwidth than currently used.

Also, while it would be possible to buffer shares while the pool was down and the pool could choose to pay for stales, I think thats actually a bad idea: it would allow you to get shares on network-offline hosts that aren't really contributing to the success of the pool... plus it would require more coding and storage for the shares.  Instead,  when the pool isn't reachable to accept shares you simply switch to using your own address for mining until it comes back.

Annnd... as we mentioned on IRC pools could still enforce sane behavior on miners (e.g. don't send 1MB blocks of crap transactions) by simply refusing to pay for shares that look like that. So the pool acts as a check on miner behavior, but it can't enforce secret rules since the miners will need to know them in order to conform.  This somewhat invalidates nanotube's #2 re-fee rules, but I think thats a good thing.  Pools don't get unilateral control but they get some influence and I think thats good.


Also from IRC, the logical place to put all this would be in bitcoind, not in a miner client. A simple modification to bitcoind would let you change the payout address... then you use normal miners against it.

All work is done locally ...
1) If you're doing all the work local then why bother sending it to a pool?
2) Why should the pool trust the number of shares you worked on? Hack the bitcoin program so that your Pentium III reports the same shares processed as the guy with 5 GH/s.

(1) in order to get pooled payments, silly.

(2) Because you still submit 'shares' (though now with more data) in order to prove that you're working for the pool, same as now.

[cuddlefish]

2. Get Bitcoin address for the pool.

The pool should give you N addresses:

One for D=1 work, one for D=6 work, one for D=12 work. etc.

D=6 work pays 6 shares. Etc.  The reason for this is because your scheme uses a lot more bandwidth to transmit shares, but this is trivially corrected by increasing difficulty. But that would increase variance to unacceptable levels for slow miners.  By changing the address they pre-commit to a target difficulty and the shares will be credited accordingly.

The miner software can then bet setup so that it picks the diff that gets it close to 1 share per minute...which should end up being less bandwidth than currently used.

Brilliant.

Also, while it would be possible to buffer shares while the pool was down and the pool could choose to pay for stales, I think thats actually a bad idea: it would allow you to get shares on network-offline hosts that aren't really contributing to the success of the pool... plus it would require more coding and storage for the shares.  Instead,  when the pool isn't reachable to accept shares you simply switch to using your own address for mining until it comes back.

Good point, probably right.

Annnd... as we mentioned on IRC pools could still enforce sane behavior on miners (e.g. don't send 1MB blocks of crap transactions) by simply refusing to pay for shares that look like that. So the pool acts as a check on miner behavior, but it can't enforce secret rules since the miners will need to know them in order to conform.  This somewhat invalidates nanotube's #2 re-fee rules, but I think thats a good thing.  Pools don't get unilateral control but they get some influence and I think thats good.

I also agree with this.

Also from IRC, the logical place to put all this would be in bitcoind, not in a miner client. A simple modification to bitcoind would let you change the payout address... then you use normal miners against it.

Yup, probably right.

[rezin777]

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

[theymos]

This won't be popular in the long-term, since running a full node will be expensive.

[cuddlefish]

This won't be popular in the long-term, since running a full node will be expensive.

It has all the flaws of solo mining (except with the benefit of pooled mining, that you get a fairly steady payout.) That said, you can connect to some hosted bitcoind to do this.

[Veldy]

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.

[grndzero]

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.