Bitcoin Forum
December 10, 2016, 04:52:19 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 [94] 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4826749 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
os2sam
Legendary
*
Offline Offline

Activity: 1918


Think for yourself


View Profile
October 28, 2011, 11:37:26 PM
 #1861

There just aren't enough objective facts to warrant moving forward in my opinion.
Sam

Without the merged mining in place and working you will never have any facts to base an opinion on..

True, to an extent.  But shouldn't there be a firm specification in place before messing with something that works?  Specs can be modified and improved but that becomes difficult to manage when everyone goes off in different directions in their own development.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481388739
Hero Member
*
Offline Offline

Posts: 1481388739

View Profile Personal Message (Offline)

Ignore
1481388739
Reply with quote  #2

1481388739
Report to moderator
gmaxwell
Moderator
Legendary
*
Offline Offline

Activity: 2030



View Profile
October 28, 2011, 11:46:59 PM
 #1862

True, to an extent.  But shouldn't there be a firm specification in place before messing with something that works?  Specs can be modified and improved but that becomes difficult to manage when everyone goes off in different directions in their own development.

For merged mining? It's not something new... https://bitcointalk.org/index.php?topic=7219.msg105915#msg105915

As far as "goes off in different directions in their own development" you've described the situation with pools already. They can't use a single unified solution for merged mining because they don't use a single solution for their pool.  Most of the pool operators keep their software private— presumably as a competitive advantage.
shads
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
October 28, 2011, 11:50:06 PM
 #1863

There just aren't enough objective facts to warrant moving forward in my opinion.

Unfortunately you don't have a choice.  I'm not against the concept of merged mining, just the appalling way it was implemented and foisted on the bitcoin chain without proper documentation and testing.  All the destabilization issues we've seen were totally predictable.

The reason there is no choice is because of the 'moar profitz!' mentality.  This will ultimately be proven a false proposition imho but in the short term as some of the replies in this thread clearly demonstrate along with the rapid uptake, if you dangle more profits in front of miners they will take them.  At the end of the day there is no more money in the combined bitcoin/namecoin economies so what little value is left in namecoin after the market has fully digested the change will come off the top of bitcoin.  So being a non-merged miner still means you're missing out.

There's no point having the discussion 'should we support merged mining or not'.  It's happening whether we like it, whether are ready for it or not.  

PoolServerJ Home Page - High performance java mining pool engine

1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq - http://payb.tc/shads

Quote from: Matthew N. Wright
Stop wasting the internet.
shads
Full Member
***
Offline Offline

Activity: 224


View Profile WWW
October 28, 2011, 11:55:25 PM
 #1864

Importantly— in all of these cases only the people benefiting from the changes suffered from them, and the same is true of merged mining.

That is categorically not the case with merged mining.  Due to market forces as discussed above if you fail to adopt there is a cost.  This is particularly the case for pools.  If they adopt to avoid the cost of not doing so (i.e. not because they want to) there is also a cost.  Stability and significant performance hit.  They may not want the benefits but they can't afford not to have them.

PoolServerJ Home Page - High performance java mining pool engine

1LezqRatQz7MeNoCVziYwcdwtqeEbvrdAq - http://payb.tc/shads

Quote from: Matthew N. Wright
Stop wasting the internet.
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
October 28, 2011, 11:59:54 PM
 #1865

I think its an important point that combining hash power of NMC and BTC improve's both network's security.  I think cgminer should do its best to work properly with merged mining.

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
October 29, 2011, 12:55:59 AM
 #1866

Here is the reality.  It doesn't matter the merits of merged mining, it already exists.  Many pools have implemented it and many more likely will in the future.  You say talk about non-economics BUT it doesn't matter how good your miner is (and it is the best) if it is uneconomical. 

Eventually pools will start to reduce payouts for those miners submitting invalid NMC hashes.  So while cgminer may be the best miner we have seen it won't matter if using cgminer puts a miner in a competitive disadvantage.  I will hate to switch from cgminer to another alternative but if pools start to penalize for bad NMC hashes that is a decision I will have to weigh.

