There's a lot of FUD going around right now, primarily sparked by Francesco Firano and now with KuCoin coming out and saying they were having a 'double-spend' issue too. I'd like to point out that Kucoin fixed this issue immediately and compensated their ledger with their own funds. They did not attempt to sweep it under the rug and the issue was not wide-spread at Kucoin whatsoever, so kudos to them.

But let's get right down to the point of this post, the tl;dr:

There is no issue with the Nano protocol nor the Nano node. There is no double spending going on. The RPC API was being used improperly.
These issues are not 'double spend' in the traditional sense. Double spend assumes someone spent the same funds twice, which would be a major problem in any cryptocurrency and is basically the primary thing that has to be defeated in any cryptocurrency. That is not what is happening, nor was it ever what happened at Bitgrail nor KuCoin. People freak out when they hear 'double spend', and for good reason, but that is NOT what has been going on.

What happened in both the Bitgrail and Kucoin situations was an improper use of the RPC API.

In the RPC, there are two ways to do things:
1. Use the account/wallet system built into the node and allow the node to do everything for you, including sending money without you ever touching a raw block
2. Keep track of your private keys yourself, store nothing in the node, and only use the node for receiving transaction notifications, reviewing the Nano ledger, and broadcasting blocks you sign yourself outside of the node. (how Nanex does it)
Option 1: why it was used, why it exists, and why it's a bad idea
Option 1 is easy, and is how things are done for most traditional coin integrations on exchanges. Nano has that option, but it was never meant to be used by large services like exchanges. It was meant so someone could build their own UI or just use the command-line. It has its own use case, but not for exchanges.

The primary issue with doing it this way is that sends are not idempotent. Idempotency means that if I were to send the request more than once, it would only perform the action once or it would effectively have the same result. In this case, all you are doing is telling the node 'send X amount to this address'. It doesn't care if you already tried doing it before. It doesn't know if you're retrying something or just sending out more funds again. Since it's not idempotent, this means that any retry code in the case of intermittent failure could possibly end up sending out a transaction more than once.

There's also a variety of other issues like not being able to have fine-tuned control over what's happening, having much more difficulty in scaling across multiple nodes, etc.

This was the method that Bitgrail and Kucoin used. As a result, if anything in the system failed or resent a message for whatever reason, it would effectively 'double withdraw'. Again, I can't state this enough, it is not an issue in the NANO protocol. This is an issue in using the nano node properly.

Option 2: the proper way of doing things
If you keep track of your private keys yourself and only use the offline signing methods, this situation becomes much more unlikely. Your transactions become idempotent.

In the Nanex database, when a withdrawal request is submitted there is a unique identifier for that withdrawal. Your funds are immediately taken out of your Nanex wallet. Only then is the request sent to the actual nano node control system. It finds one of our hot accounts with an appropriate balance, locks the account for any further transactions, and creates and signs the block for the withdrawal. This block is then stored in the database with your unique withdrawal request ID.

All of this so far has not touched the node. When the block is ready, it will be sent to one of our nodes to be broadcasted. If, for whatever reason, that fails - it can be retried again because we're sending the exact same raw, signed block to the node. No matter what, a 'double spend' cannot occur because the operation is idempotent.

At this point, the account is still locked so no further withdrawals or deposits can be made to it. Our other nodes listen on the network to ensure it was broadcasted, and once it reaches consensus the account is unlocked for further transactions and the withdrawal is considered complete.

With 10 hot accounts and an Nvidia P100 GPU node, we can process 300 transactions a minute or 5 per second without the slightest possibility of double withdrawals. If we need to scale up, we just add more nodes and hot accounts.

Nanex's design is being implemented by Kucoin now and is regarded as the 'best practice' by the core development team. edit: note that this design isn't just the idempotent transactions, it also includes how we run multiple loadbalanced nodes and have self-consensus on all transactions

BIG EDIT: This can be done from the RPC entirely as well. This isn't something that has to be implemented outside of the node. The idempotent blocks can be created using the built-in wallet system or by providing the keys yourself.

Also, because I know it will come up: the block explorer issue with improper dates being shown.
This, too, was not an issue with the network. There are no timestamps in the Nano ledger and for that matter almost no cryptocurrency has timestamps, only references to past blocks. The explorer had an issue in which some transactions never had a timestamp recorded. This issue was resolved on January 19th, and any transactions that were missing a timestamp ended up getting that date.

Francesco is trying to use this too as some evidence something is wrong with Nano. That's simply not the case, and frankly a cryptocurrency exchange handling millions of dollars a day should not be relying on a third party tool to confirm their own account data.

In conclusion..
There is no issue with Nano. There never was. All the issues Bitgrail ever ran into was of their own doing because they didn't take time to think of how to implement the node properly, just how to 'get it done'. Kucoin unfortunately fell victim to the same thing, but they made things right and fixed their issue immediately. Francesco swept it under the rug and is now attempting to FUD Nano and the core development team in an attempt to save himself.

Stay strong, nanofam.

edit:

Here's another piece I did on 'why it's not an issue with XRB'. https://www.reddit.com/r/RaiBlocks/comments/7ozfrh/im_jaydubs_the_creator_of_raiexchange_ask_me/dsdfe17/

double edit:

Since I've got the platform for this and many people are asking - the core team never endorsed Bitgrail past saying it was a place you could exchange XRB. The time where Zack said 'funds are safe' (the main thing everyone references) was never in reference to Bitgrail's solvency. Those issues happened during a time when nobody thought Bitgrail was exit scamming or that they were hacked, rather it was FUD surrounding the node and the nano protocol itself and people were worried an issue in the node could have made people lose their money.

I saw the airdrop to altcoin holder, not just a member of sem?Or what the proportion of them are going to airdrop.

I read in a forum that XSH is going to have a DAG as a sidechain.
If this is true, this can be huge.
Can someone confirm?

Those who wore signature 3 weeks recieved one payment, those who wore signature 1 week recieved nothing.  Maybe this week will be ending like previous. How can we trust those ho doing like that? They offers a job "signature compaign" and after that they say that i was participating in non existent compaign. That campaign ended a couple of weeks before i participate. They was offering a job last week but they dont wonted to pay for last week.

Ok. All is clear now. I don't blame anyone.I just don't understood it in advance.

What is the next function to be implemented? Is not there anything until summer?