Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 755. (Read 5805728 times)

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.

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.

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.

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.  

For merged mining? It's not something new... https://bitcointalksearch.org/topic/m.105915

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.

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.

So— We shouldn't have pools with stats?  We shouldn't have pools with different payout systems (e.g. hopping resistant ones)?  We shouldn't have pools that can pay users directly out of the coinbase?   We shouldn't have distributed pools?  We shouldn't have ntime rolling? We shouldn't have miners with pool redundancy?

Every one of these software features carries risk in fact, I'm aware of examples where an implementation of every single one of these has had bugs and caused outages for their users.   Importantly— in all of these cases only the people benefiting from the changes suffered from them, and the same is true of merged mining.

For a while I've been mining solo, quite enjoyably and profitably— but I switched back to mining on eligius for the time being because Luke had merged mining working and I didn't want to dork around with it (and that python proxy looked like crap to me).  I considered the costs of MM for me and decided on a course of action that made sense for me. You should do that too.

Well, I haven't heard much hard fact as to what Namecoin is why anyone would want it.  People have said that Merged Mining is easy to implement so therefore it should be done.

But then people start talking about how it could destabilize pools and cause stales and loose shares from one currency or the other.

There is no free ride, there are consequences to everything. If there is any chance that it could damage the reliability or value of Bitcoin then it shouldn't be messed with.  I just don't see where this whole idea of Merged Mining has been thought through whether it be namecoin or some other thing.

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

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.

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

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.

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)

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.

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.

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.

So, I think it's clear that merged mining is technology which is good for bitcoin even if the specific usage with NMC is boring and the software is having growing pains.

As a reminder, DiabloMiner has no problem with merged mining, so until ck fixes this you can switch.

Well other than the bitcoin unrelated and bitcoin related comments I've already made ...

It's tying a block-chain that doesn't work to bitcoin.
Namecoin doesn't work. After all the time it has existed they still haven't completed the actual namecoin functionality.
It was dying and the solution to keeping it alive was to make mining them free.
i.e. tying a dying value-less functionally-failed block-chain to bitcoin and have everyone mining bitcoins mine them also.
I can't see that being good for bitcoin.

... and worse it opens the doors for other pump and dump scamcoins to doing the same thing
(which is also 1/2 of the reason why I requested the commit into the main bitcoin source that allows merged mining to be removed - but it wasn't)

Since this is my thread, I'm going to change the rules about what is considered offtopic. I wrote this miner to be the best mining software capable of mining bitcoins because I believe in bitcoin as a concept, not because I actually want to make a profit. I wanted fully featured software that.... well by now you all know what cgminer does, but my point is that I'm trying to support bitcoin by providing software that maintains the hashing power that gives bitcoin strength. Now since I have to be the one to decide what support goes into cgminer (unless someone forks it, which has been threatened before), I have to be convinced it is worthwhile. Now, namecoin aside, I personally think all the other coins can go fuck themselves and their get rick quick mentality. However, merged mining is slightly different, I do realise this, BUT I have yet to see a good argument for how it is anything good for bitcoin.

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.

Agreed!  Where?
Sam

I thought about BTC Guild after I posted.  But he is at around 1.1THs which is less than half that pie piece, however accurate that is.

Also I agree with moving the topic somewhere else but here.
Sam

I don't want to add fuel to the fire and think merged-mining debate should be happening elsewhere, but in spite of the fact that I am getting tired of reading about it, I will say the following to the anti-merged-mining whiners:

1) Even if it were a fad and it died, those 46 bytes here and there would never disappear on their own.

2) The hash rate doesn't matter unless it gets so low that the network is vulnerable; I have read plenty of things that specifically say that the plan was for the majority of bitcoin users NOT to be mining.

3) Greed is the biggest obstacle to bitcoin's survival, not the best motivator to keeping it alive (how many people think it was a big scheme / rip-off and won't come back because the value went sky high and then plummeted while they were "investing" in it [even though those people presumably don't invest in fiat currencies because of the obvious risks of currency investing]).  On that note, I haven’t read any anti-merged-mining rhetoric that didn’t smell like greed to me, although I do agree that it does appear to be a PITA for everyone other than end-users.

4) My opinion of most aux chains is that they will basically be money-making schemes for the author and anyone who jumps to them or tries to take advantage of them is probably just greedy and stupid.  Bitcoin should have no problem surviving without those people, and I believe the project is already working on deprecating unneeded blocks, which will probably free up space faster than those 46 byte will use it, and may have even been spurred by someone over-hyping the threat of that 46 bytes per block adding up.

