It's worth mentioning that tracking addresses is a lot harder than one might suspect.

Let's go with these assumptions:
* Deposit addresses are UNIQUE (generated by server)
* Withdrawal addresses are NOT UNIQUE (generated by untrusted parties)

What's the rational for not forcing non-uniqueness on the withdrawal addresses?
* If all withdrawal addresses are forced to be unique, I could submit any withdrawal address and if it bounces, I know it's in the database. => Leaks database information.

Okay so we don't force uniqueness. What are the pitfalls?
* Tracking addresses becomes complex, our database now has to allow for multiple records of the same withdraw address. We build a primary key { user, withdraw_address } for each record.
=> deduct the balance before the withdrawal goes into the queue, and make sure that it targets the right user.

What if an attacker attempts to use a deposit address as a withdrawal address?
* This is a more interesting scenario, especially if you combine both deposit and withdrawal addresses in the same table.

Let's take this simple table as our initial state.

Alice

DEPOSIT

A

Mallory uses the deposit address of Alice as a withdrawal address.

Alice	DEPOSIT	A
Mallory	WITHDRAW	A

Alice does a new deposit and the payment handler has a flaw, it assumes the deposit addresses are unique (not true in a combined table!).
That could result in Mallory being selected as the receiver of the deposited funds by Alice. Simply by failing to verify that the type of the address was indeed a deposit address rather than a withdrawal address.
The correct way of getting the right user for the deposit address would be:

In a combined table (storing both deposit and withdrawal addresses), the primary key is { user, type, address }.
Long story short, do not store deposit addresses and withdrawal addresses in the same table in your database.
The uniqueness deposit vs withdraw addresses does not hold, and they deserve their own tables. A single missing type check in a query can spell disaster.

Hi,

I'm theorizing what the ideal patterns are for developing applications that deal with centralized payment processing.
I've come up with the following list, please let me know if there is more to add or if you think something is wrong.
There have been many hacks, which is often the fault of monolith systems without proper isolation and authentication.

I haven't looked into topics such as cold storage, anomaly detection, rate limiting and would love to hear ideas.

1. Use microservice pattern
Following the microservice pattern is a must. Payment processors must force interaction through an API. The sensitive payment processing code must have its own database with limited privileges (eg. INSERT, UPDATE, SELECT).
Ask yourself whether deletes are necessary, I recommend not giving it that ability such that there is an audit trail after an incident.

• Forces you to think about authentication.
• Isolation of the sensitive code and credentials from the main application.
• Reduces the attack surface.

2. Split the cryptocurrencies into their own microservices and containers
A malicious insertion into the source of one cryptocurrency, should not affect any other cryptocurrency.

• Containers/virtualization is your friend, isolate as much as possible.
• Docker is your friend but be distrustful of container images created by other people. Use private repositories.
• Bind containers that execute sensitive cryptographic operations to a single dedicated core, use CPU affinity.
• Each cryptocurrency should have its own database, but the API for interaction should be identical.

3. Process payments from a queue, not on-demand

