Ah that is quite fine when it comes to the price. I can't see why any new money will come in without this so us holders should ignore the charts for a bit.

Well I don't see why the price has to drop below 0.045 either. Although I agree that RC5 won't make any difference in terms of price fluctuation.      

Well I don't see why the price has to drop below 0.045 either

I think we're setting ourselves up for more disappointment by predicting price jumps after RC5. The hype is over. The only way we will grow is through adoption and actual use. That means slow growth, but consequently real growth, not just speculative bubbles as we've experienced in the past and other coins continue to experience. We need to break through the pump and dump paradigm. RC5 will hopefully allow for us to begin that process.

So!
According to http://coinmarketcap.com/currencies/views/all/
2    Litecoin  LTC    $ 165,926,555 $ 5.26
8    Darkcoin DRK    $ 11,336,589  $ 2.46

All DRK need is multiple the current price by 14,63637386871836 times
So 1 DRK = $36,005+ $0,001 to become #2
So 1 DRK = BTC0,0708969183814118

I don`t know how much time we need to obtain this BUT with open source, RC5 and comming mass info spreading marketing etc we can do it, all depend how strong hands we have and @ what price ppl start mass dumping again.
Saying this when MasterNet (darktor) will go live I don`t think we will be under BTC0,1
Time, development, testing, marketing, time, development, testing, marketing etc thats how the things should work.
btw. there will be much manipulation during all the way to darkbank, so don`t be eaten by the whale.

I don't understand why you people saying we will start marketing after RC5. Any reason we can't start it now?

They don't?

The fact that we're closed source is a huge (temporary) weakness. No one will seriously consider using Darkcoin until we go open source. That's why we're putting off marketing until then.

Ok, good points.... keeping up a synchronized, agreed-upon list of MNs throughout the network is the real crux here.  Especially since it definitely needs to account for MNs dropping out of the network from time to time.  Which shouldn't really happen, but it will happen for various reasons.  So yeah, that idea definitely has some flaws that would be hard to work through.

How about this.  Each block, a group of MNs is "nominated" by the block hash.  The hash simply matches a few bits of the MN's public address... target this so that each block hash should "nominate" 5-10 MNs on average.  Then all of the nominated MNs will be required to create "ping" transactions and push them to the network within 2 blocks.  These transactions will be included in these next 2 blocks.  Take the hash of the 2nd block after the original "nomination" block, and use it to determine the winner (among the nominees who have correctly "pinged" back) of the MN prize that will be generated by the coinbase transaction in the next, 3rd block.  If for some reason a block hash doesn't match any MNs (or no MNs happen to "ping" in time -- which is equivalent in result), then there would be a fallback option such as awarding the prize to a different MN that wasn't chosen in the previous block, but was nominated and "pinged" back correctly.

This gets rid of the problem of having to keep a current, up-to-date list of all MNs throughout the network.  The MNs themselves are responsible for letting the network know that they are out there by the "ping" transactions, and they can be called upon at any time due to the random nature of the nomination process, so therefore they must be ready to quickly respond at any time.  If they miss a "ping" then they will be penalized by not being eligible for the reward the next time they are nominated.  All MN-payment-eligible addresses will have their public addresses in the blockchain immediately prior (1 or 2 blocks) to the block which pays them out, and the reward will be awarded to one of the nominees in a deterministic fashion, which eliminates confusion and rejection of blocks due to nodes not being aware of a particular MN on the network.

There might be some problems that crop up with this process due to orphan blocks.  Perhaps the ping-response-time should be set to 5 or even 10 blocks instead of 2.  But I have been chewing on this kind of idea for a while now, and I think it could work for the MNs.

I'm thinking about opening the source at release of RC5. I've actually been having various close friends of mine look at the source and no one sees anything seriously wrong with it besides some organizational issues (which I'm working on now). I believe we're ready to go.