CIP-0111? | Web-Wallet Bridge - Wallet Transaction Caching

[yHSJ]

dApps on Cardano have been taking advantage of "transaction chaining," where a transaction spends outputs of a previous transaction that has not yet settled on chain. While this leads to a very smooth user experience, it also means users are getting used to signing transactions which have confusing or incorrect transaction summaries in the wallet UI.

It also allows scammers to take advantage of that confusing or incorrect transaction summary to build malicious chained transactions and trick users into signing transactions they did not want to approve.

This proposal introduces transaction caching into the wallet and requires that wallets display a clear warning when unable to provide a complete transaction summary.

Rendered

[rphair]

Nice addition to the Web-Wallet Bridge family. 👶

[klntsky]

I propose a simpler solution: extend signTx with an optional argument of type [CborHex<Transaction>] which would include all the relevant not-yet-onchain context.

This approach would also cover

some transaction chaining done by dApps, where they reference UTxOs that were created in a transaction that didn't involve the user but hasn't settled yet

The wallets will always be able to reliably tell what is happening, including showing the entire chain (or, rather, DAG) of txs to the user.

[yHSJ]

I propose a simpler solution: extend signTx with an optional argument of type [CborHex<Transaction>] which would include all the relevant not-yet-onchain context.

Yes, this was another idea that I had that is a totally valid solution, and may be better. The key difference would be that it is then the responsibility of the dApp to cache transactions instead of the responsibility of the wallet. I felt that it made more sense to have transactions cached at the wallet level.

Consider the case where a user is using multiple dApps at one time. The caching of transactions at the wallet level also allows wallets to 1) remove UTxOs that are consumed in cached transactions but not yet on chain from the getUtxos response and 2) not let a user sign a transaction if a UTxO in a proposed transaction has been consumed in a cached transaction, preventing some of the "cardano-y" errors that users run into and become frustrated by.

I'm not sure that those are necessarily good ideas, hence why they weren't included in this CIP, but the caching of transactions at the wallet level has multiple benefits.

[cardano-dev4]

Adding comment of support because I saw this on twitter.

Yes we need some way for wallets to handle chained transactions. Now that there have been a few malicious wallet drainers in the ecosystem its very important for wallets to display exactly what is happening or put a warning (perhaps referring to chaining resources) if it cannot

[klntsky]

@yHSJ

I felt that it made more sense to have transactions cached at the wallet level.

They will still be cached on the wallet side. dApps will be able to write to the cache by explicitly providing a set of utxos that should be considered spent after the user signs a given transaction. This is not, in fact, an approach different from caching, just a path to make caching work nicely with transaction chaining.

The caching of transactions at the wallet level also allows wallets to 1) remove UTxOs that are consumed in cached transactions but not yet on chain from the getUtxos response and 2) not let a user sign a transaction if a UTxO in a proposed transaction has been consumed in a cached transaction, preventing some of the "cardano-y" errors that users run into and become frustrated by.

Both cases could also be implemented with the extra argument approach.

1) only concerns wallet's address utxos, and the wallet can infer which of the utxos of the transactions provided via the extra argument are owned by it, and remove them from the set of available utxos

[klntsky]

I don't think cache size is a concern here. The cache will only contain utxos owned by the wallet, so even if we consider ttl, it is safe to assume that the size will not grow beyond manageable values, as each utxo creation will incur costs. We already implicitly allow the wallet size to grow indefinitely (because the number of utxos in a multi-address wallet is unlimited).

If we allow valid implementations to drop cache data due to size limits, then a dApp would not be able to rely on presence of any data in the cache. And an implementation with SIZE=0 will be a valid one.

[yHSJ]

Sorry I missed this somehow. I think that it's really important to define this behavior in a standard. Lots of the current CIPs have undefined behaviors in edge cases and it can cause real issues across the ecosystem.

