I will not remove those if other clients are relying on them. But those are not API calls, those are user interface calls. In 0.8.0 you would be able to selectively enable/disable the http API and the UI, so don't bundle them together. And they will be on different ports.

The Java API is still a work in progress, in fact I am just in the middle of another refactoring for 0.8.0. I am switching to embedded jetty, so Nxt will no longer be a servlet. I will also improve the API while at it.

For the SendMoney example, what kind of an API would you find useful? Right now the steps you would need to duplicate are not that many, basically you need to do:

The rest is validating the user input and returning error messages, which is application specific. If you submit an invalid transaction, it will not be accepted, and a lot of validation is done immediately when the Transaction object is constructed (such as for non-negative amount and fee, deadline, timestamp). Other validations, such as the account having enough funds are only done when the Transaction is about to be included in a block (because the account balance may have changed in the meantime).

The node doesn't need to be forging. If you send a transaction to any node, it will broadcast it to others, and eventually a forging node will include it in a block.

I don't understand why it keeps happening to your node, but again those two block ids are from the correct blockchain - at least on the nodes I run.

Block 2507106602597677499 is the correct block to be at that height:
http://87.230.14.1/nxt/nxt.cgi?action=1000&blk=2507106602597677499

If your node refuses to accept it, this means you are on a fork. Your base target is probably very high too, another indication of being on the wrong fork.

If it doesn't recover by itself, you will need to delete the nxt_db folder and redownload the blockchain.

Neither of those was to be considered a part of the API. They are only used by the current NRS javascript client. If you are looking at 0.7 decompiled sources or javadoc, anything under the nxt.user package is not a part of the API and may just disappear one day. The official http/json API is provided only by the classes in nxt.http.

Except nobody has had the time to write some javadoc documentation about each of those, so refer to the wiki for details.

Yeah, the logic is the same. If the account is unknown I don't start forging with it - otherwise an attacker can flood a node with bogus startForging requests for billions of secretPhrases with no real accounts associated with them.

What does "getAccount" return?

This is normal to happen. While generateBlock was running, the last block has changed - either a new one arrived, or it was popped off. So your newly generated block is no longer valid, please try again.

Those two blocks were correct at that height, so your node should not have tried to pop them off. Maybe you were on a fork? Or connected to nodes on a fork that were feeding you bad blocks. I don't see any pop-off attempts for those blocks in my logs.

+1000

I also strongly recommend that people stay away from RealSolid's mcxnow exchange. Having Nxt on it will only give us bad reputation by association.

Each node decides for itself. Eventually they have to agree. The block with higher cumulative difficulty is considered better.

Of course I store the whole blockchain, this is what the db contains.

You seem to be talking about blockchain trimming or pruning. This is in the plans, but not that soon.

Downloading the whole db will take longer than just the blockchain.

With a little help from a stronger block that kicks him out

Only one block can be at the end of the chain, but multiple nodes try to generate blocks at the same time. The better one wins, if the other was attached first it gets popped off.

No. I guess the database needs vacuuming once in a while. I will do that at shutdown, it means stopping the server will take slightly longer.

Because to find out the previous value of the alias URL, if any, you need to go back through all previous transactions. In effect, again scanning the blockchain.

I don't understand what you mean by checkpoint file. The rest is a bad idea.

What? Mine is 111M only.

It is not because of something you did. The block that had to be popped off contained an alias assignment transaction. When a block is popped off, an attempt is made to undo all transactions in it. But this type of transaction cannot be undone, and in this case a full rescan of the blockchain is needed.

This is all normal, works as intended. It is telling you exactly what is happening - popping off a block, doing a rescan because alias assignment cannot be simply undone in a pop-off. The block generation attempt failed because in the meantime another block arrived and was accepted.