[beeflet]

Firstly, that appears to be a negative externality. It seems to affect people who use the conventional credit card system as opposed to the new cryptocurrency/micropayments system I propose. So it has the effect of strengthening the cryptocurrency/micropayments system against competition.

For example, I would say that the credit card system is essentially subsidized through other forms of payment via transaction fees/cashback (I can go into detail why I think this is the case, if you would like). This is a mechanism that benefits the credit card companies at the users of other payment mechanisms (cash, crypto, etc.). So this mechanism of the credit card payment system has the effect of strengthening it against competition.

Secondly, I am not even sure if it's a negative externality. It depends on how fraud is handled in the conventional banking system and who takes the blame. Let's say that the charge-back goes all the way to the exchange, so now the exchange that facilitated the transaction is down both X cryptocurrency and Y dollars. In order to be profitable, the exchange needs to charge more in fees and needs to spend more in surveillance to counteract fraud. So ultimately the users of the exchange would pay for fraud.

Lastly, it is important to differentiate the two sources of fraud. There is the fraud inside of the micropayments system, where I pay 0.01 cents to view a webpage and I don't receive what I want. That's a very low-risk fraud, and by gaining a fraction of a cent, they can lose like 100x that in potential business through micropayments.

Then there is the fraud that happens at the border of "hard" money (cash/precious metals/crypto) and "soft" chargeback-able money in the conventional credit card system. This is pretty much facilitated just by these hard forms of money existing and being exchangeable with soft money. I would argue the weakness lies in the insecurity of the soft money systems (specifically the outdated systems of authentication). But you could still apply some sort of limit to the amount of money a single bank account can exchange for crypto (say, $20 a day) without hurting the micropayments system, because the payments involved are so small. So the risk of fraud at the exchange could be much lower for this specific use-case of cryptocurrency.

[Gigachad]

Even in a fully crypto world there is still boundless fraud potential. Even more than traditional banking.

The most obvious one that comes to mind is someone gets a script to run on your browser that loads a ton of the attackers 1 cent paywall articles. Any legitimate financial tool needs a way to roll back fraudulent transactions.

[beeflet]

I imagine that the micropayments system would be facilitated transparently through some popup in the browser, similar to how the browser asks for use of your webcam. I also imagine that some basic, configurable limits would be involved. It would look like "Give news.com ability to request up to 0.10 cents (0.01cents per page load)? Y/N". The first time you load the page.

This is an aside, but in an ideal world, such a mechanism would also be used to reduce fingerprinting! You would have to accept a popup for a page to use features like WebGL, for example.

>Any legitimate financial tool needs a way to roll back fraudulent transactions.

I strongly disagree. I would even say the opposite: the ability to bureaucratically roll-back transactions threatens the legitimacy of money. Specifically, it makes the money non-fungible.

In cryptocurrency, there are transparent multisignature-based escrow systems that allow you to have a defined window of time where the money is co-managed according to certain rules. But transactions need to be able reach a "finalized" state where they are irreversible. Otherwise you just can't ever have a truly secure method of payment between untrustworthy parties and micropayments become useless.

Also, it does not need to be cryptocurrency. Micropayments just need to be efficient, secure, and irreversible. There are other payment systems based on Chaumian cash, (GNU taler being one example) that this could be built on.