All that matters is a good strong solid anon coin. For me the price isnt important to watch until that is established. In the end people will go where the quality is.
+1.
Personally, it think it will be drk. I think it will be worth the wait and trouble. As I see it, there are two situations that could be going on.
1. Evan is screwing us over.
2. Evan is keeping it closed source and not talking much, because he is producing a product (Hate that word, but can't think of anything better) that is much, much better then the competition.
I'm (Personally) sure that it's #2.
#1 - no way
#2 - yes, he's reviewing all ideas to see if there is a better way to do this that won't cause forking.
I made a suggestion, but InternetApe said it was centralization, however, I think he is wrong. But I'll put it out here and see what you all think?
I realized that the reason we don't pay masternodes each a shar of the 20% block reward is because there are so many masternodes, and to do hundreds or thousands of transactions for each block would obviously bulk up the block chain, not something anyone would want.
But what if
an account - no, call it a secondary blockchain that is volatile, it is dumped once it completes it's task. This thing keeps track of each available masternode, for each block, awarding them a share if they were available, and then also collects the 20% mining rewards. Then once a day, this account pays all the masternodes at once, with one transaction, a percentage of the purse depending on how many shares each masternode submits, kind of like a pool.
Once the payment is made, the account is cleared, all the tallying for the day is deleted and the system starts afresh. Every wallet would process this information, keeping a copy of it, like the blockchain, except that it is volatile information, and it goes away once the payout is made.
Do you all think this is centralized? I think it's no more centralized than any single transaction, unless I'm missing something?
No, I think you misunderstand how the masternodes will be paid under the current implementation, once masternode payments are turned back on. (Somebody please correct me if I'm wrong.)
There are hundreds of masternodes. Each of them is available to perform coin-mixing services. The people who want to send coins pick a masternode, somewhat at random, but once one is picked then others join in and send their coins to that same one. The masternode performs the mixing, the mixed transactions get included in the block, and that masternode receives payment within that block for services actually rendered within that block.
So out of the hundreds of masternodes, there might be just a handful that actually perform the mixing and receive payment for any given block.
This makes perfect sense and is actually a good way of making payments. It would be extremely difficult to keep track of which masternodes are connected all the time, and keep up with the accounting for all of it. It is far more efficient to only pay a few masternodes on each block, which have been chosen randomly by the clients sending coins. So masternodes will not be getting a perfectly steady income due to the random chosing, but it will average out over time.