OROBTC (OP)
Legendary
Offline
Activity: 2926
Merit: 1863
|
|
June 10, 2014, 08:29:34 PM |
|
...
Hey, Discus Fish, BTC Guild, Eligius, Slush!
Then make it attractive (easy and somewhat profitable) to let us prospective cloudminers in! Many, many BTC await you...
Easy-Peasy! MOAR BTC, less GHash.IO, is that not what we all want?
Now get cracking!
***
And while you are at it, offer a good mixing service too!
|
|
|
|
David Rabahy
|
|
June 11, 2014, 09:30:21 PM |
|
How can pools be reliably inhibited from growing too large?
|
|
|
|
norgan
|
|
June 13, 2014, 12:34:04 AM |
|
How can pools be reliably inhibited from growing too large?
by using p2pool that is distributed!
|
|
|
|
David Rabahy
|
|
June 13, 2014, 03:07:56 PM |
|
How can pools be reliably inhibited from growing too large?
by using p2pool that is distributed! That's opt-in; I want some technique for rejecting blocks from pools that are too large.
|
|
|
|
Littleshop
Legendary
Offline
Activity: 1386
Merit: 1004
|
|
June 13, 2014, 03:33:58 PM |
|
How can pools be reliably inhibited from growing too large?
by using p2pool that is distributed! That's opt-in; I want some technique for rejecting blocks from pools that are too large. Can't work. Pool would do something to make itself look like two or more smaller pools.
|
|
|
|
norgan
|
|
June 13, 2014, 03:37:05 PM |
|
All you can do is help users understand that aside from variance, it doesn't matter what pool you mine on as far as profit goes and help them understand how important it is to use distributed pools
|
|
|
|
flound1129
|
|
June 14, 2014, 01:15:42 AM |
|
How can pools be reliably inhibited from growing too large?
. By educating people (miners) about variance and how small of a factor it is compared to other factors (assuming a pool is at a sufficient size.)
|
Multipool - Always mine the most profitable coin - Scrypt, X11 or SHA-256!
|
|
|
ShakyhandsBTCer
Sr. Member
Offline
Activity: 448
Merit: 250
It's Money 2.0| It’s gold for nerds | It's Bitcoin
|
|
June 14, 2014, 02:32:27 AM |
|
How can pools be reliably inhibited from growing too large?
. By educating people (miners) about variance and how small of a factor it is compared to other factors (assuming a pool is at a sufficient size.) Variance can be a large factor assuming that the bigger pool can get you closer to 100% Another issue with ghash is that they offer merged mining that can increase profitability by ~3% and merged mine coins that have no value now but could possibly in the future (basically a lottery ticket) but the coins are held at the pool so there is no need to download a client of a shit coin.
|
|
|
|
flound1129
|
|
June 14, 2014, 11:16:13 AM |
|
How can pools be reliably inhibited from growing too large?
. By educating people (miners) about variance and how small of a factor it is compared to other factors (assuming a pool is at a sufficient size.) Variance can be a large factor assuming that the bigger pool can get you closer to 100% Variance is not a large factor with any pool over 1PH. Other factors have a higher influence on overall profits. Math here: https://bitcointalk.org/index.php?topic=651450.msg7301307#msg7301307 Another issue with ghash is that they offer merged mining that can increase profitability by ~3% and merged mine coins that have no value now but could possibly in the future (basically a lottery ticket) but the coins are held at the pool so there is no need to download a client of a shit coin.
ghash's merged mining does not increase profits by anywhere near 3%. In fact IXC and DVC are worth so little that merged mining them probably increases stales shares more than the potential profit to be made. Namecoin is less than 1% (0.84% at the time of this writing), and the other two are more like 0.01-0.05% each. You can speculate that they may be worth more in the future, but that really has no place in a calculation of today's profits.
|
Multipool - Always mine the most profitable coin - Scrypt, X11 or SHA-256!
|
|
|
ShakyhandsBTCer
Sr. Member
Offline
Activity: 448
Merit: 250
It's Money 2.0| It’s gold for nerds | It's Bitcoin
|
|
June 14, 2014, 04:53:31 PM |
|
How can pools be reliably inhibited from growing too large?
. By educating people (miners) about variance and how small of a factor it is compared to other factors (assuming a pool is at a sufficient size.) Variance can be a large factor assuming that the bigger pool can get you closer to 100% Variance is not a large factor with any pool over 1PH. Other factors have a higher influence on overall profits. Math here: https://bitcointalk.org/index.php?topic=651450.msg7301307#msg7301307 Another issue with ghash is that they offer merged mining that can increase profitability by ~3% and merged mine coins that have no value now but could possibly in the future (basically a lottery ticket) but the coins are held at the pool so there is no need to download a client of a shit coin.
ghash's merged mining does not increase profits by anywhere near 3%. In fact IXC and DVC are worth so little that merged mining them probably increases stales shares more than the potential profit to be made. Namecoin is less than 1% (0.84% at the time of this writing), and the other two are more like 0.01-0.05% each. You can speculate that they may be worth more in the future, but that really has no place in a calculation of today's profits. Yes the value of the coins add very little to today's profits in terms of GAAP accounting, but merged mining does not cost anything to do. Market participants will also try to get the best deal for them. If someone is selling their product they will sell it to the person willing to offer the highest price even if that price is .005% higher then the next highest bidder.
|
|
|
|
flound1129
|
|
June 14, 2014, 08:02:07 PM |
|
Yes the value of the coins add very little to today's profits in terms of GAAP accounting, but merged mining does not cost anything to do.
Actually it does. A new block header and template needs to be sent to all clients every time the merged coins have a new block on their network. If this results in even 0.1% more stale shares on your miner, then you've lost money compared to just mining BTC+NMC. If it results in 1% more stales, then you've lost money compared to just mining BTC alone.
|
Multipool - Always mine the most profitable coin - Scrypt, X11 or SHA-256!
|
|
|
Groc
Sr. Member
Offline
Activity: 560
Merit: 250
Bounty manager (https://t.me/Gudwinn)
|
|
June 14, 2014, 08:29:55 PM |
|
ghash.io should just make their pool system like p2pool, then miners still make more btc than other pools AND strengthen Bitcoin?!?!
Posted From bitcointalk.org Android App
|
|
|
|
eleuthria
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
June 14, 2014, 09:15:02 PM |
|
Yes the value of the coins add very little to today's profits in terms of GAAP accounting, but merged mining does not cost anything to do.
Actually it does. A new block header and template needs to be sent to all clients every time the merged coins have a new block on their network. If this results in even 0.1% more stale shares on your miner, then you've lost money compared to just mining BTC+NMC. If it results in 1% more stales, then you've lost money compared to just mining BTC alone. This. You can circumvent it slightly by not sending out new work for merge-mined chains when those blocks update. However, there is still overhead from running extra coins that will impact pool performance. Another coin daemon means more network communication, very marginally slowing things down. Another coin daemon means more hard drive access and CPU time when a block is found on the other coin. The bottleneck for most pool servers is in the coin daemon, when it is processing new blocks. Even on SSDs and fast processors, it is anywhere from 50-200ms worth of time for bitcoind to return a block template. This would take even longer if another daemon is processing a new block (which would happen if the most recent bitcoin block was also a merge mined block for that coin!), increasing the time it takes for the pool to move to the next block. There is not a single coin aside from Namecoin that actually merits the performance hit of merged mining. It's a small, virtually immeasurable amount of delay added, but the other merge mine coins are so worthless that it's not worth risking losing time on a BTC block.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
DrG
Legendary
Offline
Activity: 2086
Merit: 1035
|
|
June 14, 2014, 10:40:22 PM |
|
Ah people are willing to lose $5 to get a free penny I love this line of thinking
|
|
|
|
bbxx
|
|
June 15, 2014, 11:46:32 AM |
|
me and my friends have moved to polmine.pl it is best pool as primary or secondary, pps, 1% fee, merged mining, share distribution and many cool things you can point script miners too, doge, ltc is supported we have picostocks 1.6 ph and many >1 th miners also best miners list is cool https://polmine.pl/?action=hofregister in english and then switch to polish to see more detailed charts full translation is in progress
|
|
|
|
ShakyhandsBTCer
Sr. Member
Offline
Activity: 448
Merit: 250
It's Money 2.0| It’s gold for nerds | It's Bitcoin
|
|
June 15, 2014, 07:57:54 PM |
|
Yes the value of the coins add very little to today's profits in terms of GAAP accounting, but merged mining does not cost anything to do.
Actually it does. A new block header and template needs to be sent to all clients every time the merged coins have a new block on their network. If this results in even 0.1% more stale shares on your miner, then you've lost money compared to just mining BTC+NMC. If it results in 1% more stales, then you've lost money compared to just mining BTC alone. This. You can circumvent it slightly by not sending out new work for merge-mined chains when those blocks update. However, there is still overhead from running extra coins that will impact pool performance. Another coin daemon means more network communication, very marginally slowing things down. Another coin daemon means more hard drive access and CPU time when a block is found on the other coin. The bottleneck for most pool servers is in the coin daemon, when it is processing new blocks. Even on SSDs and fast processors, it is anywhere from 50-200ms worth of time for bitcoind to return a block template. This would take even longer if another daemon is processing a new block (which would happen if the most recent bitcoin block was also a merge mined block for that coin!), increasing the time it takes for the pool to move to the next block. There is not a single coin aside from Namecoin that actually merits the performance hit of merged mining. It's a small, virtually immeasurable amount of delay added, but the other merge mine coins are so worthless that it's not worth risking losing time on a BTC block. Is this on the pool server side or the miner side? If it is on the pool server side, would additional infrastructure (more servers, cloud computing instances) prevent any negative performance by the miners? Granted this additional infrastructure would mean added costs to the pool (and added costs to the miners in terms of less features and/or higher pool fees) but people tend to not think about these costs. If what you are saying is that it will take 200ms extra time to start a new block template by the miners then it would mean that there would be a 1 in 3000 chance that this delay would cause you to "miss out" on finding a block. This is based on the fact that there is a 1 in 600 chance that a block will be found every second and there are 1,000ms in one second. So as long as the added benefit of the merged mining is at least 0.03% that of mining BTC alone then you would end up on top. With a 50ms delay it would be 0.0083%. Is this correct, or I am misinterpreting something? Please be patient with me as I do not know a lot about mining at that intimate level of detail
|
|
|
|
show_off
Newbie
Offline
Activity: 52
Merit: 0
|
|
June 16, 2014, 06:02:22 AM |
|
I will personally support p2pool look through all my hashrate into it.
|
|
|
|
flound1129
|
|
June 16, 2014, 08:34:21 AM |
|
Yes the value of the coins add very little to today's profits in terms of GAAP accounting, but merged mining does not cost anything to do.
Actually it does. A new block header and template needs to be sent to all clients every time the merged coins have a new block on their network. If this results in even 0.1% more stale shares on your miner, then you've lost money compared to just mining BTC+NMC. If it results in 1% more stales, then you've lost money compared to just mining BTC alone. This. You can circumvent it slightly by not sending out new work for merge-mined chains when those blocks update. However, there is still overhead from running extra coins that will impact pool performance. Another coin daemon means more network communication, very marginally slowing things down. Another coin daemon means more hard drive access and CPU time when a block is found on the other coin. The bottleneck for most pool servers is in the coin daemon, when it is processing new blocks. Even on SSDs and fast processors, it is anywhere from 50-200ms worth of time for bitcoind to return a block template. This would take even longer if another daemon is processing a new block (which would happen if the most recent bitcoin block was also a merge mined block for that coin!), increasing the time it takes for the pool to move to the next block. There is not a single coin aside from Namecoin that actually merits the performance hit of merged mining. It's a small, virtually immeasurable amount of delay added, but the other merge mine coins are so worthless that it's not worth risking losing time on a BTC block. Is this on the pool server side or the miner side? If it is on the pool server side, would additional infrastructure (more servers, cloud computing instances) prevent any negative performance by the miners? Granted this additional infrastructure would mean added costs to the pool (and added costs to the miners in terms of less features and/or higher pool fees) but people tend to not think about these costs. If what you are saying is that it will take 200ms extra time to start a new block template by the miners then it would mean that there would be a 1 in 3000 chance that this delay would cause you to "miss out" on finding a block. This is based on the fact that there is a 1 in 600 chance that a block will be found every second and there are 1,000ms in one second. So as long as the added benefit of the merged mining is at least 0.03% that of mining BTC alone then you would end up on top. With a 50ms delay it would be 0.0083%. Is this correct, or I am misinterpreting something? Please be patient with me as I do not know a lot about mining at that intimate level of detail There are a lot of variables, many of which aren't easily quantified.
|
Multipool - Always mine the most profitable coin - Scrypt, X11 or SHA-256!
|
|
|
norgan
|
|
June 16, 2014, 09:29:26 AM |
|
If you cache or run ram drives and have good low latency links then you can run them no probs
|
|
|
|
7queue
|
|
July 04, 2014, 01:40:39 AM |
|
What happens if/when a Nation State does this?
8 )
|
8 )
|
|
|
|