I hope that situation never happens as cgminer SHOULD respond to LP notifications by pools.  cgminer shouldn't assume the pool is wrong and it can ignore an LP by pool just because no block has changed.  A pool for example may have just found a juicy high fee transaction and has updated the merkle tree to maximize value of the pool.   The pool potentially has more information than cgminer so it should respond to any LP notification it gets.  At a minimum there should be a command line option to enable that functionality.  This goes beyond merged mining, merged mining simply highlights this potential issue.  As times goes on there may be lots of different reasons why a pool needs to issue a LP that doesn't involve a block change.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 29, 2011, 01:06:09 AM
 #1867

Here is the reality.  It doesn't matter the merits of merged mining, it already exists.  Many pools have implemented it and many more likely will in the future.  You say talk about non-economics BUT it doesn't matter how good your miner is (and it is the best) if it is uneconomical. 

Eventually pools will start to reduce payouts for those miners submitting invalid NMC hashes.  So while cgminer may be the best miner we have seen it won't matter if using cgminer puts a miner in a competitive disadvantage.  I will hate to switch from cgminer to another alternative but if pools start to penalize for bad NMC hashes that is a decision I will have to weigh.
There is no such thing as a bad NMC hash in relation to this.
It has nothing to do with hashing.
It has to do with the pool sending back information about different chains ...

I hope that situation never happens as cgminer SHOULD respond to LP notifications by pools.  cgminer shouldn't assume the pool is wrong and it can ignore an LP by pool just because no block has changed.  A pool for example may have just found a juicy high fee transaction and has updated the merkle tree to maximize value of the pool.   The pool potentially has more information than cgminer so it should respond to any LP notification it gets.  At a minimum there should be a command line option to enable that functionality.  This goes beyond merged mining, merged mining simply highlights this potential issue.  As times goes on there may be lots of different reasons why a pool needs to issue a LP that doesn't involve a block change.
The definition of LP is to notify of a block change - LP in itself is badly implemented but that is how it has been done.
How this hack has been added on top of LP ... well I wonder if it is even works properly ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
October 29, 2011, 01:11:03 AM
 #1868

