But since this is "blockchain", is it more like... they weren't polling for the right confirmation/status/update from the blockchain network API thingie?
That's the exact same mistake I referenced. The consuming website should not be in charge of the atomicity of transactions.
It doesn't matter whether the API was used incorrectly, blockchain was used, or finanglesperunk was the technology. The vagaries of the implementation don't matter. Sending money should be atomic with the request instead of whatever this was. The $3.36 Billion in theft should tell you that.
PS Blockchain is a database. You can choose to enforce SALT instead of ACID, but $3.36 Billion should tell you that people aren't doing something right.
ACID makes sense in internal transfer, like the example you gave:
> debiting one account and crediting another, is a single transaction.
Blockchain is ACID compliant, their internal database could be ACID compliant hard part is linking it together.
That's the issue, ACID is not ACID for a tiny bit but for the transaction. See the definition you quoted, "debiting one account and crediting another, is a single transaction." Blockchain is absolutely not ACID compliant. There must be a deterministic methodology not miner consensus for ACID. Miners can even change the blockchain.
However, why are you even mentioning blockchain instead of MYSQL without SERIALIZABLE, which enforces atomicity?
> The solution here is exactly going opposite of ACID.
What solution are you talking about? There was no solution put in place, which was the cause of the thefts.
> So Silk Road wasn’t waiting for any transaction confirmations??? And didn’t append a nonce to each withdrawal to avoid duplicates?
See the ACID properties of databases. [1] These are often put to the wayside in order to have greater transaction speed. We can see the results.
[1] https://en.wikipedia.org/wiki/ACID