I want this standard to be comprehensive, regardless of device or wallet software. In the (rare, as you correctly point out) case that a cache has to be purged, it is important the wallet purges transactions in an appropriate manner (ascending chronologically).

It's an excellent point that a wallet could correctly implement this CIP with a cache size of zero bytes. I think it makes sense to add a "minimum cache size" that is n * maxTxSize. I would love to hear others' thoughts on what the value of n should be, since it will necessarily add (small) overhead to the wallet.

[klntsky]

n * maxTxSize

Why do we need to cache whole transactions? I think it could work with caching just UTxOs, and only those that belong to one of the user's addresses.

[yHSJ]

While the specific problem in the CIP is solved with just the UTxOs, I felt it may be useful to have the complete transaction. For example, caching the inputs as well would allow a wallet to refuse a signature on a transaction which consumes inputs which are already consumed in a cached transaction. Perhaps that is out of the scope of this CIP in particular though.

[yHSJ]

@yHSJ

I felt that it made more sense to have transactions cached at the wallet level.

They will still be cached on the wallet side. dApps will be able to write to the cache by explicitly providing a set of utxos that should be considered spent after the user signs a given transaction. This is not, in fact, an approach different from caching, just a path to make caching work nicely with transaction chaining.

The caching of transactions at the wallet level also allows wallets to 1) remove UTxOs that are consumed in cached transactions but not yet on chain from the getUtxos response and 2) not let a user sign a transaction if a UTxO in a proposed transaction has been consumed in a cached transaction, preventing some of the "cardano-y" errors that users run into and become frustrated by.

Both cases could also be implemented with the extra argument approach.

1) only concerns wallet's address utxos, and the wallet can infer which of the utxos of the transactions provided via the extra argument are owned by it, and remove them from the set of available utxos

I agree in general it makes sense to also support providing "context" at the sign endpoint level. I think the two ideas work well together, but it is important that a wallet does the caching as well. Otherwise, the attack vector would always exist (just don't pass in the optional additional transactions)

[Ryun1]

Should this be a CPS rather than a CIP?

[yHSJ]

Should this be a CPS rather than a CIP?

I think this particular proposal provides one solution to an (currently) unwritten CPS. I thought about writing a CPS first, which @Crypto2099 also suggested, but I felt that I'd rather not release the blueprint for a scammer without also providing a potential solution for wallets.

[Ryun1]

I think it is worth discussing here the alternatives to this approach, such as stronger warnings within wallets OR not letting users sign unknown transactions.

[Ryun1]

I would change this from being an explicit extension to these CIPs and rather be a best practice that applies to these other CIPs

[yHSJ]

I think I agree in general, I was just trying to follow the standards for "adding on" to the existing CIPs. That said, I think that it makes more sense to not explicitly extend any one CIP, especially as this CIP should be used along side ANY CIP that involves a wallet prompting users for a signature.

[rphair]

Agreed to promote at today's CIP meeting 🚀

[cardano-dev4]

+1 from me. Caching is a good solution and this is definitely critical to Cardano UX.

Also it might be wise to add some method of adding transaction to the wallet cache. This can help sites that submit transactions through the their own backend

EDIT: This caches on sign transaction which is effectively what I wanted above

[rphair]

@yHSJ I've been assuming that this will be moving ahead with some concurrent developments from the Wallets Working Group... but we do need to update the status to Waiting for Author because of the indefinite delay: which means you should please also update this PR to detail whatever we have been waiting for these past several months.

If you can please keep us updated, the editors would want to ensure that all these Web-Wallet Bridge proposals can move together as a pack & get merged when the dependencies are met. If you have anything that can help that happen, please let's get it on record here. cc @Ryun1 @Crypto2099

[yHSJ]

@rphair Thanks for the update! I apologize, I've been very distracted with lots of other work.

We have been waiting on some implementations of this CIP to go live along with feedback from the wallets. Other than that, I think we're good to go...?

I will follow up with some wallets again to see if there is a status update on these things. Thanks for the reminder!