Bitcoin Forum

I have finally started that "bitcoin with ONLY the merged mining parches applied" repo I have so often mentioned.

https://github.com/knotwork/Mergecoin

The purpose of this repo is to provide the common code that all merged mined coins based on bitcoin all have in common, that is, bitcoin plus being able to be a secondary coin in a merge.

Most merged mined coins will be trivially easy to update to recent bitcoin code using this repo once the repo is ready and debugged.

Namecoin and Devcoin, being more than trivially different from bitcoin, will take more work to update, as they have more things they need to change. But most will be able to update as fast and easy as the creation of pump and dump coins shows us almost anyone can easily do.

Problem is, recent bitcoin is quite a bit different from the ancient version the merged-mining.patch was based on, so just getting the merged mining patches all applied is going to take some work...

-MarkM-

Great job!
Hopefully existing merge coin creators will jump in and update :)

Seems to have failed compilation on MacOS X.

This is way over my head, seems nice work though, but I have a question.
How do you mergemine geistgeld? I'm merge mining namecoin, devcoin and ixcoin on bitparking, but that's the only option I know to mergemine?

What are benefits of mergemine?

Well done!  Keep up the hard work!

inb4 people come and cry because there are no binaries

This is some of the most exciting news in a long time, keep up the good work  :D

auxpow?
cryptopp/sha.h?

looking forward to the updates.

Did you manage to apply the .rej chunks? I'd guess probably not, as one of the first clues as to whether you have applied them properly will be that it does compile...

-MarkM-

Yeah it looks like whtever variant of diff I used to create merged-mining.patch didn't include the actual content of entire files that were to be added. I thought patch included creating entire files but evidently diff does not always include the info that patch actually needs to do that.

Presumably the copies in IXCoin, DeVCoin, I0Coin etc are pretty much all the same as they all probably came ultimately from the original patch file from when merged mining was first done, on namecoin.

Oh wait, I think I already fixed the crypt thing, I think it is now crypto.h or some such, that is, no longer a directory full of candidate crypto systems someone once upon a time was considering using.

-MarkM-

You mine multiple coins at once (with the same hashes you already do).

Whats the status of this project? Is it targetted to being able to merge mine every coin at the same time that can be merged mined?
I only know bitparking.com where one can mine devcoin, ixcoin and namecoin together with bitcoins. Is there a way to mine even more coins at the same time?

Does this work because if you can find a block for btc being the highest dif, then it must work for lower dif chains?

Bitparking chooses to only merge a few coins, that is simply their choice.

for example they used to include I0Coin but do not include it now.

I merge bitcoin, namecoin, devcoin, groupcoin, i0coin, ixcoin, coiledcoin and geistgeld.

If no one is going to help figure out how to get the chunks to apply that the new database is making complicated then this could be a very very long term project. But hey the longer it takes the less new miners will be jumping into merged mining so the more coins for the rest of us eh?

-MarkM-

I think merged mining has the best capabilities for higher returns by mining with asics. Other currencies are too small and fast saturated when many mine on them. Litecoins cant be mined with asic's yet, pool hopping isnt really possible anymore and having a feeless pool that gives transaction fees too can be done with merged mining too.
So i think merged mining is the best way to maximize profits yet.

Can you tell if the longpoll problem is a serious one? Or wouldnt it matter much when merge mining as much coins as possible? So that the earning at the end is better anyway?

Unfortunately i cant tell much about the techniques. Would setting up a bounty help here?

Here's a thought.  Instead of using the latest Bitcoin version with the new database as your starting point, why not use the last Bitcoin version BEFORE the database change (I think that was 0.7.2).  If it's the new database changes that you're stuck on then worry about that upgrade later.  Using Bitcoin 0.7.2 would allow the merge mined cryptos to at least come close to current.  Some haven't had client updates since 2011! 

That seems kind of a waste of everyone's time and effort.

If a coin is going to bother to upgrade at all it might as well upgrade to the latest.

if it would just end up still old code it might as well stick with the old code it already has, though maybe I0Coin and GeistGeld might profit by rebasing themselves on some old merged coin that at least doesn't crash daily doing pointless DNS lookup and doesn't have memory leaks.

Also it might not be hard at all, I don't know as I didn't get to looking at those rejected chunks yet, had too many other things I need to do.

-MarkM-

