Bitcoin Forum
December 06, 2016, 06:15:08 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   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 17830 times)
rezin777
Full Member
***
Offline Offline

Activity: 154


View Profile
May 21, 2011, 11:44:43 PM
 #61

Apparently you misunderstand the point of this thread.

Ok .. never mind .. I'm outy  Smiley


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 ... Huh so .. am I still wrong about forcing the break up of MEGAs and creating smaller groups being better?Huh

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  Huh? ... 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.
1481048108
Hero Member
*
Offline Offline

Posts: 1481048108

View Profile Personal Message (Offline)

Ignore
1481048108
Reply with quote  #2

1481048108
Report to moderator
1481048108
Hero Member
*
Offline Offline

Posts: 1481048108

View Profile Personal Message (Offline)

Ignore
1481048108
Reply with quote  #2

1481048108
Report to moderator
1481048108
Hero Member
*
Offline Offline

Posts: 1481048108

View Profile Personal Message (Offline)

Ignore
1481048108
Reply with quote  #2

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

Posts: 1481048108

View Profile Personal Message (Offline)

Ignore
1481048108
Reply with quote  #2

1481048108
Report to moderator
1481048108
Hero Member
*
Offline Offline

Posts: 1481048108

View Profile Personal Message (Offline)

Ignore
1481048108
Reply with quote  #2

1481048108
Report to moderator
thefiatfreezone
Jr. Member
*
Offline Offline

Activity: 31


View Profile WWW
May 21, 2011, 11:48:50 PM
 #62

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.

Ah .. ok ... thank you .. I thought some of you wanted big ones !! made no sense to me ..
much better .. Smiley thank you.
rezin777
Full Member
***
Offline Offline

Activity: 154


View Profile
May 21, 2011, 11:54:36 PM
 #63

Ah .. ok ... thank you .. I thought some of you wanted big ones !! made no sense to me ..
much better .. Smiley 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).  Angry
thefiatfreezone
Jr. Member
*
Offline Offline

Activity: 31


View Profile WWW
May 21, 2011, 11:56:38 PM
 #64

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

So when does the new 'client' come out with the additions/modifications?   and please forgive this .. but what's F@H???
rezin777
Full Member
***
Offline Offline

Activity: 154


View Profile
May 22, 2011, 12:10:55 AM
 #65

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

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

Activity: 308


Timekoin - Save Electricity, Don't Waste It!


View Profile WWW
May 22, 2011, 03:20:29 AM
 #66

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?

Basiley
Jr. Member
*
Offline Offline

Activity: 42


View Profile
May 22, 2011, 03:46:59 AM
 #67

is anyone communicating with pool managers to depoy such changes ?
cuddlefish
Full Member
***
Offline Offline

Activity: 126



View Profile
May 22, 2011, 04:07:35 AM
 #68

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.

nanotube
Hero Member
*****
Offline Offline

Activity: 485


View Profile WWW
May 22, 2011, 06:32:58 AM
 #69

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

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

Activity: 126



View Profile
May 22, 2011, 06:56:20 AM
 #70

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.
the creation of coinbase tx, the monitoring of the network and inclusion of transactions into the block, etc, is done client-side.


I figured doing the coinbase TX on server-side'd make it easier to check.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
May 22, 2011, 09:58:40 PM
 #71

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 <x>, <y>, <z>" as well...

cuddlefish
Full Member
***
Offline Offline

Activity: 126



View Profile
May 22, 2011, 10:13:18 PM
 #72

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 <x>, <y>, <z>" 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.

goatpig
Legendary
*
Offline Offline

Activity: 1316

Armory Developer


View Profile
May 22, 2011, 10:21:08 PM
 #73

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 <x>, <y>, <z>" 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.

btcarmory.com
cuddlefish
Full Member
***
Offline Offline

Activity: 126



View Profile
May 22, 2011, 10:48:05 PM
 #74

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 <x>, <y>, <z>" 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.

goatpig
Legendary
*
Offline Offline

Activity: 1316

Armory Developer


View Profile
May 22, 2011, 10:55:10 PM
 #75

The pool can check that the transactions fit the inclusion rules, and reject shares where they don't.

Sure that too.

btcarmory.com
FairUser
Sr. Member
****
Offline Offline

Activity: 261


View Profile WWW
May 22, 2011, 11:38:41 PM
 #76

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

Activity: 126



View Profile
May 22, 2011, 11:43:20 PM
 #77

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

:/

nanotube
Hero Member
*****
Offline Offline

Activity: 485


View Profile WWW
May 23, 2011, 04:15:44 AM
 #78

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!

:/

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

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
goatpig
Legendary
*
Offline Offline

Activity: 1316

Armory Developer


View Profile
May 23, 2011, 07:59:32 AM
 #79

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!

:/

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.

btcarmory.com
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
May 23, 2011, 12:12:08 PM
 #80

You still need a way to get work at a specific difficulty and for a specific public key
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!