Bitcoin Forum

Its been a while now that people have been running merged mining of various numbers of blockchains.

So, anyone getting any decent ballpark estimates yet of how much per additional blockchain it is actually costing to mine more than just one blockchain?

-MarkM-

Why would it cost anything at all?

I know that I have spent some time per chain setting them up and monitoring them, trying geistgeld a number of times and finally having to decide to run without it for now as it is too heavy on resources, trying RUCoin for a while and finding problems with that too thus dropping that too, having to get and compile and try new versions of I0Coin from time to time, and so on. If I was working for a company charging for my time ten or twenty years ago they would have been billing my time at at least twice as much per hour as they were paying me.

So I figure there would be some overhead of that kind in addition to the additional network bandwidth of running another chain, additional disk space usage, additional CPU time used and so on.

All that stuff is not free.

Basically I am trying to get some general idea of how much the transaction fees of a chain are going to have to add up to per month in order for pools and large mining institutions to be able to actually profit at least some tiny amount by adding that chain to their merged-mining lineup...

-MarkM-

Your miners have to handle more Long Polls. This can reduce mining efficiency of the main chain.

It should be a really small overhead though.

There's also a cost in more possibility of orphans. Before submitting a result to the parent chain a number of requests are made to the auxiliary chains to see if they've been solved. The more auxiliary chains you have, the longer the delay before the parent chain is informed of the resulting hash. If the daemons for the auxiliary chains are overloaded then that delay can be even longer. If some other miner finds a result in that delay time you can be orphaned.

An attacker could work on giving a merge mining pool more orphans by overloading the auxiliary chains with transactions. Satoshidice caused overloading on the bitcoin chain. Imagine if each child chain a pool was merge mining was 'satoshidiced'. The load and delay would be magnified for each chain the pool was mining.

Is it actually necessary to submit to aux chains first before submitting to main chain?

Shouldn't the submissions all be able to be done at once as distinct threads none having to wait for another?

-MarkM-

Even if not, I'd much rather submit to important chains first (usually the ones with the highest difficulty). So you should never be stuck on an alt-chain if the program is made well.

"Solutions" are sent to alt-chains more often however since they usually have much lower difficulty.

The process of submitting to the aux chain involves a couple of RPC calls. One to the aux chain and one to the parent chain. This is repeated for all aux chains being mined. Then an RPC is done to the parent chain again to check if it solves the parent block. If the parent chain is done first then the call made as part of the aux chain check can become invalid (my understanding based on code inspection).

Hmm so if you have such massive power that you solve a primary chain block very frequently compared to the few seconds needed for all those calls, those few seconds will be a significant fraction of the time. However if it is only once every ten minutes on average that you solve a primary block maybe a few seconds isn't really a large fraction so not a really bit hit on performance? Maybe you'd have to be a huge fraction of total hash power for those few seconds to be of much impact?

-MarkM-

This is not really an abstract theoretical question, it is a practical question.

There are plenty of chains that are not currently being merged-mined much.

Some of them would like to find out how much it is going to cost them to correct that problem so they can properly set up business plans to include that cost.

-MarkM-