nami: Vasil branch produces incorrect witnesses

It looks like the vasil branch of nami properly understands babbage era transaction (at least, the ones that have all the babbage era features set to use the *None constructors from cardano-api) - however, I believe it creates the witnesses improperly, as subsequent transaction submission towards testnet yields:

ShelleyTxValidationError ShelleyBasedEraBabbage (ApplyTxError [UtxowFailure (FromAlonzoUtxowFail (WrappedShelleyEraFailure (InvalidWitnessesUTXOW [VKey (VerKeyEd25519DSIGN ...)])))])

When I try to manually sign with a private key using cardano-serialization-lib 11.0.0-rc.1, with effectively the same logic nami uses under the hood - everything works fine and the transaction goes through.

Since the issue probably lies in the cardano-multiplatform-lib wasm files used by nami, I’m unsure where exactly to look to try and quickly fix it via a PR.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 1
  • Comments: 19 (8 by maintainers)

Most upvoted comments

@TotallyNotChase I just updated the vasil branch for Nami. It should support now the legacy output serialization. Actually Nami makes now the witness on the raw cbor encoded tx body that is provided. So it should work for any tx.

And you may wanna check out Lucid 0.5.4 which also has the legacy output support now. Lemme know how all of this goes.

However I don’t like it actually that I’m forced to serialise transactions in a certain way although the specifications do allow me differently

Completely understandable. Sometimes the ecosystem just chooses the fundamentally wrong thing… and we devs have to just follow by also doing the wrong thing. In this particular case though, I’d argue the specification shouldn’t leave room for ambiguity, and yet it does.

Maybe wallets should sign the raw body instead of serialising it on their own and then sign it which results in wrong witnesses obviously.

I always asked myself why this isn’t what all the wallets do. Just seems a lot more cryptographically reasonable to me.

Hello again @alessandrokonrad

Some more thoughts: I suspect this affects Lucid as well. I can’t use Lucid’s vasil branch with other wallets (for example: eternl) - only nami. Other wallets are also failing submission with a similar error of sorts. Do you reckon this issue is worth a deeper look? I could perhaps try helping if you want me to look in a particular spot. I’d ideally like this incompatibility fixed since this doesn’t only affect nami adoption on our (and our clients’) ecosystem side, but it may now also affect Lucid adoption - I’d like to prevent that.

Perhaps I should start by looking at the tx output serialization. Though the error in different wallets (and cardano submit api) indicate it’s an issue in the signatories for some reason.

I think what other wallets do is check if the output contains an inline datum or a refScript. If so use the new output format otherwise the legacy format. I can do that too, however I don’t like it actually that I’m forced to serialise transactions in a certain way although the specifications do allow me differently. Maybe wallets should sign the raw body instead of serialising it on their own and then sign it which results in wrong witnesses obviously. But I can support the legacy format for now as well.

Indeed, it is the incompatibility between the cardano libs. Using the specific cardano multiplatform lib impl from temporary_modules in this repo (vasil branch, of course) works properly. I tried with newer official dcSpark/CML as well since I noticed there was a 1.0.0 release - same issue there.

This is rather weird though - surely incompatibility with the upstream stuff isn’t intentional. After all, most frameworks built around this stuff that I’ve worked on, are and will be using either official CSL or official CML. I suppose it’s worth a deeper look to find the source of incompatibility.

I’m pretty sure it has to do with how the outputs are serialized. There is a new format, but the legacy format is the primary one supported by the CSL.