It has to do with the pool sending back information about different chains ...
They never do. It is impossible to detect merged mining on the miner end.
The definition of LP is to notify of a block change - LP in itself is badly implemented but that is how it has been done.
How this hack has been added on top of LP ... well I wonder if it is even works properly ...
No, the definition of LP is to notify miners of new blocks, which could have the "prevblock" header changed-- or might not. As others have noted, there are plenty of other reasons a pool might do a longpoll without changing "prevblock". When receiving a LP response, miners are supposed to discard their old work (it's "stale", which is a term defined by your particular pool) and start working on the new work provided. Not doing so is a bug. Since most miners don't have this bug, it would fit in the "makes cgminer not the best bitcoin miner" category.

kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 29, 2011, 01:28:09 AM
 #1869

So I'm going to open up the discussion and I would like to see arguments for why I should or should not explicitly support merged mining, and I ONLY want to see arguments that don't include "it is more profitable". More profit by "earning" namecoin at the same time as earning bitcoin does not support anything to do with bitcoin as a concept of a cryptocurrency that ultimately makes free trade possible.

Before I respond to it I think it's important to emphasize that there is _NOTHING_ fundamental about the problem here.  Regardless of merged mining the bitcoin daemon needs to be able to tell workers that they need to move on to new work— this arises without prev changing due to merged mining, sure,  but it is just as equally an issue if a new txn with high fees hits the memory pool, a pool server is simply restarted, or a network failure switches remote miners to another datacenter.
So why not implement a new notification rather than mess up LP so it no longer does what it was designed to do ....

Quote
Many people misunderstand merged mining— they think things like it means automatically switching between systems, or that it lowers the work useful work miners do on bitcoin. This is not true (save any software bugs that crop up while adding the feature— but you can say this about _ANY_ feature).
Well yes even the people who documented it didn't even get it right ... but when asked to correct it they wont.
However ... "save any software bugs that crop up while adding the feature" is probably the whole point of this discussion
So fobbing it of as something minor shows a lack of understanding of the whole discussion ...

Quote
Now, as far as the goodness of MM goes— forget about the profitability of it, it's not why MM is important.   Merged mining is a major improvement in the fundamental trustworthyness of Bitcoin:

Prior to merged mining,  adopters of bitcoin took the risk that IF bitcoin lost popularity (or, even didn't lose popularity but mining became less attractive due to energy costs, declining rewards, etc)  THEN bitcoin would NECESSARILY become insecure— and vulnerable to reversal attacks.

With the existence of merged mining bitcoin being popular or profitable-to-mine is still sufficient for security but it is no longer strictly necessary:  Bitcoin is secure so long as the sum of ALL distributed systems which use the nakamoto block chain distributed consensus and share work with bitcoin, some of which may have no "coins" at all,  are popular enough to provide enough mining hash power for security.
Namecoin is ONLY leveraging off Bitcoin - there is no such hyperthetical other way around.
As I said before, if not for merged mining, namecoin would die since most people don't want it.
If enough people wanted it, then it wouldn't have been dying in the first place.

The same is true of Bitcoin itself.
If most people don't want it and use it, it will die.
Simple.
Unfortunate for those who want it and use it, but if there aren't enough to keep it alive, it dies.
At the moment it is staying alive - good for everyone here and myself.
If people don't back it and use it, but instead leverage off it and take away it's value by trying to keep alive something that most people don't want, then that will hurt Bitcoin exactly as do scamcoins.

Quote
For example of a very different application: P2Ppool now uses merged mining to achieve consensus about the distribution of payouts for the distributed pool.

Merged mining is also very good for bitcoin because it reduces the incentive for various parasitic behaviors.  For example, some people have wanted to cram random data into the block-chain for proving time of creation.  This is bad for all bitcoin users because our system fundamental depends on flooding and near global awareness— bitcoin is the least efficient data storage system used by man (short of our own genome).   Merged mining would allow these parasitic loads to exist in separate chains.  (Importantly, the _only_ cost to bitcoin for merged mining is a single hash in the coinbase, and whatever software bugs miners suffer while implementing it, and MM has O(1) scaling— with one additional hash in the coinbase we can support an infinite number of merged chains)
The code commit to add merged mining also allows for EXACTLY this you are saying is bad. EXACTLY this.

Quote
Also, In cases where a system using the same computing resources becomes as interesting as bitcoin mining you risk hash power oscillation unless you have merged mining. At one point we had a good few hundred GH/s bouncing between NMC and Bitcoin every difficulty change.  Because bitcoin was still growing hashpower quickly at this point it wasn't a terrible problem (well it was pretty devastating on namecoin, and only wasn't on bitcoin because bitcoin miners were fortunately slow to respond to the extreme profitability of namecoin). But if the swing had instead been twice as high or happened when we had declining hash power we would have been seeing very noticeable cycles of slow blocks.
That's a strange argument in favour of it Tongue
Basically saying that if (though it wont happen) Namecoin reaches Bitcoin then ...
So you are arguing against Bitcoin Cheesy

Quote
It's also the case that you're wrong to ignore profitability. Because the profitability of mining contributes to the attractiveness of adding lots of hash power legitimately which provides bitcoin's security (as opposed to the profitability of using hash power to attack).  If you make legit mining more profitable you make bitcoin more secure.
Simple: It takes it from Bitcoin.
They are free coins thus with no value - where do they get value? By taking it from Bitcoin.

Quote
Finally, even in cases where you can argue that MM is bad (perhaps the various scam-coins) you can't actually prevent merged mining. The current system works cooperatively with the binding in the coinbase txn, but you could always bind other hashchains by stuffing the binding hash in a parasitic transaction.
Again, this is exactly what the commit that went into Bitcoin to allow for merged mining to work with the base code also allows to occur with the base Bitcoin code.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 29, 2011, 01:28:31 AM
 #1870

It has to do with the pool sending back information about different chains ...
They never do. It is impossible to detect merged mining on the miner end.
You don't see the problem there ... ?

The definition of LP is to notify of a block change - LP in itself is badly implemented but that is how it has been done.
How this hack has been added on top of LP ... well I wonder if it is even works properly ...
No, the definition of LP is to notify miners of new blocks, which could have the "prevblock" header changed-- or might not. As others have noted, there are plenty of other reasons a pool might do a longpoll without changing "prevblock". When receiving a LP response, miners are supposed to discard their old work (it's "stale", which is a term defined by your particular pool) and start working on the new work provided. Not doing so is a bug. Since most miners don't have this bug, it would fit in the "makes cgminer not the best bitcoin miner" category.
Show me the documentation ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
October 29, 2011, 01:35:01 AM
 #1871

Show me the documentation ...
https://deepbit.com/longpolling.php

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
October 29, 2011, 01:43:48 AM
 #1872

So why not implement a new notification rather than mess up LP so it no longer does what it was designed to do ....

LP is used to indicate a change in block for miner to hash.

There are many reasons this can be used.
1) New block has been found
2) New transactions have been added to block
3) Merged Mining hash has changed
4) As a countermeasure against "block withholding attack"
5) ... (any other reason pool determines block header should change)

