Bitcoin Forum
August 20, 2017, 04:34:25 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   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 18571 times)
cuddlefish
Sr. Member
****
Offline Offline

Activity: 308


View Profile
May 20, 2011, 08:55:16 PM
 #21

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.
1503203665
Hero Member
*
Offline Offline

Posts: 1503203665

View Profile Personal Message (Offline)

Ignore
1503203665
Reply with quote  #2

1503203665
Report to moderator
1503203665
Hero Member
*
Offline Offline

Posts: 1503203665

View Profile Personal Message (Offline)

Ignore
1503203665
Reply with quote  #2

1503203665
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1503203665
Hero Member
*
Offline Offline

Posts: 1503203665

View Profile Personal Message (Offline)

Ignore
1503203665
Reply with quote  #2

1503203665
Report to moderator
1503203665
Hero Member
*
Offline Offline

Posts: 1503203665

View Profile Personal Message (Offline)

Ignore
1503203665
Reply with quote  #2

1503203665
Report to moderator
cuddlefish
Sr. Member
****
Offline Offline

Activity: 308


View Profile
May 20, 2011, 08:55:53 PM
 #22

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
Sr. Member
****
Offline Offline

Activity: 406



View Profile
May 20, 2011, 09:01:50 PM
 #23

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.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
Veldy
Member
**
Offline Offline

Activity: 98



View Profile
May 20, 2011, 09:03:25 PM
 #24

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.

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

Activity: 868



View Profile WWW
May 20, 2011, 09:11:13 PM
 #25

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

(gasteve on IRC) Does your website accept cash? https://bitpay.com
cuddlefish
Sr. Member
****
Offline Offline

Activity: 308


View Profile
May 20, 2011, 09:14:52 PM
 #26

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

Activity: 98



View Profile
May 20, 2011, 09:19:59 PM
 #27

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.

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

Activity: 154


View Profile
May 20, 2011, 09:21:51 PM
 #28

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
Sr. Member
****
Offline Offline

Activity: 406



View Profile
May 20, 2011, 09:22:23 PM
 #29

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.

Quote from: OP (emphasis added)
6. Miner finds share! Sends it to pool. If the share turns out to be a valid block, pool distributes winnings.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
Dusty
Hero Member
*****
Offline Offline

Activity: 725


Libertas a calumnia


View Profile WWW
May 20, 2011, 09:47:21 PM
 #30

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

Articoli bitcoin: Il portico dipinto
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
May 20, 2011, 10:10:49 PM
 #31

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

Activity: 725


Libertas a calumnia


View Profile WWW
May 20, 2011, 10:16:22 PM
 #32

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.

Articoli bitcoin: Il portico dipinto
Ian Maxwell
Full Member
***
Offline Offline

Activity: 140



View Profile WWW
May 20, 2011, 10:16:48 PM
 #33

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

Ian Maxwell
PGP key | WoT rating
fergalish
Sr. Member
****
Offline Offline

Activity: 440


View Profile
May 20, 2011, 10:21:41 PM
 #34

If I'm understanding everything correctly, this is fantastic.
Wise man once say - man who thinks everything ok, doesn't understand anything.
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
May 20, 2011, 10:27:06 PM
 #35

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.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
goatpig
Legendary
*
Offline Offline

Activity: 1582

Armory Developer


View Profile
May 20, 2011, 10:46:25 PM
 #36

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
Sr. Member
****
Offline Offline

Activity: 308


View Profile
May 20, 2011, 11:50:32 PM
 #37

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.

Quote
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
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
May 21, 2011, 01:09:38 AM
 #38

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.

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

(gasteve on IRC) Does your website accept cash? https://bitpay.com
molecular
Donator
Legendary
*
Offline Offline

Activity: 2338



View Profile
May 21, 2011, 01:13:53 AM
 #39

That's fucking genius!

Don't thank me, send me BTC.

Doing both: Thanks!

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
May 21, 2011, 06:03:09 AM
 #40

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.

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!