C'mon ... when I got interested in this coin in February/March I sent to the donation address 5000 IXC as I thought they were going to the development, and soon after I sent you another 5000 IXC for CP. It was before I realized that there were nothing that could expected from you to deliver, and I thereby lost my interest in the coin.

Now that there seems to be actually a competent coder, I suggest that you take your cut out of that 10000 IXC for the work done since March, and send the rest (if any) to Ahmed. Please announce here how much (if any) you sent to Ahmed.

Apart from the fact that everywhere the reference is still to BTC, the client seems to be working smoothly.

Nice work, Ahmed !!!!!!!

sorry Ahmed and thank you.

i will back up people whether i like them or not.. i'm all about facts.
and if i got something wrong i will try and make it right.. not just hide.

just follow the money lol

How does so many algo's tackle blockchain bloat? I would assume the extra hashes from just mono-merge mining would add a fair bit of bloat over time but mining over 4-5 algo's should then add a fair amount of extra bloat to the blockchain. What is Myriadcoin's growth in size per year?

After you test out the merge mining functionality, can you work with CEX.IO to get the 0.9.2 functionality into their pool?

This is the current biggest obstacle in getting any new functionality into IXC.

As an additional upside, CEX.IO may just hire you for your pool development experitise.



Thanks!

Don't we need at least an 80 Byte OP_RETURN for counterparty?

Nice concept, but sounds really hard to implement...

@ahmed
Looking at your github I see you forked myriadcoin from zetacoin, what was the basis behind that decision?

Use then the block height used by the previous version. 

Well, excellent that you got it working.  The 0.9.2 code base is nicer than the previous because it uses the standard automake to drive its makefile.   There is a couple of spots in the code base that have markers when a BIP was enabled,  you may want to either permanently disable those BIP changes or set them sometime in the future.

The purpose of having the overlap is to devote a few of the algorithms to network security through merge mining and "tip" them a smaller block reward while keeping a few others with the "real" block reward numbers.

Looking at the examples in my visualization again, Myriad Child A overlaps Myriad with the Myr-Groestl and Qubit algorithms. Myriad Child B overlaps Myriad with the SHA256d, Scrypt, and Skein algorithms.

It depends which algo.. im not sure how much work it is. If its as simple as changing the getwork routines im all for it, but if it means changing the way blocks are stored on disk or memory then i disagree. The mining part is seperated pretty well now in the new base..

Remember that since the hash is so high it may not make economic sense to try to mine with another algo? How will you find a block when competing against asics? Not sure how multi algo works in this regard.

Also think about the fact that miners only get 10% of each block.. is it really a miners coin?  Maybr when value is realy high.. but the security is important and if the merge mined pools arent helping thrn we can investigate other algos to improve security.

tx messaging and myriadcoin?

THing with adding services to the blockchain would be we are moving away from the bitcoin protocol and any updates would mean harder and harder changes back to devcoin... so we really need to evaluate if we should do such a thing I can forsee in the future that only a few alt coins will be able to keep up to the bitcoin codebase and leverage true developer power while the altcoins die off due to lack to developer competence. By adding something like tx messaging you would need to re-integrate every single time and with every thin client perhaps that needs to connect, unless its scalable such that something like the android client doesnt need to know about it? I'm trying to keep it as close to btc as possible while adding reciever file stuff... but perhaps if the pro's outweigh the con's we can always do it.. just think long term. Whatever bitcoin implements it is easy to do so with devcoin.

For example someone on IRC asked me how to change the default base58 properties set in chainparams, and I didnt change ours because devcoin is totally address compatible with bitcoin they are the same, but any other coin that attempted to create a non conforming address with bitcoin (every alt besides devcoin) needs to know how to create bip32 priv/pub key pairs to enter in the base58 properties in order to properly integrate the 0.9.2 codebase... so since I never touched it I investigated and found it to be the whole openssl heartbleeed bip32 fix.. and some algorithm is externally applied to find this information... many people will not know how to calculate these things going forward and we were able to leverage bitcoin's tools and development to be able to integrate 0.9.2 rather painlessly. Also any thin client that integrates bip32 and such are also freebies for devcoin.. whereas other alt coins will lose the ability to "keep up" unless they have a bigger development community thats capable (not many).

Fuck you, after all that I did for you guys.  Burn with your worthless iXcoins, burn you lowly folks.