Conversation

remains astonishing to me that there’s no real way to know what an eth transaction actually does before signing it, and the ecosystem is basically fine with this
87
862
Replying to and
For Bitcoin, the flow is almost always generating a transaction with your wallet. There are only a small set of operations which can be composed to implement straightforward things. For example, Lightning channels are simple 2-of-2 multisig with a timelock setup for recovery.
1
2
In some cases, for doing multisig with multiple wallets, you would be generating a partially signed transaction fully understood by each wallet involved. For both multisig and hardware wallets, it's important that it's fully understood and displayed by the UI for confirmation.
1
Ethereum has complex arbitrary code with loops, method calls and interactions across contracts. The wallets for working with Ethereum have no idea what they're approving. Users have no idea what they're actually approving and it's pretty easy for all their stuff to be stolen.
1
2
The flow for a Bitcoin wallet is generating a transaction based on what you want and then confirming it. For a hardware wallet, you're required to confirm the destinations/amounts, fee, time lock configuration, etc. and it won't sign what it can't understand and show to you.
1
2
Flow for Ethereum is authorizing a web site to interact with your wallet, web app generates code and you blindly sign a transaction using that code with no clue what you're actually doing. This is how they end up in the "all my apes gone" situation even with a hardware wallet.
1
5
The programs have state and often depend on lots of external state. Their results can be very subtle. Simulating it and then using a domain specific viewer to inspect results would have a lot of issues. It would likely catch some low hanging fruit but it's not a viable solution.
1
4
This Tweet is from a suspended account. Learn more
Show replies