"How many confirmations should you wait for a Bitcoin payment to be safe?" That’s true—but you don’t have an hour to wait for a cup of coffee. Back in 2009, someone posed this exact question to Satoshi. If you hold BTC, it’s worth reading Satoshi’s response. [Question] The questioner cited the probability calculations from the whitepaper: to set risk at 0.1%, you must wait nearly an hour for a transaction to confirm. For small payments like web content or digital goods, the wait time is a major barrier. Blocks are added roughly every 10 minutes. Waiting for multiple confirmations means waiting tens of minutes. The same question still arises today. [Satoshi’s Answer 1: Risk depends on the amount] "For micropayments, you can safely accept the payment immediately. The size of the payment is too small for the effort to steal it." Micropayments can be accepted immediately—the amount is too small to justify the effort of stealing. His example was digital goods: micropayments almost always involve intellectual property, so there’s no physical loss to the store. And the real risk is the 0.1% probability multiplied by the likelihood that the buyer is an attacker with a massive computing network. The whitepaper’s numbers assume the worst-case attacker—not an ordinary customer buying a single article. [Satoshi’s Answer 2: Better than credit cards] "Currently, businesses accept a certain chargeoff rate. I believe the risk with 1 or even 0 confirming blocks will be much less than the rate of chargebacks on verified credit card transactions." Businesses already tolerate a certain loss rate. The risk with one—or even zero—confirmations is far lower than the chargeback rate on verified credit card transactions. [Satoshi’s Answer 3: One to two minutes is enough] A common attack targeting stores that accept unconfirmed payments is double-spending: sending the same funds to the store while simultaneously broadcasting another transaction spending those same funds elsewhere. Satoshi’s solution: the store should broadcast its received transaction and simply monitor for one to two minutes to see if any double-spend attempts appear. During that time, most nodes will accept the store’s transaction, and the attacker’s transaction won’t catch up. Attackers only act if they have a high chance of getting something for free—but one to two minutes of monitoring reduces that probability below the threshold where fraud becomes worthwhile. [Fairly speaking] This is Satoshi’s projection, not measured data. And for one to two minutes of monitoring to work, one condition must hold: the network must respect the first transaction received. If later transactions with higher fees can replace earlier ones, then the one-to-two-minute observation window becomes meaningless. [Which direction did BTC take?] Bitcoin Core, the reference client for BTC, enabled "full-RBF" (replace-by-fee) by default in v28.0 released in October 2024. This policy allows unconfirmed transactions to be replaced by others paying higher fees. In v29.0 released in April 2025, the option to disable this feature was removed entirely—officially described in release notes as making "full-RBF the standard behavior." While useful for freeing stuck transactions when fees rise, this change has erased the foundational assumption behind Satoshi’s micropayment solution from Bitcoin Core’s default behavior. It’s no accident that zero-confirmation payments are risky on BTC—it was already an established practice, but now the reference client has cemented this direction as default. [Conclusion] "Wait for confirmations" is sound advice for high-value transactions—and Satoshi agreed. But he never demanded the same waiting time for every payment. Accepting risk proportional to the amount is how cash has always worked. A currency that requires an hour’s wait for a coffee? That’s not the electronic cash Satoshi designed. #Bitcoin #BSV #Micropayments