BTC/NMC merged mining available for testing

[JohnDoe]

Testnet Pool: http://dot-bit.org/forum/viewtopic.php?p=1576#p1576

Wiki: http://dot-bit.org/MergedMining

Forum thread: http://dot-bit.org/forum/viewtopic.php?f=5&t=217&start=10#p1242

README by vinced: https://github.com/vinced/namecoin/blob/mergedmine/doc/README_merged-mining.md

Source: https://github.com/vinced/namecoin

Benefits
- Increased network security for both block chains (more hashing power, as you no longer need to choose between mining one or the other).
- Mining becomes more profitable (mining two currencies at the same hash rate for the same kWh. If you don't care about Namecoin you can just sell the mined NMC for BTC).

[smoothie]

A list of reasons and benefits for this change would be appreciated, especially for the community that is going to be using it.

[talpan]

Sounds interesting, I'll look into it this weekend.
thx

[JohnDoe]

A list of reasons and benefits for this change would be appreciated, especially for the community that is going to be using it.

- Increased network security for both block chains (more hashing power, as you no longer need to choose between mining one or the other).
- Mining becomes more profitable (mining two currencies at the same hash rate for the same kWh. If you don't care about Namecoin you can just sell the mined NMC for BTC).

Those are the ones I can think of.

[smoothie]

So basically this will split mining with my hashrate between BTC and NMC equally? Is there any flexibility to this?

I can think of several scenarios where I would want to mine one more over the other in terms of percentage of my total hashrate. What details on the granularity of the settings for mining both exist?

[grod]

Hasn't this functionality already existed in current miners?  I can simply fire up a miner or two or three using the same OpenCL device and point them to multiple pools.  So I could fire up 2 vs btcguild, one vs deepbit, one vs slush and one vs bitparking and have roughly 4:1 split on mining power between the two block chains with built-in redundancy for pool failure.

Am I missing something here?

edit: apparently I am.  very clever.  going to check into how I can implement this.

[JohnDoe]

Hasn't this functionality already existed in current miners?  I can simply fire up a miner or two or three using the same OpenCL device and point them to multiple pools.  So I could fire up 2 vs btcguild, one vs deepbit, one vs slush and one vs bitparking and have roughly 4:1 split on mining power between the two block chains with built-in redundancy for pool failure.

Am I missing something here?

If you have a mining power of 100 mhash/s and just open 2 miners you would end up mining BTC and NMC at 50 mhash/s each. With the merged mining approach you would mine each at 100 mhash/s. Basically you are computing 1 hash and then submitting that hash to both block chains to see if it's under the target in either one.

[smoothie]

How would you submit a hash to both NMC and BTC networks when they have different difficulties?

[JohnDoe]

How would you submit a hash to both NMC and BTC networks when they have different difficulties?

If you get a hash below the target of both chains then you announce you have solved a block in each one. If your hash is only below the target of one chain then you only announce to that one and nothing happens in the other.

If you meant how the low level stuff with merkle trees work then I have no idea.

[murfshake]

Thank's a ton, having a hard time getting this to run on Windows 7 though.  Any help would be appreciated guys.  Peace!

[smoothie]

Okay wait. So then that would mean the hashing would include namecoin transactions into the bitcoin block chain and vice versa. How is this going to work when they are two separate networks?

Am I missing something?

I do get the idea of finding a hash that fits Namecoin and Bitcoin or just Namecoin.

Since namecoins difficulty value is less than bitcoin, the only case would exist where it would benefit you is you could get a hash that is less than both namecoin's threshold and bitcoin's threshold but not the other way around unless namecoin's difficulty goes above bitcoin's or they some how become equal someday.

Still a little unclear...

[zamgo]

Still a little unclear...

Me too.  But maybe something like this:

• no change to miners, they just getwork and hash like normal...
• lots of changes to pools, new patched bitcoind and namecoind, etc...
• pool sends out getworks that are 'compatible' between both chains
• if a miner sends a proof-of-work that is of at least Namecoin difficulty, the pool gets a Namecoin block
• if a miner sends a proof-of-work that is of at least Bitcoin difficulty, the pool gets a Namecoin block and a Bitcoin block

(assuming that Namecoin difficulty is below Bitcoin difficulty.    Parity here we come....)

[NetTecture]

How odes that work mathematically?

As in: The GetWork woul dbe different, so the solutions too. I dont see this working at all, purely from a mathematical point of view.

[JohnDoe]

Here is a wiki entry that does a better job at explaining things: http://dot-bit.org/MergedMining
Thanks to Nodemaster for putting it together.

How odes that work mathematically?

As in: The GetWork woul dbe different, so the solutions too. I dont see this working at all, purely from a mathematical point of view.

Sorry I don't get how it works mathematically either, but just so you know it is already working on the testnets. The information of how it works at the low level is here: https://github.com/vinced/namecoin/blob/mergedmine/doc/README_merged-mining.md

[Dargo]

This is very interesting. The first few pools to implement this should see a lot of hashing power flocking over to try it. The race is on?

[nodemaster]

• no change to miners, they just getwork and hash like normal...

Right. miners stay the same. Its completely transparent to them. they won't even recognize that they mine on two blockchains if you don't tell them.

• lots of changes to pools, new patched bitcoind and namecoind, etc...

Right. I have tested it on testnet with an uncomplete interface of my namecoin pool and start to build an alpha version of my pool in order to let interested people try it (on testnet) in order to make sure there are no unknown issues with some or specific miners. Alphaversion will be ready in the next week.

bitcoind need to be patched in order to have support for auxiliary (in our case namecoin) blockchain.

namecoind will undergo some major changes on block (proposed) 24000 in order to be able to act as auxiliary blockchain.

• pool sends out getworks that are 'compatible' between both chains

In fact there is a proxy (merged-mine-proxy) who connects to the bitcoind and namecoind. You can connect your miners to this proxy or let for example pushpoold connect to it.

• if a miner sends a proof-of-work that is of at least Namecoin difficulty, the pool gets a Namecoin block

Right. It is added to your namecoinds blockchain

• if a miner sends a proof-of-work that is of at least Bitcoin difficulty, the pool gets a Namecoin block and a Bitcoin block

No it'll get only a bitcoin block.

With a reasonable low probability it might however be possible that a solution fits both blockchains.

(assuming that Namecoin difficulty is below Bitcoin difficulty.    Parity here we come....)

Not nessecarily. Merged mining is of course optional. Each pool operator can decide if he only mines bitcoin, namecoin or do merged mining. However i guess that most users might switch to merged pool as soon as they are available. Thus in a way there will be parity if merged mining is successful.


One thing that wasn't mentioned before (or I missed it) is that this is not only a bitcoin/namecoin thingy. It is possible to have several auxiliary blockchains (however ATM there are no others I know about). Thus if there are more bitcoinlike implementations they all might have a good start (or better start) as long as pool operators start to add them to their pools.

[nodemaster]

And forgot to add, that bitcoind not nessecarily need to be the parent blockchain. There is a patch available, that lets you use it as auxiliary blockchain and for example use namecoin as parent. But is easier to patch bitcoin with the "parent"-patch, as the difficult part with the change in blockchain will be done in namecoind at (proposed) block 24000 and can be found then in stock namecoind.

[bcpokey]

Sounds cool, and I'd definitely like to give it a try, but it won't be implemented until block 24000? I guess you guys need time to get it going, but that will be quite a while looking at historic trends. On 7/21 block 16128 the difficulty drops and people will rape namecoin for a few days, then drop out when difficulty erupts again (2-4 days later?), after which it will take 1-2 months to reach block 18144, etc. At that rate it will take half a year or more to reach 24k, is that intentional?

[Clavulanic]

I'd be interested in seeing pools implement this in weeks, not months 
The first pool to do this would have me switch over pretty quick.

[nodemaster]

Sounds cool, and I'd definitely like to give it a try, but it won't be implemented until block 24000? I guess you guys need time to get it going, but that will be quite a while looking at historic trends. On 7/21 block 16128 the difficulty drops and people will rape namecoin for a few days, then drop out when difficulty erupts again (2-4 days later?), after which it will take 1-2 months to reach block 18144, etc. At that rate it will take half a year or more to reach 24k, is that intentional?

Yeah, sort of. In fact we need more or less an entire namecoind update for all users at the same time. This is no easy going. All users need to be prepared. As blocks generated with the namecoind with merged mining patch will be rejected by older clients and vice versa. This is one reason why we use bitcoind as parent. using bitcoind as aux blockchain would nearly be impossible as there are way too many clients that would need to be updated. Using bitcoind as parent gives a smooth migration path for bitcoin users. But bear with the poor namecoin users who need time.

I'd be interested in seeing pools implement this in weeks, not months  
The first pool to do this would have me switch over pretty quick.

Yeah, me too   On testnet it IS implemented for my pool, but unfortunately generated namecoins are rejected by the unpatched clients (reason see answer above). Thus it won't make any sense to start now. If everybody agrees on this it will be block 24k.