avhwl

I had some fun formalizing + building an interactive science communication app around Hanson et al's Grabby Aliens model for the Fermi Paradox. I hope people enjoy.

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...

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.

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.

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.

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.

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...

This is an entertaining and important talk. Technology is not value-neutral, and insistence that it is is a larger meta-security issue in of itself.

Cool write-up. This is one of the things that interested me about the new T2 computers; having a secure boot process that loads every link in the boot chain using cryptographic signatures verified by an onboard TPM engineered by some of the smartest people in hardware security. This isn't a move by Apple to lock users into their platform, they do that far more effectively through other means.

Both Augur [0] and MakerDAO [1] have centralized points of failure that would allow the owners of the contracts that define the tokens to halt transfers, withdraw funds, or in the case of MakerDAO, mint tokens out of thin air.

[0] https://etherscan.io/address/0x9f8f72aa9304c8b593d555f12ef65... (Line 453) [1] https://github.com/AugurProject/augur-core/search?q=onlyInBa...