Vitalik Buterin: My Personal Experience and Small Suggestions on Crypto Payments

Written by: Vitalik Buterin

Compiled by: Katie Gu, Odaily Planet Daily

In 2013, I went to a sushi restaurant next to the Internet Archive in San Francisco because I heard they accepted Bitcoin payments and wanted to give it a try. When it was time to pay, I asked to pay with Bitcoin. I scanned the QR code and clicked "send." To my surprise, the transaction did not go through. It seemed to have been sent, but the restaurant did not receive it. I tried again, but still nothing. I quickly realized the problem was that my mobile internet was not working well at the time. I had to walk over 50 meters to the nearby Internet Archive to use their Wi-Fi, and finally, I was able to send the transaction.

Lesson learned: The internet is not 100% reliable. We need better broadcasting methods, such as point-of-sale systems with features (like NFC and customer-presented QR codes) that allow customers to directly transmit their transaction data to merchants.

In 2021, I bought tea drinks for myself and friends at a café in Argentina. They explained that it was not intentional for me to pay with cryptocurrency. The café owner recognized me and showed me his account for cryptocurrency trading, so I suggested paying with ETH (using a cryptocurrency exchange account as a wallet is the standard way for on-site payments in Latin America). Unfortunately, my first transaction of 0.003 ETH was not accepted, possibly because it was below the exchange's minimum deposit of 0.01 ETH. I then sent 0.007 ETH. Soon, both transactions were confirmed (I didn't mind paying three times as much; I considered it a tip).

In 2022, I tried to buy tea at another place. The first transaction failed because my mobile wallet's default transaction only sent 21,000 Gas, while the receiving account was a contract that required additional Gas to process the transfer. The attempt to send a second transaction failed because my mobile wallet UI malfunctioned, preventing me from scrolling down and editing the field containing the Gas limit.

Lesson learned: A simple and stable user interface is better than a flashy and stylish one. However, most users don't even know what Gas limits are, so we really need better default settings.

Many times, there is surprisingly long delays between my transaction being accepted on-chain and the service acknowledging the transaction, even being "unconfirmed." Sometimes, I do worry that their payment system has issues.

Often, there can be long and unpredictable time delays between sending a transaction and that transaction being accepted in a block. Sometimes, a transaction can be accepted in seconds, but other times, it may take minutes or even hours. Recently, EIP-1559 has significantly improved this, ensuring that most transactions are accepted in the next block, and the recent Merge has further stabilized block times.

The charts in this report were created by Yinhong (William) Zhao and Kartik Nayak.

However, outliers still exist. If you send a transaction while many others are sending transactions and the base fee is skyrocketing, you may find your transaction rejected due to the high base fee. Worse, the wallet's user interface is not good at displaying this. There are no obvious red alerts, and there are few clear indications of what you should do to resolve the issue. Even experts, who know that in such cases they should "accelerate" the transaction by submitting a new transaction with the same data but a higher "max-basefee," often find it unclear where the button to do this is located.

Lesson learned: The user experience (UX) around designing transactions needs improvement, even though there are simple fixes available. Thanks to the Brave wallet team for seriously considering my suggestions on this issue, first raising the max base fee limit from 12.5% to 33%, and recently exploring ways to make "blocking transactions" prompts more visible in the user interface.

In 2019, I was testing one of the earliest wallets attempting to provide social recovery (social recovery wallet: a modern smart contract wallet that offers high levels of security and better usability). Unlike the smart contract-based approach I preferred, their method was to use Shamir's secret sharing to split the account's private key into five parts, such that any three parts could be used to recover the private key. Users needed to choose five friends (modern term: "guardians"), persuade them to download a separate mobile app, and provide a confirmation code to create an encrypted connection from the user's wallet to the friends' app via Firebase, sharing the private key with them.