• Users shouldn't be able to trigger an asynchronous withdrawal, the corresponding cryptocurrency microservice should maintain a queue which is processed every X amount of time.
• Use mutex locking to prevent ANY possibility of concurrent processing of payments, if a processing request accidentally wants to process the queue, it must happen in sync.
• Spamming transaction attacks may trigger payment processing requests that overlap and can therefore cause undefined behavior if no mutex locking is provided.
• As a general rule: deposits should be processed before withdrawals (to prevent a withdrawal from using coins of an unconfirmed deposit.
• Always use UTXOs  (txid + vout) and their amount to track payments (rpc command listunspent). Txid's on their own mean nothing.
• Always check whether a UTXO is already present in the database.
• Register deposit transactions eagerly and mark them as "unconfirmed", then periodically monitor the transactions for confirmations, and only when confirmed, update the balance of the user. (rpc fields 'safe' and 'solvable')
• The balance of a user requesting a withdrawal should subtract the balance eagerly and verify that the remaining balance is a positive amount, only then push the withdrawal on the queue of "to be processed".
• Evict the withdrawal from the queue before actually executing the transaction. A failed withdrawal should not stay in the queue as it may repeat itself and drain all the funds.
• Think about corner cases where a withdrawal is made to an address within the system and would also have to account for a deposit!
• Rollback at any error on a transaction. Make sure that the eviction from the "to process" queue (both deposit and withdrawal) is not rollbacked though.

4. Authentication for microservice X should not be valid for microservice Y
Make clever use of authentication. I recommend using OpenID Connect JWT tokens that a cryptographically signed by the authentication microservice.
JWTs should:

• Be fully verified before even inspecting them.
• Only be valid for this particular service, tokens generated for other microservices should not provide access.
• Only be valid for a single request and provide replay protection.

An example of very simple replay protection would be to have an API function that generates a random 'challenge' on a cryptocurrency microservice, stores it locally and also returns it to the user.
Then the user turns to the authentication microservice and ask its to include the hash(challenge + API function + API request) in the creation of the JWT token specific for the cryptocurrency microservice.


5. Optimize for security not for performance

• Realistically, how many transactions does your company expect to process?
• If you're using SQL, make sure to always used prepared statements and transactions where necessary.
• If you're using SQL, make sure to test every endpoint for SQL injections. Doing this retroactively is often PITA to do manually. There are automated tools that can also crawl the website for you.

0. Obvious notes

• HTTPS everywhere...

Nice scam you got operating here! 

What version are you on?
Join slack if you want faster help.
Keep your debug files!

Contact polo support - verify that transaction went OK.
Contact Bittrex support and ask why balance is not credited.

We can't help, exchanges have to do that..

I suggest that for the moment you run the wallet with the following parameter added to your shadowcoin.conf (only for servers and daemons)


We're working the stability of our secure messaging code 
Send me a private message when they are up!

Hi BitcoinFX,

We sure appreciate Tor nodes bridging the clearnet to the hidden net!
We have a few of our own actually, we should probably update the docs to include them, thanks for the notice.


You're always free to host your own, if you need funds to do so then the only option is to openly request it here with a BTC/SDC donation address attached to it.
I can't however guarantee any monetary reward for running the nodes, I'm sorry 

Hi,

All our software is licensed under the MIT license for that exact reason, you can do with it what ever you want.
We were just a bit annoyed by the mud throwers, then looking through the source code and finding our code was a bit of a stab to the heart. I didn't really go through the rest anymore - crypto coinbases are huge.
The response of you team has been very kind, we wish you the best on your endeavor.
Make sure to send us a message when the white paper is released, we'll take a look at it and give critique and compliments, I hope to give more of the latter 

Hi NavCoin devs,

I'm a member of The Shadow Project, we're a group of developers and activists that fight for online privacy.
We're also the people behind the ShadowCash project, one which we develop with a lot of spirit and love.

We took notice that you're using quite a bit of our codebase - we think that's great by the way, as developers it strokes our ego a bit  
On the other hand we do believe credits are to be given where they are due.

We were wondering if you could give us a fair mention in the main thread for the tremendous effort we've put into programming it.
Major parts of your platform are 100% based of what we made stealth addresses and our secure messaging, all by all good for roughly 4,600 lines of code.
Our community is heavily guarded by morals, none of them are pleased with relentless "copy-pasting" our efforts and at best will not touch your coin, at worst they'll argue to death and the odds are not in your favor with this one.

Recently some members of your community have been throwing mud at ShadowCash for not 'having enough developers, navcoin has 7'.
I don't have to explain why that pissed some people off, I hope we can come to consensus.

PS: Good job on running those Tor relay nodes, glad to see supporters of Tor  

What kind of rhetoric is that?

We were not fundamentally flawed as we fixed the flaw. Hence it was not very fundamental to the theoretical design of our crypto rather being a bug in the actual product.

It was discovered and shared because we have a good bounty bug program that ensures finders a good reward,
it was also patched rather fast as the bug was really small; the kind you can overlook easily.

No need to mess with PGP keys or e-mail addresses.
Anything you sent is automatically encrypted.

We've also been doing a very effective outreach.
The newcomers per week has dramatically gone up  

Soon every node will automatically be a Tor node 

That's actually a freaking clever idea.

The list of tor nodes is known so whenever a user would make a successful connection to a website it can start broadcast a acknowledgement of service which would be secured by a CPU PoW algo and the node is rewarded.


Another good starting point for the consensus algo would be the "DDoS coin" example.
 https://news.bitcoin.com/proof-ddos-malicious-consensus/

Use magnet links, not torrent files.
> Smaller

Hehe, who made that typo?  Greed lol.

I'll help you refresh your memory.
https://blog.shadowproject.io/2016/02/12/deanonymize-shadow/

We didn't claim our "test results came back fine", we claimed that after 10 hours of messing with OpenSSL libs that we hadn't been able to confirm that the vulnerability was a fact.
This was because our cryptographer wasn't online at the time.

I'm not a cryptographer in the sense that I can create my own cryptographic schemes, but I am capable of comprehending the inner workings of elliptic curve cryptography and most cryptographic schemes that involve diffie-hellman key exchanges at their core. As I programmer I am capable of working with cryptographic libraries and implementing well-documented schemes.

I'll also point that the bug in our system also corresponds to the poorly documented schematics in the inititial CryptoNote whitepaper surrounding the way keyImages are created.
The documentation was so bad that Shen even had to do a second writeup about how they indeterministically map hashes to the curve, https://github.com/ShenNoether/ge_fromfe_writeup/blob/master/ge_fromfe.pdf
The bug was something very small that could've been easily overlooked by anyone doing an implementation based on that paper, but the effects were rather big on the other hand.

Also just FYI, most of the transactions happening on Shadow are still public transactions due to exchanges. On top of that there was only a small portion of ring signature compared to the vast amount of tokens. Of the tokens in existance something < 25% was affected because most HODLers don't move their coins around.

We also never denied Shen his right to the bounty, we did question the applicability but in the end we decided to pay it out. I took 4 days to confirm he was eligible for the bounty and compared to other bounty programs that's rather fast.

--

On the other hand I am confident that our ring signature scheme is secure now, the crucial part in all ring signatures is the keyImage and those have had a thorough review.
The forming of the actual "ring" is not as error-prone as the keyImage and is harder to "fuck up".

I was the first developer to take a look at this vulnerability, and we immediately recognized the flaw  described in the mathematics.
What you're saying is simply untrue, https://github.com/shadowproject/shadow/issues/25#issuecomment-182977494

A flaw in theory doesn't immediately mean that it's applicable to the software in question.
I did not code our ring signature implementation so it took some time to find all the details about the OpenSSL libraries we use.

Hi,

Make sure to have a backup of all your transactions you've made to and from ALL the exchanges you've traded with.

If you still got every log of transaction and trades, then that proof should suffice to build up a whole history.


---

On the other hand, for the sake of preventing abuse by third parties, falsely screwing you over you should use altcoins like ShadowCash, Monero or Dash to cryptographically break the links and traceability of your transactions.

I'm an avid SDC supporter, but in case big transactions I suggest using Monero or Dash because their volume is a lot bigger.