Slower != secure.

But secure implies slower. Therefore, fast as possible implies not secure.

The more consequential the thing, the more likely that it will still be consequential after some time passes at a human scale, and the more important it is to take the time and be sure it’s done right.

It takes time to catch mistakes-whether mistakes on the operator’s part or mistakes on the system designer’s part-that unforeseen circumstances or malicious actors might be turning to unexpected effect.

In the author’s example of a cryptocurrency heist: had this happened in a US bank, where somebody tried to initiate a $90,000 transfer from the victim’s account to a strange one, there’s a much better chance that, in the days it takes to settle, a bank employee would ask questions or the friend would notice a large pending transaction and question it in time to cancel it.

I mean for that matter, we have examples of fast-settling systems (like credit card fraud detection) where that prudent degree of friction comes from having an automatic system auto-deny the transfer in the minority of cases it finds suspicious, requiring the friend to meet a higher bar of scrutiny for that specific high-consequence action.

In the case of most all $90,000 transfers to strangers in a person’s life, the money’s just as good “day after tomorrow” as it is “just as soon as this block makes it on the chain.” The house/car/rucksack of contraband will still be there, and your money will still be good.

Consider that in a world where almost everything is automated and reacts quickly, some faulty logic somewhere could cascade and lead to a lot of bad stuff happening before anyone even has a chance to notice. Introducing some latency, need for validation, etc, at the right places could mitigate this. I don't think just sprinkling slowness everywhere is the idea.

I do think that the efficiency hype has made us all a little speed blind. It's not like faster = secure either...