not such a bad idea.  if we keep starting over on mergecoin every new bitcoin update then we'll never get anywhere.  a quick update to older version is better than six more months of nothing.  don't think its a waste of time at all.

Sounds a lot like greed over improvement. I would rather wait for a sustainable and well developed solution over hacking together something 90% for a quick few extra % income.

how is 90% solution not improvement?  just saying its been two years since some merge mine coins updated.  target is always moving anyway.  sometimes its best to make some progress than none.  its can still be sustainable and well developed if no major bugs introduced.  that has nothing to do with which version is targeted.  if new database is biggest hold up why not upgrade to just before new database.

The recent I0Coin update to recent Bitcoin code seems to work, so maybe now people can update their merged mined coins based on that instead of needing this "mergecoin" thing for now.

-MarkM-

Link/s to git/s? I can try them all: ixc, i0c, nmc, dvc :)

link to the git and will it allow merged mining as a secondary chain?

Yes, it seems to be working as a secondary chain.

Apparently it was made by progressively applying bitcoin updates to the old i0coin code all the way from the old bitcoin it was based on up to latest or very recent bitcoin (one that uses the new database instead of BDB for the blockchain).

So basically it is mergedcoin plus the individuation of chains stuff that makes i0coin different from just bitcoin with secondary chain merged mining patches applied.

It should be as easy to adapt all the others from as mergedcoin itself, maybe even easier since for a lot of the places where name of coin appears you can search for i0coin instead of for bitcoin, which is nicer since bitcoin appears in variable names and file names even in all the individual coins are that are not bitcoin.

So really even if we had made mergecoin, it would be easier in some ways to base off of whichever coin first made its own new self from it than from mergecoin itself, unless the first to do so was one with more than just the usual clonecoin copy and paste changes we see so much of nowadays.

(e.g. if devcoin went first, ouch, basing off that would not be so simple as just using mergecoin directly as it changes way more things than the typical clonecoin does.)

I can't remember where I got this new i0coin, git does not conveniently tell me where it pulls from when i do git pull nor even when I do git status, I don't know enough git to have it simply tell me where the repo is.

Presumably it was posted in i0coin's own thread though or maybe some "I made a new i0coin version" thread or something as i did come across it somehow.

-MarkM-

Sounds like its possible that in the near future a working solution appears?

i see, well then im going to find and clone it and attempt to build a copy for bytecoin, ill post the results here soon

git remote show origin
:)
So you have created NEW i0coin, NOT make old one working as 0.8.x ?

https://github.com/rsnel/i0coin.git

It wasn't me. But supposedly they started with the i0coin everyone was using and patched it using the bitcoin historic record at github to bring it in steps more and more up to date.

I guess doing the updates in stages made each individual pull easier to resolve/apply.

-MarkM-

Ok, I have compiled and run -rescan, it accepts my chain up to
But now I have no nodes to connect :/

Also, memory issue is NOT resolved, it eats 1GB already (vs ~200MB for bitcoind)

Shutting down...

No, the master branch does not resolve the memory issue, as the issue is not a leak but rather is something all coins will one day face, the sheer amount of outputs, bitcoin keeps them all in RAM.

There is a version with a fix for that, but it has not been made the master branch yet.

Back when I grabbed this and used it, the only fix for the memory was a dirty trick kludge i did not want to use, so that master you just tried is what i am running. i was already throwing RAM at the coin so have no problem that it still legitimately needs lots of RAM.

There is though now a proper fix, that stores the outputs in the database instead of in RAM, it is one of the branches, see the I0Coin resurrected thread.

I am not using it yet myself but the coder seems confident it will work okay.

If so maybe all coins will eventually use it as they too run up against RAM consumption problems.

EDIT oh its the block headers not the outputs that eats the RAM, merged coins have all the merkles of all the coins they are merged with in their headers.

-MarkM-

guys, is it worth to invest? it pumped a lot at btc38

this is definitely a scam.
no team +bought twitter followers etc.

Is it the same thing?
http://www.mergecoin.com/

No.


That twitter account (https://twitter.com/MergeCoin) is not related to this project.

---

https://github.com/knotwork/Mergecoin/pull/1


What is "SS++"?

https://en.wikipedia.org/wiki/Request_for_Comments 
The inception of the RFC format occurred in 1969 as part of the seminal ARPANET project.