Enforceable Human-Readable Transactions: how to solve Bybit-like hacks

Security
31

Ah good point.

I feel like @Elyx0’s QR code point holds water, though. Basically, you base64 encode the data for the transaction and show it as a QR code. Then, someone can use whatever device they want to make sure the transaction is good.

You could have a second QR code “decoder” hardware device, or some hardware devices could opt in to being connected to the internet to help decode and “translate” the data.

To me, it feels like we either:

  1. Show a QR code to make it easier to extract the data off hardware devices. This could be base64 encoded, so the security assumptions would be the same as normally showing the screen itself, and just make sure the base64 encoding is good.

  2. We hash the data to a calldata digest or EIP-712 digest and let the user compare it to an expected one.

  3. We have smart contract developers add a new function to their contracts where they hash a description that users have to sign in addition to their original transactions.

TBH, I feel like #1 is actually the best option, #2 is less engineering lift for hardware wallets (and they can still do #1), and #3 is redundant, and in my opinion in the long run is more cumbersome, and gas ineffective.

I’d imagine if we go with #3, eventually descriptions will get so long and confusing, that we will just wind up back here because no one reads them because they are too confusing anyways. My argument here is that now that I “can read” calldata (I feel like I’ve learned the language of the hex) it feels very weird for me to have to sign another transaction which has essentially the same information just “in another language”. Granted, the calldata doesn’t have the ABI/documentation, but then I’d still rather do like a docsURI feature and let the user find that.