If I were them and there's really a working test client, I would publish the test client first at least to some beta testers. I believe I will collect much more fund with their testimonials. At least, I will post some screenshots to show how the client/node works to attract more investment. Then think about why I don't do things like this. Most likely because I can't.

Moreover, apparently this proposal exactly targets some complaints of Nxt. Nxt suffers from DDos because of the less of incentive of mining. The two methods in this proposal were actually proposed by other people in the Nxt thread. Actually, it was me who suggested sending nxt out from the unclaimed account every minute to increase the incentive of miners (they get the tx fee). Now think about which one has the higher possibility. 1) The got the idea 2-3 months ago before Nxt was announced. 2) The got the idea just couple of days ago by reading the Nxt thread.

I am not sure how PoS in PPC works, but in nxt, they claim that the mining is deterministic and who should forge a block is determined as long as that node is forging.

I am quite curious about how timestamp control can avoid a client to make multiple hash in a second. It may avoid a client to SUBMIT more than a hash a second, but hashing is done locally and no other node will know how many times I have tried.

Speculation is about the price of the stock, and we are talking about the value of this stock. That's completely different.

For example, by speculation, now may be a good chance to buy AM shares cause someone may keep pumping the price until the tape-out result is out and you could earn considerable BTC by join the pump and dump. When we consider the value of the AM share, however, the current price is already above its value in my opinion and we should not consider it a good investment any more.

I agree with you way to calculate the value of the stock, but I don't think AM has any chance to generate dividends of 0.6 BTC in the future. Another 0.6 BTC means AM has to generate more than 240K BTC in the future. Considering there're only 9M bitcois left, it means AM has to get more than 2.6% of the rest BTC. As a mining dominated company, that almost means AM has to keep 2.6% of the network hashing rate all the time (costs have been completely ignored here), not matter how fast the whole network hashing rate increases.

You may say, there're other revenue besides the mining/selling chips/franchising, such as immerse cooling. Those revenues, however, are in fiats and considering the appreciation of BTC in the future, revenue in fiats can be safely ignored in my opinion.

Finally, even AM achieves the objective, what's the point to spend 0.6 BTC and wait for the 0.6 BTC be returned in dividend in the following years?

If they cannot prove they have found the way to know the uptime of each node in an decentralized way, their claim that it works in the testnet already is most likely a lie.

It works only when making more than 1 hash per second does not bring more benefit, such as PoS coins, but no necessarily works in PoT, where making more hashes seems will bring more chances of win the block.

May I ask a question about the developer's incentive.

Proof by burn does increase the trust level, but how about the incentive? Have the developers already burned enough BTC to get their shares, or have the developers reserved certain part of XCP for themselves? If not, how can we be sure the developers will concentrate on this project and try their best to improve the value of XCP?

How to fix everyone's hashing rate to one hash per second? Relying on no one changes your source code, or is there any method to ensure this in the decentralized network?

I haven't seen this great question be answered yet. As a decentralized application, there's no central server to do the statistics. How the network check the online status of each nodes and how the nodes prove their uptime?

You may setup a central node to distribute the rewards, but how could this node know the exact uptime of each other client? Remember not all nodes connected to this central node, otherwise it becomes not decentralized at all. This is the most innovative part of this proposal and needs more verification since it's not applied in all existing coins.

I think some people just try to pump and dump, taking advantage of the out-coming tape-out. Even the tape-out is successful (most likely someone has already got some insider news about the progress), the current price is still way over-priced in my opinion.

A main concern in p2p software is that you cannot rely on the assumption that no one will change your code. You may easily add a sleep in the code to control the generating speed, but you cannot avoid others to remove this 'sleep' from his code. Remember being a decentralized application, there's no central point to control anything in the global level. That's why PoW is introduced because they can avoid such kind of cheating. Everyone has to finish some kind of computing before they can generate a block and the interval of generating blocks can be adjusted by changing the difficulty.   

Before we come out some innovative ideas, we'd better understand the rationale of current system first. 

Wait until the CipherTrade is live and hope Kate and Deprived are back that time.

As long as Kate can be contacted, we can negotiate on how to deal with the CipherMine.B1 part (more than half) of DMS. The rest 150 BTC in the public address https://blockchain.info/address/1CzJY7pVkCqDjUtycHzFgeTTbbWokqYuXo is only accessible by Deprived and nobody else can handle it, so we really needs to find Deprived for that part of DMS.

I think you'd better understand why PoW or PoS is required in the first place. One of the main reasons is to avoid people to spawn a lot of instances to attack without any cost. Your idea is exactly something they love. They can even create thousands instances in one computer.

Just click https://btcchina.com and you will know.

It does not matter who mined the 12 blocks. If you want to double spend a coin in 12 blocks before (say current block height is 10012, and you want to double spend a coin at 10001), you have to reverse back 12 blocks and begin mining a new block (10001). In the same time, other miners are mining 10013. Your hash rate needs to be faster than all other miners so you can catch up with the main chain before next difficulty adjustment. Don't expect you will finish all blocks 10001 - 10013 before other miners find their block 10013. You have to catch up with them slowly, maybe at block 10033 or even 10133. Before that, all the blocks you mined are treated as orphan blocks.

If you are still mining the shorter chain after next difficulty adjustment, you will never catch up because the other miners mining speed will be doubled due to difficulty decrease.

Moreover, it is very easy for the public to find you are trying to do this malicious thing.
1) The confirmation time of following blocks are doubled, because your hash rate has left to mine a 10001.
2) You've mined many orphaned blocks in a row (10001, 10002, ...) until your chain catches up with the main chain and replace it.
3) All the clients will suffer from a deep reorganization after your chain finally catches up and replace the old block chain.

In short, even if you have 51% hash rate, you will not double spend some coins 12 or even 6 blocks away. Otherwise, it takes a lot of time for you to catch up with the main chain, and people will notice this very easily.

A proper way for a merchant to receive BTC payment is to generate an address for each customer. It's a standard way and helps a lot for tracking who pays how much automatically. You could generate a BTC address when people login in and store that in the DB.

Please use one public address approach only as donation address.

I am quite curious about how you were pushed away since you are the co-founder, and co-founder cannot be just fired. Does it relate to the investors from China?

Nothing can reverse hashes cause hashing is not a lossless compression. For example, you could hash a 1G movie into 256 bit hash value. A lot of information has lost during hashing, so no one can reverse it.

Most likely that's the change address. When sending out some btc, The Qt client will create a new address and  send change to this address. You will see the change after you finish syncing all the blocks.

I really don't understand it. Even someone can prove he has 1 btc does not mean he will send you 1 btc. Please use escrow or at least trade with small steps.