The most common reason for LP is because a new block has been found but that isn't the only reason.  Even without merged mining it is very likely pools will have reason to indicate a block change.  As block rewards decline and transaction fees hopefully increase pools will need to maximize transaction fee value and may indicate a change in block because they hashed in a high fee transaction.

The threat of "block withholding" may become more prevalent in the future.  A countermeasure for that is for the pool to issue a found block to pool members and if they "fail to find the hash" then flag them as potential attackers.  If cgminer doesn't properly respond to blocks changes via LP it would improperly make it look like those miners are withholding blocks.

Lastly there may be as of yet unknown reasons why pool may need to change the block that miners in the pool are working on.  Regardless of the reason the miner should change when given new block data.

Even if merged mining didn't exist the proper response to a miner receiving an updated block via LP is to work on that block.  If your hatred of merged mining didn't blind you then you would see cgminer's response is flawed and should be fixed regardless.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 29, 2011, 01:58:14 AM
 #1873

... hmm that's an interesting argument against merged mining
An LP represents a loss of work.
Throw away your incomplete work (or stop it and throw it away) and start new work.
This is where most stales occur and thus the related issues.

So merged mining adds many more of these
Actually a lot more since one will occur every namecoin block which is currently 15 times per bitcoin block
Hmm yep so I'd expect a 15 times increase in bitcoin stales due to merged mining if you force people bitcoin mining to take notice of namecoin mining block changes.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
DiabloD3
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
October 29, 2011, 02:00:13 AM
 #1874

... hmm that's an interesting argument against merged mining
An LP represents a loss of work.
Throw away your incomplete work (or stop it and throw it away) and start new work.
This is where most stales occur and thus the related issues.

So merged mining adds many more of these
Actually a lot more since one will occur every namecoin block which is currently 15 times per bitcoin block
Hmm yep so I'd expect a 15 times increase in bitcoin stales due to merged mining if you force people bitcoin mining to take notice of namecoin mining block changes.

Wrong, stales happen because you DONT throw the work away fast enough. Namecoin through merged mining can't generate stales.

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
October 29, 2011, 02:04:55 AM
 #1875

... hmm that's an interesting argument against merged mining
An LP represents a loss of work.

No it doesn't.  There is no lost work, prior work has absolutely no value.  You either have a solution or you have nothing.

Quote
So merged mining adds many more of these
Actually a lot more since one will occur every namecoin block which is currently 15 times per bitcoin block
Hmm yep so I'd expect a 15 times increase in bitcoin stales due to merged mining if you force people bitcoin mining to take notice of namecoin mining block changes.

Most miners get new work many times per minute even w/o LP.  My rigs are 2GH/s and I pull 20+ getworks per minute.  A few more LP is insignificant.  Also it is closer to 9NMC blocks per BTC block now.  As NMC hash rate continues to climb and the cost to merged mine drops the # of NMC blocks per BTC will decline likely in the future become <2 NMC : 1 BTC.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 29, 2011, 02:13:10 AM
 #1876

... hmm that's an interesting argument against merged mining
An LP represents a loss of work.

No it doesn't.  There is no lost work, prior work has absolutely no value.  You either have a solution or you have nothing.

Quote
So merged mining adds many more of these
Actually a lot more since one will occur every namecoin block which is currently 15 times per bitcoin block
Hmm yep so I'd expect a 15 times increase in bitcoin stales due to merged mining if you force people bitcoin mining to take notice of namecoin mining block changes.

