c_k: yes and I don't see why it would cripple cgminer. As I understand it (I'm no expert on cgminer) it lowers stales two ways, by prefetching work and by monitoring other pools to see if they move to a new block before the one yr mining does.

I'm not proposing to disable prev_block_hash checks, just to accept that when a LP comes in (as long it's a proper longpoll response with a full payload) that it should start working on that work and replace it's cached work. Prefetching still happens, it isn't nerfed at all, it just happens a little more often. Monitoring other pools still gives potential advantages, it's just limited to detecting new blocks on the parent chain (bitcoin).

So no functionality is lost as far as I can see. Some of the benefits of cgminer won't work as well for aux chain changes but there'll be no loss of functionality for the main chain so the net effect is +ve and still in excess of what other mining sw does.

kano: I'm not here to debate the merits of merged mining. I'm not a fan either. But the market has spoken and miners want it so if cgminer is crippled for merged-mining compared to other mining s/w (and I'd call stales several times higher competitively crippled) it's going to rapidly lose users. I'm just presenting a solution to yet another problem MM has caused. It's not really even in my interests do so. Most of the miner specific issues I've had to deal with for poolserverj are issues with cgminer trying to be too clever so quite frankly it would make my life easier if conman gave MM the finger and refused to deal with it. Still it would be a shame to lose such a well engineered tool to obsolescence.

I'd like to defend Merged Mining though I'm not a fan of it. Despite all the drawbacks, I can see one big advantage - more profit, so Merged Mining helps to pay for electricity bills in the time of crisis

It depends how the pool handles them. As far as I can tell for most pools that use MMP the problem will be hidden so the miner is unlikely to see the stales even though they're occurring. When psj-mm edition got to the part about handling these (because psj-mm has it's own native implementation and doesn't use merged-mining-proxy) we started seeing mass stales and began investigating. Of course psj got the blame initially because it appeared other pools were working fine (even I thought it was something wrong with psj). But after getting all the per chain block tracking working it became pretty clear what was going on...

I know for a fact that NMCBit is wearing the losses at the moment. They are using PSJ + MMP. Psj is NOT compatible with MMP, the problem being that psj doesn't know when to switch to new blocks because MMP doesn't send the right signals. He is copping a LOT of stales but you are not seeing them and because the pool is PPS it's him that's wearing cost, he's not passing it on to miners. When he switches to psj-mm edition this will probably change a little as you'll actually start seeing yr own real stales. To clarify atm nmcbit is suffering two kinds of stales, the normal kind that is miner related (which miners should be paying for) and the bonus stales from the PSJ MMP incompatibility. He's taking the losses for both right now. With psj-mm the second kind won't happen but the first kind will be transferred back to the miners where it belongs.

I can't comment on slush as he uses his own custom pool software. I suspect he's probably eating the aux chain stales as well. Even if he's sending LP when the aux chains update and dealing with the double LP problem he still won't be able to force cgminer clients to switch.

It's probably worth noting that a proportional pool won't actually incur obvious costs from this problem. Unless they go looking the problem will likely only become apparent after a while when they calculate pool luck for the alt chains.

I can't comment on slush as he uses his own custom pool software. I suspect he's probably eating the aux chain stales as well. Even if he's sending LP when the aux chains update and dealing with the double LP problem he still won't be able to force cgminer clients to switch.

It's probably worth noting that a proportional pool won't actually incur obvious costs from this problem. Unless they go looking the problem will likely only become apparent after a while when they calculate pool luck for the alt chains.

[/quote]

I think I can provide some insight. IIRC Slush doesn't calculate shares on NMC. The NMC reward for all NMC blocks during one BTC block is simply split based on how the BTC block % (modified because not all miners are collecting NMC rewards). Slush eventually wants to change this but this method was a way to get NMC off the ground quickly. If the block is good for BTC then it isn't rejected as stale by Slush pool.

Thus an individual miner isn't going to see a problem on Slush pool. I certainly haven't for my two rigs pointed there. However if what you say is right then the efficiency is NMC collection is affected. Meaning the pool as a whole isn't getting the max NMC for the raw hashpower it has which lowers average NMC reward for all miners (regardless of if they use cgminer or not).

Bingo on the "luck" for NMC. I don't know if anyone has run any NMC luck stats. Doing so might be tough with limited information available on NMC block (at least for slush pool) however I suspect your a right as length of history increases we would expect to see pools being "unlucky" when it comes to NMC blocks. If 5% of hashes worked on by a pool have invalid NMC data then it isn't "luck" (they never had a chance) but it will show up as a 5% unlucky (5% less NMC collected then the expected value given hashrate if all hashes are valid).

However if what you say is right then the efficiency is NMC collection is affected.

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.

However if what you say is right then the efficiency is NMC collection is affected.

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.

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

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.

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

So when you submit a share the server would1) 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.

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

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?

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.

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.

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

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?

I don't want to add fuel to the fire and think merged-mining debate should be happening elsewhere

Agreed! Where?Sam

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.

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)

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLUFreeNode IRC: irc.freenode.net channel #kano.isMajority developer of the ckpool codeHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!

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.

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.

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.

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

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?

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.

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.