Bitcoin Forum
April 16, 2014, 08:33:55 PM *
News: ♦♦ A bug in OpenSSL, used by Bitcoin-Qt/Bitcoin Core, could allow your bitcoins to be stolen. Immediately updating Bitcoin Core to 0.9.1 is required in some cases, especially if you're using 0.9.0. Download. More info.
The same bug also affected the forum. Changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 5 6  All
  Print  
Author Topic: Think I just solved the pool problem.  (Read 13613 times)
cuddlefish
Full Member
***
Offline Offline

Activity: 126


View Profile WWW

Ignore
May 20, 2011, 07:20:53 PM
 #1

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.

I'm Nathaniel Theis.
Selling 1 BTC for cash near Berkeley, CA
161eFswCmjZvijEmiEdXVCKy8EXYfybZzx
Private Internet Access™ - No logs, Unlimited Bandwidth, PC Magazine's Editor's Choice
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1397680435
Hero Member
*
Offline Offline

Posts: 1397680435

View Profile Personal Message (Offline)

Ignore
1397680435
Reply with quote  #2

1397680435
Report to moderator
AntiVigilante
Member
**
Offline Offline

Activity: 98



View Profile

Ignore
May 20, 2011, 07:23:40 PM
 #2

Don't thank me, send me BTC.

I came.

Holy fuck.

NICE!

Proposal: http://forum.bitcoin.org/index.php?topic=11541.msg162881#msg162881
Inception: https://github.com/bitcoin/bitcoin/issues/296
Goal: http://forum.bitcoin.org/index.php?topic=12536.0
Means: Code, donations, and brutal criticism. I've got a thick skin. 1Gc3xCHAzwvTDnyMW3evBBr5qNRDN3DRpq
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile

Ignore
May 20, 2011, 07:27:12 PM
 #3

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
Full Member
***
Offline Offline

Activity: 126


View Profile WWW

Ignore
May 20, 2011, 07:29:01 PM
 #4

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.

I'm Nathaniel Theis.
Selling 1 BTC for cash near Berkeley, CA
161eFswCmjZvijEmiEdXVCKy8EXYfybZzx
bullox
Member
**
Offline Offline

Activity: 98


View Profile

Ignore
May 20, 2011, 07:30:53 PM
 #5

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.

1mNotIntoTheWholeBeggingThing02hd3us23nB372b
gigitrix
Sr. Member
****
Offline Offline

Activity: 266



View Profile

Ignore
May 20, 2011, 07:31:38 PM
 #6

I don't know much about the Crypto, but someone please explain what is wrong with this Cheesy
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile

Ignore
May 20, 2011, 07:33:15 PM
 #7

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
Full Member
***
Offline Offline

Activity: 126


View Profile WWW

Ignore
May 20, 2011, 07:33:32 PM
 #8

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!

I'm Nathaniel Theis.
Selling 1 BTC for cash near Berkeley, CA
161eFswCmjZvijEmiEdXVCKy8EXYfybZzx
nanotube
Hero Member
*****
Offline Offline

Activity: 485


View Profile WWW

Ignore
May 20, 2011, 07:34:13 PM
 #9

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.

Join #bitcoin-market on freenode for real-time market updates.
Join #bitcoin-otc - an over-the-counter trading market. http://bitcoin-otc.com
OTC web of trust: http://bitcoin-otc.com/trust.php
My trust rating: http://bitcoin-otc.com/viewratingdetail.php?nick=nanotube
Stefan Thomas
Administrator
Full Member
*
Offline Offline

Activity: 230


AKA: Justmoon


View Profile WWW
May 20, 2011, 07:38:43 PM
 #10

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
Full Member
***
Offline Offline

Activity: 126


View Profile WWW

Ignore
May 20, 2011, 08:06:25 PM
 #11

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.

I'm Nathaniel Theis.
Selling 1 BTC for cash near Berkeley, CA
161eFswCmjZvijEmiEdXVCKy8EXYfybZzx
grndzero
Sr. Member
****
Offline Offline

Activity: 392


View Profile

Ignore
May 20, 2011, 08:11:20 PM
 #12

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.

Ubuntu Desktop x64 -  HD5850 Reference - 400Mh/s w/ cgminer  @ 975C/325M/1.175V - 11.6/2.1 SDK
Donate if you find this helpful: 1NimouHg2acbXNfMt5waJ7ohKs2TtYHePy
cuddlefish
Full Member
***
Offline Offline

Activity: 126


View Profile WWW

Ignore
May 20, 2011, 08:12:41 PM
 #13

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

I'm Nathaniel Theis.
Selling 1 BTC for cash near Berkeley, CA
161eFswCmjZvijEmiEdXVCKy8EXYfybZzx
gmaxwell
Moderator
Hero Member
*
Offline Offline

Activity: 1078


View Profile

Ignore
May 20, 2011, 08:13:34 PM
 #14

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
Full Member
***
Offline Offline

Activity: 126


View Profile WWW

Ignore
May 20, 2011, 08:16:09 PM
 #15

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

I'm Nathaniel Theis.
Selling 1 BTC for cash near Berkeley, CA
161eFswCmjZvijEmiEdXVCKy8EXYfybZzx
rezin777
Full Member
***
Offline Offline

Activity: 154


View Profile

Ignore
May 20, 2011, 08:18:40 PM
 #16

If I'm understanding everything correctly, this is fantastic.
theymos
Administrator
Hero Member
*
Online Online

Activity: 1526


View Profile
May 20, 2011, 08:36:23 PM
 #17

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

cuddlefish
Full Member
***
Offline Offline

Activity: 126


View Profile WWW

Ignore
May 20, 2011, 08:39:24 PM
 #18

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.

I'm Nathaniel Theis.
Selling 1 BTC for cash near Berkeley, CA
161eFswCmjZvijEmiEdXVCKy8EXYfybZzx
Veldy
Member
**
Offline Offline

Activity: 98



View Profile

Ignore
May 20, 2011, 08:53:23 PM
 #19

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.

If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
grndzero
Sr. Member
****
Offline Offline

Activity: 392


View Profile

Ignore
May 20, 2011, 08:55:04 PM
 #20

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.

Ubuntu Desktop x64 -  HD5850 Reference - 400Mh/s w/ cgminer  @ 975C/325M/1.175V - 11.6/2.1 SDK
Donate if you find this helpful: 1NimouHg2acbXNfMt5waJ7ohKs2TtYHePy
Pages: [1] 2 3 4 5 6  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!