I hate to keep bringing this up, but everytime I get the answer, oh you musta been on a forked chain, etc..

!! but someone really needs to address how added features are susceptible to attacks, leading one to get confirmations of a transaction on a fork (orphaned) block, that may not actually exist..

Meaning. One could potentially pay for an added feature, asset or an alias (as It happened to me) pay a fee, get confirmations, timestamp, and transaction ID, then find out a few hours later your transaction was on an forked chain. And that asset, feature, or alias is now "owned" by someone else, who very likely paid for it after you, but because their client was on the "right" chain.. they lucked out.
 
I believe my fee was returned, still.. These features are very interesting, but in a system with confirmations and blocks it needs to be much much tighter. Personally I think aliases or added features, assets, should go by timestamp, and not value size and only confirmations, etc. It just opens the door for questionable tactics.
What happens when it’s not just a single 1 NXT alias.. something bigger and more valuable?

So are the value of features to the forger, affected by orphaned blocks? I guess is my essential question. Cuz that seems problematic.

Think the Apocalypse might be a little bit later...

I'm on:

24186      4747512364439223888      woensdag 25 december 2013 1:28:56   
      
      0      0 + 0      0 B   
      
      1      5311201058894520581      112 %


and only 140 confirmations away from the 1440  

There are .bak files from about an hour ago, before it all happened.

Yes, looks like somebody found an integer overflow bug. Account.balance is long, but Transaction.amount and Transaction.fee are integers. My guess is that somewhere in the transaction validation code those are subtracted in a way that gives a value < Integer.MIN_VALUE, which overflows and becomes a positive. So a transaction with fee exceeding the account balance is wrongly considered valid. Or something along those lines.

Anyway, the result is that the blockchain after the corrupted block is invalid, but the current client code does not know that. Once the bug is fixed, and the blockchain rescanned, it should reject the block with the invalid transaction and start a new fork. Hopefully BCNext and CfB can provide a fix soon. In the meantime, I would advise everybody not to do any transactions - because they will all be recorded in a chain that is going to be orphaned after the fix.

mastercoin appeared in coinmarketcap on 3d place ^^

Yeah, such is the growing pains of a completely new code base.  They did say it was alpha.  I am going to bed.

Yeah, we're all alpha testers.

Then we get to be beta testers.

Then we all become early adopters

Is the blockchain rescanned on startup normally? I guess not, but may be made configurable in a fixed version.

Developers should put to client some checkpoints for blockhain. There is no checkpoints.