V God: Regarding encrypted payment, my personal experience and small suggestions

Katie 辜

Odaily资深作者

2023-02-28 04:24

This article is about 3077 words, reading the full article takes about 5 minutes

5 lessons learned after the "overturn".

AI Summary

Expand

5 lessons learned after the "overturn".

This article comes from Vitalik Buterin, compiled by Odaily translator Katie Koo.

This article comes from

, compiled by Odaily translator Katie Koo.

In 2013, I went to a sushi restaurant next to the Internet Archive in San Francisco because I heard it accepted bitcoin payments and wanted to try it. When it came time to pay the bill, I asked to pay in Bitcoin. I scanned the QR code and clicked "Send". To my surprise, the deal didn't work out. It appeared to have been sent, but the restaurant did not receive it. I tried again, still nothing. I quickly discovered that the problem was that my mobile internet was not working very well at the time. I had to walk more than 50 meters to the nearby Internet Archive, snuggle up to the Wifi there, and finally be able to send transactions.

Lesson learned: The Internet is not 100% reliable. We need better ways of broadcasting, such as on-site payment systems with some functionality (NFC and customer showing QR codes, etc.) that allow customers to transmit their transaction data directly to the merchant.

In 2021, I was buying tea for myself and a friend at a coffee shop in Argentina. They explained that they didn't mean to ask me to pay in cryptocurrency. It's just that the coffee shop owner recognized me and showed me one of his accounts on crypto exchanges, so I suggested paying in ETH (using a crypto exchange account as a wallet is a standard way of paying live in Latin America). Unfortunately, my first transaction of 0.003 ETH was not accepted, probably because it was below the exchange's minimum deposit of 0.01 ETH. I send another 0.007 ETH. Soon, the transaction was confirmed for both parties (I don't mind paying 3 times more, just consider it a tip).

In 2022, I tried to buy tea at another location. The first transaction failed because my mobile wallet's default transaction only sent 21000 Gas, and the receiving account was a contract that required additional Gas to process the transfer. Attempting to send a second transaction fails because my mobile wallet UI is glitchy, preventing me from scrolling down and editing the field containing the gas limit.

Lesson learned: A simple and stable UI is better than a fancy and sleek UI. But at the same time, most users don't even know what the gas limit is, so we really need better defaults.Many times there is a long and unpredictable time delay between sending a transaction and when that transaction is accepted in a block. Sometimes, a transaction can be accepted within seconds, but other times, it can take minutes or even hours.

More recently, EIP-1559 has improved this significantly, ensuring that most transactions are accepted into the next block, and even the recent Merge has further improved this by stabilizing block times.

image description

Charts for this report were produced by Yinhong (William) Zhao and Kartik Nayak.

However, outliers still exist. If you send a transaction at the same time as many people are sending transactions and the base fee is skyrocketing, you run the risk of the transaction not being accepted because the base fee is too high. To make matters worse, the wallet's UI isn't very good at showing this. There are no obvious red flags and few clear indications of what you should be doing to fix the problem. Even the experts know that in this case the transaction should be "speeded up" by issuing a new transaction with the same data but with a higher "max-basefee", but it is usually possible to do so" button" users do not know where.

Lessons learned: The user experience (UX) regarding design transactions needs improvement, although there are currently simple fixes. Thanks to the Brave Wallet team for taking my suggestions on this issue seriously, first increasing the maximum base fee limit from 12.5% to 33%, and more recently exploring ways to make the "blocked transaction" notification more visible in the UI.

In 2019, I was testing one of the earliest wallets that attempted to provide social recovery (social recovery wallet: a newer smart contract wallet that provides a high level of security and better usability). Unlike the smart contract based approach that I like, their approach uses Shamir's secret sharing to split the account's private key into five parts, in this way any three parts can be used to recover the private key. The user needs to choose 5 friends ("guardians" in the modern term), convince them to download a separate mobile app, and provide a confirmation code that creates an encrypted connection to the friend's app from the user's wallet via Firebase , and send them their shared private key.

This method quickly caused problems for my wallet. After a few months I had a problem with my wallet and I needed to use a recovery program to get it back. I asked my friends to go through the recovery process with me through their app, but things didn't go as planned. Two of them lost their private key shards because they switched phones and forgot to use the mobile recovery app. The third reason is that the Firebase connection mechanism didn't work for a long time. Eventually, we found a solution to the problem and recovered the private key. However, a few months later, the wallet had problems again. This time, a regular software update accidentally reset the app's storage and deleted its private key. But I didn't add enough buddies to participate in the recovery process because the Firebase connection mechanism is too poor to allow me to do this successfully. I ended up losing a small amount of Bitcoin and ETH.

Lesson learned: Off-chain social recovery involving private information sharing is really fragile and a bad idea unless there is no other option. Friends (guardians) who are involved in your recovery procedure should not download a separate app, because if your app is only used for a special case like recovery, it's easy to forget and lose it. Additionally, the need for independent centralized communication channels creates all sorts of problems. Instead, the way to add guardians participating in the recovery process should be to provide their ETH address, and the recovery should be done through smart contracts, using ERC-4337 account abstraction wallets. This way, guardians just need not lose their Ethereum wallets.

In order to save costs, I once used the relay mechanism for the first small withdrawal, which charged a lower fee, and then I sent the second larger one myself using the "self-relay" function in Tornado Cash Withdraw money without using a relay. The problem is, I screwed up and accidentally made a mistake when logging into my deposit address, so the deposit address paid the fee, not the withdrawal address. Caused me to create a public link between the two.

Lesson learned: Wallet developers should start thinking about privacy more explicitly. Additionally, we need better forms of account abstraction to remove the need for centralized or even "federated relays" and commoditize the role of relayers.

secondary title
other problemshttps://etherscan.io/address/0xd8da6bf26964af9d7eed9e03e53415d37aa96045#tokentxnsMany apps still don't work on Brave Wallet or the Status browser. It's probably because they didn't do their homework properly and relied on the metamask specific API. Even Gnosis Safe didn't work with these wallets for a long time, leading me to have to write my own mini Javascript Dapp for confirmation. Fortunately, the latest UI has fixed this issue.
ERC 20 transaction transmission page on Etherscan, for example:
Logging in with Ethereum is a good option, but it is still difficult to use if you try to log in on multiple devices and your Ethereum wallet can only be used on one device.