Topic: Think I just solved the pool problem. - page 3. (Read 19141 times)
You still need a way to get work at a specific difficulty and for a specific public key
I tried this a long time ago....it doesn't work. If you getwork from your local bitcoind, you can't send it to anyone else's bitcoind, and visa-versa.
Sorry to burst your bubble.
Sorry to burst your bubble.
Oh yes, no need to radically modify the mining platform, let's just use vanilla bitcoind!
:/
maybe it is simple enough - have the block be sent to your local bitcoind - and your local bitcoind will then broadcast your block to everyone - including the pool node.
of course, everyone but the pool node will reject your difficulty-1 blocks, but the pool node will see them and give you credit for them.
so it seems that modifications necessary to bitcoind are actually quite minimal. (1) configurability to let it set getwork difficulty (2) configurability which nodes to send blocks to (ideally, to prevent network spam, it can be configured to send diff-1 blocks only to the pool's node, not everyone else.)
Don't mod bitcoind. Build in a class that your miner will getwork() from. Have some simple pool type detection code. If the pool is classic, the class will bypass its main functions and just deal directly with the pool. If the pool is modded, the class will request the getwork() off of localhost bitcoind with the pool's address, and then upload whatever data it needs to to the pool.
This way both bitcoind and number crunching side of miners will remain untouched. No need for several versions of the same miner either.
I tried this a long time ago....it doesn't work. If you getwork from your local bitcoind, you can't send it to anyone else's bitcoind, and visa-versa.
Sorry to burst your bubble.
Sorry to burst your bubble.
Oh yes, no need to radically modify the mining platform, let's just use vanilla bitcoind!
:/
maybe it is simple enough - have the block be sent to your local bitcoind - and your local bitcoind will then broadcast your block to everyone - including the pool node.
of course, everyone but the pool node will reject your difficulty-1 blocks, but the pool node will see them and give you credit for them.
so it seems that modifications necessary to bitcoind are actually quite minimal. (1) configurability to let it set getwork difficulty (2) configurability which nodes to send blocks to (ideally, to prevent network spam, it can be configured to send diff-1 blocks only to the pool's node, not everyone else.)
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.
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 tried this a long time ago....it doesn't work. If you getwork from your local bitcoind, you can't send it to anyone else's bitcoind, and visa-versa.
Sorry to burst your bubble.
Oh yes, no need to radically modify the mining platform, let's just use vanilla bitcoind!
:/
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.
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 tried this a long time ago....it doesn't work. If you getwork from your local bitcoind, you can't send it to anyone else's bitcoind, and visa-versa.
Sorry to burst your bubble.
The pool can check that the transactions fit the inclusion rules, and reject shares where they don't.
Sure that too.
This could create strategic problems for pool operators. With the current "plan", it is impossible for the often-foreseen future where merchants can pay a flat monthly "priority fee" to pools and such. So any system which allows the end-miner to control block creation would probably need some kind of way for the pool to say "must include txids , , " as well...
What about a .conf file capability added to bitcoind that allows to script TX inclusion rules. It doesn't even have to be added to bitcoind. Let's say you add a class that the miner calls, which will include TX according to the .conf file rule, then call the core bitcoin API to pull create the block header. Then a pool operator can propagate these to his clients, assuming most users won't just be douches and ignore it, since it is directly related to their profits in the long term.The pool can check that the transactions fit the inclusion rules, and reject shares where they don't.
This could create strategic problems for pool operators. With the current "plan", it is impossible for the often-foreseen future where merchants can pay a flat monthly "priority fee" to pools and such. So any system which allows the end-miner to control block creation would probably need some kind of way for the pool to say "must include txids , , " as well...
What about a .conf file capability added to bitcoind that allows to script TX inclusion rules. It doesn't even have to be added to bitcoind. Let's say you add a class that the miner calls, which will include TX according to the .conf file rule, then call the core bitcoin API to create the block header. Then a pool operator can propagate these to his clients, assuming most users won't just be douches and ignore it, since it is directly related to their profits in the long term.
Also, doesn't the network already order the TX by fee? The system described here implies the miners have to inform the pool of the TX they are including, by ID to save bandwidth obviously. The ID linking means the miners are referring to the network propagated list of pending TX, which, if they are ordered by fee, will smooth this whole system a lot.
This could create strategic problems for pool operators. With the current "plan", it is impossible for the often-foreseen future where merchants can pay a flat monthly "priority fee" to pools and such. So any system which allows the end-miner to control block creation would probably need some kind of way for the pool to say "must include txids , , " as well...
The pool can reject shares not containing those TXs. However, it /must/ publicize which ones it requires, which is a good thing IMHO.
This could create strategic problems for pool operators. With the current "plan", it is impossible for the often-foreseen future where merchants can pay a flat monthly "priority fee" to pools and such. So any system which allows the end-miner to control block creation would probably need some kind of way for the pool to say "must include txids , , " as well...
While I like the idea of the first post, it seems like the only difference between this type of pool-mining setup and the existing ones is that the BTC generated at the user and then the pool decides how it's divided up, is that correct?
No.
The pool picks the share difficulty and creates the coinbase TX.
The user does the rest.
I figured doing the coinbase TX on server-side'd make it easier to check.
While I like the idea of the first post, it seems like the only difference between this type of pool-mining setup and the existing ones is that the BTC generated at the user and then the pool decides how it's divided up, is that correct?
No.
The pool picks the share difficulty and creates the coinbase TX.
The user does the rest.
mmm unless something changed in the past 3 pages
, my understanding is quite the contrary.well, the pool is still in charge of user registration, and assigning addresses to be used in the coinbase by the clients. the creation of coinbase tx, the monitoring of the network and inclusion of transactions into the block, etc, is done client-side.
but then, the distribution of the bounty is based on number of shares submitted by the clients.
While I like the idea of the first post, it seems like the only difference between this type of pool-mining setup and the existing ones is that the BTC generated at the user and then the pool decides how it's divided up, is that correct?
No.
The pool picks the share difficulty and creates the coinbase TX.
The user does the rest.
is anyone communicating with pool managers to depoy such changes ?
While I like the idea of the first post, it seems like the only difference between this type of pool-mining setup and the existing ones is that the BTC generated at the user and then the pool decides how it's divided up, is that correct?
Well, some do want big pools, otherwise they wouldn't join deepbit. They like low variance (not realizing the highest fee costs them more in the long run). And I suspect many of them come from F@H, where you want to be big. I also suspect many of them only care about making easy money, not the health of the Bitcoin network. 
So when does the new 'client' come out with the additions/modifications? and please forgive this .. but what's F@H???
Whenever someone writes the code and tests it. F@H is Folding at Home, a distributed computing project. The various groups that "fold" compete to see who can do the most computational work, and the competition is good because it's for a good cause. But that competition doesn't translate well to Bitcoin.
Well, some do want big pools, otherwise they wouldn't join deepbit. They like low variance (not realizing the highest fee costs them more in the long run). And I suspect many of them come from F@H, where you want to be big. I also suspect many of them only care about making easy money, not the health of the Bitcoin network.
So when does the new 'client' come out with the additions/modifications? and please forgive this .. but what's F@H???
Ah .. ok ... thank you .. I thought some of you wanted big ones !! made no sense to me ..
much better .. thank you.
much better ..
thank you.Well, some do want big pools, otherwise they wouldn't join deepbit. They like low variance (not realizing the highest fee costs them more in the long run). And I suspect many of them come from F@H, where you want to be big. I also suspect many of them only care about making easy money, not the health of the Bitcoin network (which is also stupid because the Bitcoin network is what is allowing them to earn easy money).
No! You are wrong because you suggested that we want large pools.
This thread is an example of a way to reduce the control a large pool has over the network. The people posting in this thread want many small pools, the same as you. This is why I said you misunderstand the point of this thread.
This thread is an example of a way to reduce the control a large pool has over the network. The people posting in this thread want many small pools, the same as you. This is why I said you misunderstand the point of this thread.
Ah .. ok ... thank you .. I thought some of you wanted big ones !! made no sense to me ..
much better ..
thank you. Apparently you misunderstand the point of this thread.
Ok .. never mind .. I'm outy
EDIT: /??? just asking but ..... if one MEGA goes down and the network can not adapt immediately .. then you get delays and a back log of transactions ... so the 'dictatorship' I was referring to was the MEGA that controls the network ... if it glitches, goes down, etc .. and everyone hurts ...
so .. am I still wrong about forcing the break up of MEGAs and creating smaller groups being better?No! You are wrong because you suggested that we want large pools.
so .. ?? deepbit goes down for 30 minutes and the network dies ... and you all want this ? ... 1 HUGE mining groups that dictates ....
? ... 1 HUGE mining groups that dictates ....This thread is an example of a way to reduce the control a large pool has over the network. The people posting in this thread want many small pools, the same as you. This is why I said you misunderstand the point of this thread.
Jump to: