Regarding the flaws. They assume that an adversary can build ASICs (which is quite possible) or use a lot of GPUs that used to mine bitcoins and now r not used.
Like magically being able to modify blocks while maintaining hashes and sending these modified blocks to the network.
256-bit is still unbreakable.
You just need to cause a collission of the block ID, which is 64bit.
So if you want to inject a block with a certain transaction somewhere within the last 720 blocks, here's how you do it:
You need a block that you generated, otherwise it's hard to modify.
You add your transaction to that block, the block ID (64bit will change).
To get th correct block ID, you just have to change some parameter in the block that doesn't really matter, e.g. the deadline for your transaction, that you just added.
You do that on an ASIC/GPU. You need a 64bit collission, that's not that hard.
When you have your block, you wait until someone calls you to update his blockchain.
You tell him, that you have a great cumulative difficulty. He'll want to confirm your last common block.
You tell him that your last common block is the one before the modified one. He'll believe you, he doesn't check anything.
When he asks you for the blocks, you send him your modified block. It perfectly fits on the common block, so he'll add it.
Next you send the normal chain, that will also fit perfectly because no ID changed. (You have to make sure, that by moving money around you don't keep someone from being able to generate a block that has already been generated)
You replay the current blockchain until you're at the level that the client was before.
The client will check the cumulated difficulty, which is equal to what he had before, so he'll accept it.
Now we have 2 slightly different blockchains, with different amounts of NXT in the wallets but that look the same in all operations. Because when getting a blockchain, you just check the IDs.
Did you mean that thing as a possible attack vector?
[edit]
How to avoid the whole thing:
Also check the 256bit signatures before accepting stuff.
[edit2]
As for 64bit collission generation: You've got nearly a day to calculate a collission with the rate that blocks are moving at the moment.
[edit3]
If you say the 16bit deadline isn't enough freedom to generate a fitting hash: Just add 3 transactions of 1 NXT to yourself, so you have 3*16bit more freedom.
There are tons of ways to do it, since the payloadHash is part of the block ID.