Most miners get new work many times per minute even w/o LP.  My rigs are 2GH/s and I pull 20+ getworks per minute.  A few more LP is insignificant.  Also it is closer to 9NMC blocks per BTC block now.  As NMC hash rate continues to climb and the cost to merged mine drops the # of NMC blocks per BTC will decline likely in the future become <2 NMC : 1 BTC.

Firstly to both of you.
Look at the output of your miner.
Where do stales occur?


Secondly: no that 15 times was based of the current blocks when I typed it.
I'll do it again:
BTC difficulty = 1468195.4272208 (and will be for about another 2 days)
NMC difficulty = 94037.337 (block 24191)

1468195.4272208 / 94037.337 = 15.61...

Edit: and the obvious: an LP and a work request are two completely different things.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
October 29, 2011, 02:26:03 AM
 #1877

1) A LP doesn't cause a stale.  Stales are determined by the pool.  If the block is still valid for BTC the pool shouldn't consider it stale.  The pool may improperly consider the BTC share stale but that will happen no matter what cgminer does.  If cgminer ignores the LP and keeps mining the pool will still consider the share invalid if its stale logic is flawed.

As a practical example though, Sush pool doesn't consider a share to be stale even if it is invalid for the current NMC block as long as it is valid for the BTC block.  So regardless of if cgminer ignores the LP or not the share would be considered valid however if it ignores the LP it is no longer working on valid NMC hashes.  Now currently Slush doesn't have seperate stale count for NMC shares so they are considered valid BUT it lowers the overall pool efficiency because all those shares after the LP and before next getwork() can't produce valid NMC blocks.

2) NMC difficulty is currently ~156K and rising fast.  

Current ratio is ~9:1
On 10/31 it will be ~7:1
On 11/03 it will be ~5:1

It is likely more pools will adopt merged mining.  BTC Guild is looking into merged mining so when they implement it that single pool is >1GH which would put the hashrate ratio ~3:1 (although it will take at least one diff adj for ratio to catch up).  Ultimately if NMC hashrate ever reached 51%+ of BTC then the number of NMC : BTC blocks would be <2:1.

http://dot-bit.org/tools/nextDifficulty.php

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
October 29, 2011, 02:39:01 AM
 #1878

I'm loathe to adding yet more confusing command line options when many people mine blindly with defaults.
I'm also unhappy about throwing out work blindly whenever a LP comes without it actually being a real block change.
I'm most unhappy going out of my way to support another network, whatever it is.
However, having sane defaults and the most efficient mining on BTC are my desired endpoints.
If someone is merged mining, they will receive a lot more longpolls if I'm not mistaken.
If they're not merged mining the longpolls should match block changes and whatever other reasons the pools actually use - It's my impression that they're all theoretical arguments and non merged-mining pools ONLY use longpoll for a block change.
Therefore, throwing out work blindly with a longpoll that doesn't have a corresponding detected block change, without adding any more command line options, is the most unobtrusive change that I can think of and I will do so in the next version.

Merged mining discussion is now closed. Thank you all for your prompt submissions.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
October 29, 2011, 02:44:52 AM
 #1879

...
2) NMC difficulty is ~156K and rising fast.  

Current ratio is ~9:1
On 10/31 it will be ~7:1
On 11/03 it will be ~5:1

It is likely more pools will adopt merged mining and if NMC hashrate ever just 51% of BTC then the number of NMC : BTC blocks would be <2:1.

http://dot-bit.org/tools/nextDifficulty.php


Hmm yep oh well I looked at http://blockexplorer.sytes.net/
Which is wrong. Thanks for the link with the correct value Smiley

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
gmaxwell
Moderator
Legendary
*
Offline Offline

Activity: 2030



View Profile
October 29, 2011, 03:01:12 AM
 #1880

That is categorically not the case with merged mining.  Due to market forces as discussed above if you fail to adopt there is a cost.  This is particularly the case for pools.  If they adopt to avoid the cost of not doing so (i.e. not because they want to) there is also a cost.  Stability and significant performance hit.  They may not want the benefits but they can't afford not to have them.

The data clearly does not support your claim. Hell, we have basically half our hash power on a pool without (disclosed) merged mining.
Pages: « 1 ... 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 [94] 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 ... 830 »
  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!