This approach quickly led to problems with my wallet. Months later, my wallet had issues, and I needed to use the recovery process to restore it. I had my friends complete the recovery process with their app, but things did not go as planned. Two of them lost their private key shards because they changed phones and forgot to move the recovery app. The third reason was that the Firebase connection mechanism was not working for a long time. Eventually, we found a way to resolve the issue and restored the private key. However, months later, the wallet had issues again. This time, a routine software update accidentally reset the app's storage and deleted its private key. But I hadn't added enough partners to participate in the recovery process because the Firebase connection mechanism was too poor to allow me to do so successfully. I ended up losing a small amount of Bitcoin and ETH.

Lesson learned: Off-chain social recovery involving sharing private information is really fragile and a bad idea unless there are no other options. Friends (guardians) participating in your recovery process should not have to download a separate app, as if your app is only used for such special cases of recovery, it is easy to forget and lose it. Additionally, requiring a separate centralized communication channel can introduce various problems. Instead, the way to add guardians participating in the recovery process should be to provide their ETH addresses, and recovery should be done through a smart contract using ERC-4337 account abstraction wallets. This way, guardians only need to not lose their Ethereum wallets to be effective.

In 2021, I tried to save on fees using Tornado Cash by utilizing the "self-relay" option. Tornado Cash uses a "relay" mechanism where a third party pushes the transaction on-chain because when you withdraw, your withdrawal address usually does not have tokens, and you do not want to pay the transaction from your deposit address as it creates a public link between the two addresses, which is what Tornado Cash tries to prevent. The problem is that the relay mechanism is often expensive, charging a percentage fee that can far exceed the actual Gas fees of the transaction.

To save costs, I once used the relay mechanism for my first small withdrawal, which had lower fees, and then I sent a second larger withdrawal using the "self-relay" feature in Tornado Cash without using a relay. The problem was that I messed up and accidentally operated incorrectly when logging into my deposit address, so the deposit address paid the fees instead of the withdrawal address, creating a public link between the two.

Lesson learned: Wallet developers should start to consider privacy issues more explicitly. Additionally, we need better forms of account abstraction to eliminate the need for centralized or even "joint relays" and to commoditize the relay role.

Other Existing Issues

• Many applications still do not run on the Brave wallet or Status browser. This may be because they did not do their homework correctly and rely on Metamask-specific APIs. Even Gnosis Safe could not run with these wallets for a long time, which forced me to write my own mini Javascript Dapp for confirmations. Fortunately, the latest user interface has fixed this issue.

• The transaction transfer page for ERC 20 on Etherscan, for example: https://etherscan.io/address/0xd8da6bf26964af9d7eed9e03e53415d37aa96045#tokentxns, is easy to send scam information. Anyone can create a new ERC 20 token that can emit a log claiming that I or any other specific person sent tokens to someone else. This is sometimes used to deceive people into thinking I support some fraudulent token that I have never heard of.

• Uniswap used to offer a very convenient feature to swap tokens and send the output to a different address. This feature was really handy when I had to pay someone with USDC but did not have any USDC on me. Now, this interface does not provide this functionality, so I have to convert and then send a separate transaction, which is inconvenient and wastes more Gas. I later learned that Cowswap and Paraswap offer this functionality, although Paraswap currently seems not to work with the Brave wallet.

• Using Ethereum login is a good option, but if you try to log in on multiple devices and your Ethereum wallet can only be used on one device, it is still difficult to use.

Conclusion

A good user experience is crucial. A user interface that looks clean and tidy on the surface but does strange, inexplicable things 0.723% of the time will lead to huge problems, which is worse than a user interface that exposes more real existing detail issues to the user. Directly exposing problems at least allows users to better understand what is happening, know where the problem lies, and resolve it.

Aside from the most significant issue of high transaction fees due to scalability not being fully addressed, user experience is a key reason many Ethereum users (especially in the southern hemisphere) often choose centralized solutions over on-chain decentralized alternatives, which would keep power in the hands of users and their friends, family, or local communities. Over the years, user experience has made tremendous progress. Particularly, the average transaction time has improved from taking several minutes before EIP-1559 to just seconds after EIP-1559 and the Merge, making using Ethereum a very pleasant experience. But we still have a long way to go on this development path.