Think I just solved the pool problem. - page 5.

Maged

legendary

Activity: 1204

Merit: 1015

Quote from: goatpig on May 20, 2011, 05:46:25 PM

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.

molecular

donator

Activity: 2772

Merit: 1019

That's fucking genius!

Quote from: cuddlefish on May 20, 2011, 02:20:53 PM

Don't thank me, send me BTC.

Doing both: Thanks!

Steve

hero member

Activity: 868

Merit: 1008

Quote from: cuddlefish on May 20, 2011, 06:50:32 PM

Quote from: goatpig on May 20, 2011, 05:46:25 PM

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.

cuddlefish

sr. member

Activity: 364

Merit: 250

Quote from: goatpig on May 20, 2011, 05:46:25 PM

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.

goatpig

legendary

Activity: 3752

Merit: 1364

Armory Developer

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.

xenon481

sr. member

Activity: 406

Merit: 250

Quote from: fergalish on May 20, 2011, 05:21:41 PM

Quote from: rezin777 on May 20, 2011, 03:18:40 PM

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.

fergalish

sr. member

Activity: 440

Merit: 250

Quote from: rezin777 on May 20, 2011, 03:18:40 PM

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

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

Ian Maxwell

full member

Activity: 140

Merit: 101

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

Dusty

hero member

Activity: 731

Merit: 503

Libertas a calumnia

Quote from: BitterTea on May 20, 2011, 05:10:49 PM

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.

BitterTea

sr. member

Activity: 294

Merit: 252

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

Activity: 731

Merit: 503

Libertas a calumnia

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

xenon481

sr. member

Activity: 406

Merit: 250

Quote from: Veldy on May 20, 2011, 04:19:59 PM

Quote from: cuddlefish on May 20, 2011, 04:14:52 PM

Quote from: Veldy on May 20, 2011, 04:03:25 PM

Quote from: cuddlefish on May 20, 2011, 03:55:16 PM

Quote from: Veldy on May 20, 2011, 03:53:23 PM

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.

rezin777

full member

Activity: 154

Merit: 100

Quote from: Veldy on May 20, 2011, 04:19:59 PM

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.

Quote from: cuddlefish on May 20, 2011, 02:20:53 PM

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

Veldy

member

Activity: 98

Merit: 10

Quote from: cuddlefish on May 20, 2011, 04:14:52 PM

Quote from: Veldy on May 20, 2011, 04:03:25 PM

Quote from: cuddlefish on May 20, 2011, 03:55:16 PM

Quote from: Veldy on May 20, 2011, 03:53:23 PM

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.

cuddlefish

sr. member

Activity: 364

Merit: 250

Quote from: Veldy on May 20, 2011, 04:03:25 PM

Quote from: cuddlefish on May 20, 2011, 03:55:16 PM

Quote from: Veldy on May 20, 2011, 03:53:23 PM

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.

Steve

hero member

Activity: 868

Merit: 1008

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

Veldy

member

Activity: 98

Merit: 10

Quote from: cuddlefish on May 20, 2011, 03:55:16 PM

Quote from: Veldy on May 20, 2011, 03:53:23 PM

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.

xenon481

sr. member

Activity: 406

Merit: 250

Quote from: Veldy on May 20, 2011, 03:53:23 PM

Quote from: cuddlefish on May 20, 2011, 02:20:53 PM

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.

cuddlefish

sr. member

Activity: 364

Merit: 250

Quote from: grndzero on May 20, 2011, 03:55:04 PM

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.

cuddlefish

sr. member

Activity: 364

Merit: 250

Quote from: Veldy on May 20, 2011, 03:53:23 PM

Quote from: cuddlefish on May 20, 2011, 02:20:53 PM

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.

Topic: Think I just solved the pool problem. - page 5. (Read 19141 times)