Two consecutive transactions over the same public address leads to a pattern relaying on the elliptic curve cryptography method.
So working along with reverse engineering, hacker can find the private keys, where he can extract them and steal coins whenever they want to.
Imagine if those private keys belong to a cold wallet of huge bitcoin exchange... It can be a disaster for digital currencies...
This has been always the problem in the history of cryptography, and it is actually the reason why cryptography has born.
Let only the target person know what your information is, but don't let anybody else know about it.
So you have to encrypt it at the source, but also have to allow it to be fully recoverable at the destination, without getting caught in the air with some patterns.
To be honest, it is not an easy job, requires a lot of focus and luck. If someone can do it, I am sure they deserve it, but need a patch ASAP, maybe adding another layer of security of some hashing algorithm for the public address and its transaction IDs could be a solution, to remove the patterns...
In the meantime there are precautions everyone can take to mitigate the risk of falling victim to this exploit.
A) The most drastic and cumbersome preventive security measure would be to never use the same address twice.
or
B) Another, more easily manageable option would be to use a wallet whose dedicated purpose is to transact with the outside world, and to never leave important amounts in it. An example would be a wallet with addresses for exchanges, mining pools, donations, stores, etc., and whenever the balance of any of those addresses goes over a certain pre-established amount, you, as the owner and user, would send the balance to another wallet that you only use for storage and that only transacts with your "intermediary transaction wallet" and never with anyone else. I think this would be an effective workaround solution.
REMEMBER: most of us use specific addresses of our own creation with each entity we deal with, which means that those addresses easily fall into "two consecutive transaction" sequences. For example, most people have a specific address they use with Cryptsy, and another for Bittrex (again, these are named for sake of giving an example). Those specific addresses are used only for transactions with each specific entity and no-one else. Obviously this means that the entity we are transacting with has made not just two, but a plethora of sequential transactions with our specific address.
The good news is that an attacker cannot steal everything in our intermediary transaction wallet, only what's assigned to the particular address in the blockchain. Relaying funds to a safer, better protected address using a "proxy" wallet in a firewall kind of fashion as outlined in option B above should keep any attacker at bay.
Please correct me if I'm overlooking anything (which is quite possible). There are things we can do to improve security using the technology currently available to us and it's not necessary or recommendable to ignore the issue while waiting for a fix. Beyond what I've mentioned here, other advice is to never use an online wallet provider or online creator of paper wallets, NEVER! What other suggestions and recommendations has everyone else heard of or have?so you are saying that we should have 2 desktop wallets:
Wallet A [Usage Purposes] and Wallet B [Storage Purposes]
Wallet A will always have transactions with exchanges, mobile wallets, merchants, etc
Wallet B will *
only* have transactions with Wallet A
And it would be better if both wallets are on a different hardware?
like Wallet A on a desktop and Wallet B on a laptop?
just a question regarding the wallet that will be used for storage purposes - how often does one need to download the blockchain or at least to update the wallet? sometimes when i follow a certain coin and when they have a newer version, they want people to use the latest version asap. is that really necessary?
what are the Digibyte team doing on their travels? I assume it's business, and secret for now. 
