Ok got you...
the 100 reserve I understand - this is the pre fund for instant TX
the 24 hours is arbitrary and the reserve should be held until no instant TX are not confirmed.
EDIT: this is the maximum total liability they can create and they cannot withdraw the reserve balance.
I still don't understand the 1/10 if it were a limit per instant TX as further risk management, its stil arbitrary but I could understand it but I don't get it as a 24hr limit on the reserve - why is this?
If am not completely mistaken, an attack should work like this:
I have 1000 merchants. I want to buy 1000 items, 1 from each merchant. I initiate the trade and pay each of them 1 NXT. My reserve fund is 100. So, if everything goes well, I have 1000 items an only paid 100.
The merchants send me the items as soon as they have the confidence that I can pay and I do not cheat. That confidence is different from merchant to merchant.
1) They send the transactions I send them to the network.
2) They wait for a moment to see what other transactions are coming through.
3) They re-evaluate my reserve fund.
Here kicks the network randomizer in:
A) Some merchants see that I was cheating, so they will cancel the trade and nodes start deleting my transactions for that very account.
B) Some merchants are faster and did not wait for so long. They already sent me the item. They need to be refunded, so they resend the transactions.
---
I see this is not quite secure as it might seems from the beginning. In case merchants of type B trying to refunding them, I could easily abort the refunding process by spamming the network with transactions. I can replay this over and over again.
Is there a way to distinguish merchants from me?
In my thinking there are two balances, - apologies if this is a bit long....
The Reserve Balance which is an amount of NXT you cannot withdraw and you can initiate instant transactions up to that level - this is a permanent reserve until cancelled.
The other balance is the Instant Balance which is updated as soon as an instant transaction is broadcast by a node i.e. 0 confirmations.
This reflects the liability the account has created with an instant transaction.
The node the transaction is broadcast through will have an realtime view of this because it will update the accounts instant balance before broadcasting the tx, all nodes seeing the TX will also update the instant balance for that account.
If the account tries to initiate more TX that would make Instant Balance > Reserve Balance this would create an error.
An attack vector such as you describe would rely on being able to send the TX through a node which had not yet updated its instant balance total for the account in question.
For instant transactions to work I would want to ensure that both accounts had to be connected to a node and both nodes had the same view of the instant transaction balance of the sending account. If the seller is logged into the buyer node then this is a possible edge case attack.
This means that the sellers account can confirm that there are sufficient reserved funds for the instant purchase because it also has a view of the buyers instant balance that it can verify with other nodes - this would be a possible client verification/check during the purchasing process, the seller NRS node is passive in this process other than providing data to the sellers software client.
Even if the buyer switches nodes, the seller doesn't and the sellers node reconciles the instant balance of the sellers account using normal time line rules.... So unless the buyer can get the seller onto a node that doesn't know the buyers balance or initiate trades with lots of sellers which it knows are connected to nodes which won't get the instant balance update then an attack will fail ( I think)
Once the instant TX is confirmed the liability reduces and the instant balance can be reduced.
I tried looking through the change logs but must have skipped that one. Is it possible to run testnet and real NXT at the same time?
(probably already noticeable 
)