Quote from: Quartx on May 11, 2013, 04:15:24 PM

Quote from: markm on May 11, 2013, 03:54:31 PM

They do overall seem to show renewed interest in having low time between blocks, so if nothing else they might be indication it would be useful to rebase GeistGeld (15 second blocks) on new bitcoin code to bring GeistGeld up to date codewise.

Since GeistGeld can be merged mined alongside bitcoin it already provides, and has all along been providing, about as fast a block speed as can realistically be used, without needing to divert any hashing power away from bitcoin.

-MarkM-

I second that

Well like all the merged mined coins, the first step is a copy of bitcoin that has had the merged mining patches applied.

I made a copy of bitcoin quite a while ago now, renamed the directory "newcoin" and, it seems applied the merged mining patches. That was as far as I got but that is all that is wanted as a common ancestor for all the merged mined coins to rebase themselves upon.

It is no longer a very recent bitcoin but it is much more recent than most of the merged mined coins are currently using. Getting the merged mining patches to apply to the latest bitcoin code would probably be harder because over time more and more subsystems seem to be getting moved into separate source code file. Which is good but confounds the patch-applying process making more manual intervention and possibly even modification be needed to get the patches applied.

I do not know enough about git though to push this "newcoin" to a new repo. Right now it pulls from the main bitcoin repo if I use git pull. If there is a way to tell it to push to a new repo called newcoin under my "knotwork" github account that would be nice as then we'd have a repo of just bitcoin (albeit not the latest bitcoin) with only the merged mining patches applied. Waiting for such a repo is so far the primary delay in getting all the merged mined coins moved to newer code than they are currently using.

-MarkM-