5) I feel NMC doesn't fall into the category mentioned in (4) because it has inherent value in that it provides a potentially easy to use domain naming structure outside of government control (much like bitcoin provides a portable store of currency outside of government control), unfortunately, greedy miners prevent it from functioning if merged mining doesn't exist.  In that sense, I look at merged mining as more of an inoculation against the bad apples than a threat to bitcoin.  It also seems beneficial to me that bitcoin is going to be the typical parent blockchain, because this increases its presence, even if aux chains aren’t specifically dependent on it.

6) It is possible that other future chains will have their own (non-currency) values, and I withhold my opinion regarding them.

7) I’m sure that the majority of people in this thread have no interest in reading this post, and I have no interest in reading or subsequently thinking about the posts that lead me to go ahead and write this, so seriously, can we please stop going way off-topic in this thread and try to stick with useful posts?  Seriously, there have only been about 3 useful posts since a potential problem with cgminer (that wasn’t a problem before merged mining) was brought up.

You may want to direct yr grievance elsewhere.  I warned about the problems merged mining was going to cause before it went live.

however I will point out that the drop in hashrate has fuck all to do with merged mining.  A major part of the reason 'other' is so big atm is because btcguild has had a major restructure and doesn't seem to be recognized by btcwatch anymore.  They account for at least half of the 'other' category.

Everyone says that implementing merged mining is  SOOOooo... Easy that it is stupid to not do it.  Well what I see is possibly permanently devaluing Bitcoin and the potential to cripple the Bitcoin network.

There is allot that is unknown as to how to handle these scenarios.  Bitcoin was not intended to be a "Get Rich Quick Scheme".  I think this will just drive serious supporters of Bitcoin away or just into Solo Mining quietly.

As more Merged Mining comes online the network hash rate continues to decline and the "Other" chunk of hash rate distribution increases in size.  I don't think you guys have thought this out very thoroughly.  But what do I know?
Sam

psj is currently recording NMC only shares as our_result=yes reason=partial-stale.  This is an interim solution, there's a discussion on the psj thread atm to decide on the best strategy for recording this properly so pools have complete information for calculating shares that can account for more than one aux chain.

I agree it hasn't been conclusively proven but it does make sense.

How it likely will be "fixed" is keeping track of BTC/NMC shares & stales seperately. 

So when you submit a share the server would
1) Check if it is a valid BTC share.  If so increment BTC share count.  If not increment BTC stale count.
2) Check if it is a valid NMC share. If so increment NMC share count.  If not increment NMC stale count.

Returning NMC stale/reject message would require support of the miner.  Current miners are "merged mining" dumb.  They have no idea merged mining is even happening and thus wouldn't know what a BTC accepted, NMC stale message means.

My hypothesis is that while I have a very low stale count right now (0.1%).  If accounting like the above was implemented I would keep a lot BTC stale % but have a very high NMC stale %.  NMC is still seen by many as "free money" so likely we have some time to implement a solution.

If we can confirm this issue by a pool operator.  If Slush has the records he could look at my stales/invalid shares submitted (BTC vs NMC).  Once confirmed I would throw start the bounty pool by throwing 5 BTC towards it.

And I reiterate it's possible I'm wrong but what you say makes perfect sense in the context.  More to the point efficiency is being far more negatively affected by cgminer nodes and by non-cgminer nodes.  When pools rectify their accounting it will be the cgminer nodes that take the brunt of it since they are currently getting more than their 'fair shares'...  Pools will have to do this for the same reason many are feeling compelled to introduce merged mining... i.e. they are at a competitive disadvantage if they don't.  I say this without prejedice because I hope the situation for other pools will change quickly but poolserverj has uncovered this problem and is the first to deal with it properly so for the time being poolserverj-mm based pools offer miners better value for their hashes overall.  Once miners realize this the pressure will be on for other pools to sort it out.