>Can someone explain simply why it is supposed to be so hard to track ransomware bitcoin payments, if all bitcoin transactions are in a shared public ledger?

Clearly, it's not. This is a pervasive misconception. Bitcoin is not, and is not even meant to be, private. Even with obfuscation attempts, nearly every ransomware gang has their bitcoin payments fully tracked, as this one did. There is a robust industry of blockchain analytics that pulls in many many millions each year surveilling the bitcoin blockchain. Virtually all exchanges (fiat on and off ramps) collaborate with those analytics companies and require full KYC/AML of their customers, and can thus apply their KYC label data to blockchain metadata.

Bitcoin is not account based: it is based on unspent transaction output sets. UTXOs can be combined with many other UTXOs, combined into one, or split into many. This leaves a large amount of potential for obfuscation strategies such as CoinJoin[^1]. Nearly all of these gangs attempt to use CoinJoin or similar but make small mistakes such as being representative of a large amount of the volume, leaking information through timing, combining their outputs into one, or countless other potential errors, and often a simple "FIFO" strategy can trace flows. Obfuscation is not a robust anonymity strategy, and pseudonymity is not anonymity. To quote Vitalik Buterin, "If your privacy model has a medium anonymity set, it really has a small anonymity set. If your privacy model has a small anonymity set, it has an anonymity set of 1. Only global anonymity sets (eg. as done with ZK-SNARKs) are truly robustly secure."[^2]

[^1]: https://en.bitcoin.it/wiki/CoinJoin [^2]: https://twitter.com/vitalikbuterin/status/119646811199575654...

Good explanation thanks. I'm only a bit confused now. You say "Bitcoin is not account based". But if we send bitcoin to some address doesn't that address in effect equate to an "account"?

Just like if you put money into my bank-account you will need to know the account-number (i.e. "address") of my bank-account?

If the private key was hashed, and they only had the hash, then they could not crack it. Hashing is not the same as encryption.

Hashing is for ensuring data integrity and encryption is for protection of data and information I know it but I meant hashing bitcoin private key with some hashing algorithm in order to conceal it.

> amateur crackers could recover private keys pretty efficiently

That's only if the key was derived from a weak password, which allows it to be brute-forced with standard password scanning techniques. If you're even slightly concerned with security you let a computer generate a fully random key using the proper amount of entropy—preferable on an air-gapped system or an HSM (hardware wallet). No one is going to be "recovering" private keys which were generated and handled securely without a very large budget and physical access to the storage medium.

I never heard of any criminal that's fast as light so they do not need to be faster than light in order to catch him.

A "backdoor in bitcoin's hashing algorithm" would not help them recover a private key. "bitcoin's hashing algorithm" is, for PoW, SHA256. The only relevant break for PoW would be a break in preimage resistance; this would allow the attacker to mine blocks faster, which does not allow them to calculate private keys. They could use that to mine an alternate history where the ransomware attack did not occur, but that would of course be immediately obvious.

Preimage attacks tend to be much more rare than collision attacks. MD5 for example still has no publicly known practical preimage attacks.

Proof-of-Capacity schemes would incur ecological cost as well, replacing a constantly escalating energy demand for a constantly escalating rare-earth metal demand.

>Bitcoin can be hampered but not outright killed, at least not over night. A death by a thousand cuts is the most likely solution but by no means guarantees Victory.

Ignoring policy attacks, and focusing on the purely technical:

A useful metric here is to compare the cost of executing a 51% attack on Bitcoin long enough to erode confidence in the software to the military budget of the top nation states.

Additionally, the broadly assumed consistency properties of Proof-of-Work cryptocurrencies fall apart in the face of a powerful network adversary who can cause arbitrary segmentation.

Everyone seems to forget that whilst a 51% attack could easily be financed by a nation state, actually getting the hardware to perform it is the bottleneck.

One aspect of this is that it incentivizes Denial-of-Service attacks. It would allow any attacker to directly convert a DoS attack into money. Imagine that the 5 largest ISPs in the United States decided to surveil Bitcoin usage on their network and and record a list of probable addresses for their users (BTC has no transport encryption in its P2P layer). Then, all 5 decide to collude and block the Bitcoin P2P protocol for a week. How much BTC would they earn by doing this? It's a contrived example, but DoS is a common weakness in cryptocurrency protocols in addition to being fairly easy to execute in a typical network context to individual targets. In effect, instead of authorizing transactions based on ECDSA, you're relying upon key liveness which is a much weaker thing to rely upon and would incentivize large amounts of fraud and abuse.

I think they really missed an opportunity by exclusively supporting AMD/Intel here. Would have been nice to have a competitive and relatively affordable POWER system- open hardware and firmware is nice but kind of mooted by having a mysterious minix black box running at all times in ring -3 (Intel ME/AMD PSP). I guess TALOS is still the only option there.

Wait for the Raptor Blackbird. They're apparently trying for a very competitively priced POWER9 system with that one, as in sub-$1k.

Aren't the lowest core power9 still intended for servers? I wasn't aware they had desktop processors.

There are inherent benefits to large, centralized platforms. Users, especially content creators, desire a large network of users and excellent UX, both of which have typically been properties of centralized systems or at least far easier to achieve with centralized systems. Every decentralized social network thus far has failed, and the modestly successful ones (Mastodon, for example) are in fact federated.

Many of the problems alluded to in this article, in particular the privacy risk of centralized data, are more effectively solved by policy changes and iterated technology (differential privacy as well as bread-and-butter cryptography) rather than furious hand-waving about blockchain protocols.

Agreed, the thread highlights some decent implementation issues but largely misses the design problems, both ones that were present in the whitepaper but fixed and ones that are still with us today.

Would you be willing to expand on some of the errors in the white paper? I’m admittedly not too familiar with the whitepaper (only skimmed it), but some of the other errors mentioned in this thread (for example, not including accumulated work of a chain in consensus calculations and only considering chain length) are pretty interesting.

The "freeing up disk space using Merkle trees" section doesn't make much sense. The Merkle tree structure turned out to be useful for other purposes but reducing disk usage wasn't one of them.

The original Bitcoin release (and whitepaper) made the mistake of reaching consensus by selecting the longest chain instead of the chain with the most accumulated work. The distinction is subtle but important, since the amount of PoW per block varies. This was quietly fixed early on in Bitcoin's history: https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7...

Great find.