Closed sourabhxyz closed 1 year ago
ShelleyTxValidationError ShelleyBasedEraBabbage (ApplyTxError [UtxowFailure (FromAlonzoUtxowFail (PPViewHashesDontMatch (SJust (SafeHash \\"2f50ea2546f8ce020ca45bfcf2abeb02ff18af2283466f888ae489184b3d2d39\\")) (SJust (SafeHash \\"15dd0a3ac1244430aacc7e95c2734b51f1a8cf2aaf05e5d6e8124cb78ab54cc9\\"))))])\""})
This is not a signing issue and has nothing to do with Lucid. The construction of the tx is wrong or redeemers/datums were not added correctly to the witness set by atlas. PPViewHashesDontMatch
refers to the script data hash in the body and it doesn't match with the hash that is constructed by datums + redeemers + cost models.
All the cbor transactions seem to have small differences (I looked at the length). So it's obvious the vkey witnesses are different. But I'm not sure if this is what you are even referring to?
@alessandrokonrad Thanks,
Looking at the definition of scriptIntegrityHash
, there seems to be no change in $\text{languages }txw$, $\text{txrdmrs }txw$ & $\text{txdats }txw$ ($pp$ is not part of body) b/w these different transaction bodies so it's a bit odd to see that one (using the signTx
code here) is valid and can be successfully submitted whereas the other one using lucid can't be.
Yes the difference in signature is expected as transaction body itself is changed b/w these two as somehow some of sizedSize
value in transaction outputs gets changed by that signTx
function.
Looking more into what specifically caused PPViewHashesDontMatch
to be thrown by ledger, thanks for your response.
https://github.com/input-output-hk/cardano-ledger/releases/latest/download/alonzo-ledger.pdf
According to 3.1 in the specs datums are indexed by their hashes and redeemers by the redeemer pointer.
The official CML keeps datums and redeemers by insertion order, which is not correct: https://github.com/dcSpark/cardano-multiplatform-lib/blob/31df57ad10c585ad8f0d469990afc525d3dd0e4d/rust/src/builders/witness_builder.rs#L231-L232
Lucid on the other hand uses BTreeMap
to index the datums and redeemers according to specs:
https://github.com/spacebudz/lucid/blob/ef49aff3a1128c40895b04116e8d2359b5eabedc/src/core/libs/cardano_multiplatform_lib/src/witness_builder.rs#L213-L214
@alessandrokonrad After a lot of testing, I now understand where the issue is. The thing is that when performing the signTx
operation in browser wallet api (as in case of nami), they modify the transaction cbor when deserializing where they simplify the transaction outputs to legacy format when possible https://github.com/input-output-hk/cardano-ledger/blob/master/eras/babbage/test-suite/cddl-files/babbage.cddl#L79. Initial cbor I gave had all the outputs in post_alonzo_transaction_output
but after deserialization by CSL/CML, outputs which didn't weren't using babbage era features got simplified to legacy_transaction_output
.
What is the error you get?
Because this:
ShelleyTxValidationError ShelleyBasedEraBabbage (ApplyTxError [UtxowFailure (FromAlonzoUtxowFail (PPViewHashesDontMatch (SJust (SafeHash \\\"2f50ea2546f8ce020ca45bfcf2abeb02ff18af2283466f888ae489184b3d2d39\\\")) (SJust (SafeHash \\\"15dd0a3ac1244430aacc7e95c2734b51f1a8cf2aaf05e5d6e8124cb78ab54cc9\\\"))))])\""})
has nothing to do with it.
I also think that Nami keeps the original bytes when deserializing and adds the signature on the original bytes.
@alessandrokonrad
I also think that Nami keeps the original bytes when deserializing and adds the signature on the original bytes.
Seeing nami's source code here, I don't think it does. Please see this response to the issue I raised yesterday at CSL Github. They have recently added support for FixedTransaction
type which would help get hash (when performing signing) of the original transaction body's cbor.
What is the error you get? Because this: ... has nothing to do with it.
It appears weird to me that I was shown this error at time but now I am adding witness (obtained using wallet's signTx
method) to the original transaction cbor in my haskell backend & now I see incorrect witness signature error which is simply because internally Nami changed the transaction body's cbor.
This issue, the way it stands is confusing and maybe I should open an issue at Nami's Github for it. But I guess it is still relevant as you maintain a custom fork of CML.
Seeing nami's source code here, I don't think it does
That's just a high level function. This is what actually happens when serializing the body again: https://github.com/berry-pool/cardano-multiplatform-lib/blob/29e726d460d6dfb7f01597e74a451d7479abe558/rust/src/serialization.rs#L291-L293 And here when deserializing the tx in the first place: https://github.com/berry-pool/cardano-multiplatform-lib/blob/29e726d460d6dfb7f01597e74a451d7479abe558/rust/src/serialization.rs#L691
Does this issue only appear with Nami or also with Lucid? What if you try Lucid and another wallet?
It is indeed not an issue with Nami & Eternl but is with Lace which tricked me into thinking that it is also an issue with Nami. Thanks for awesome work with Nami!
Hi,
I obtain the following unsigned transaction from Atlas:
CBOR (say
txRaw
)Simplified
And then when I sign it, using the code mentioned here (the
signTx
function), I get:CBOR
Simplified
Which basically populates entry in
txwitsVKey
(comparing unsigned one with now signed one):I can successfully submit this transaction.
However, if I try to sign using lucid, I get:
CBOR
Simplified
Compared to previous one, the difference is mainly in
txwitsVKey
Issue: I am unable to submit ones signed by lucid. It would be nice if we can have lucid interoperable with transactions built using Atlas. In particular, I see this error when submitting:
If required, to reproduce:
config.json
taking cues fromconfig.sample.json
can run the server viacabal run betref-server -- config.json
.yarn
followed byyarn run dev
to run the site locally and try the "Then lets make our first request to add for reference script:" operation in "Browser Integration" page of "Getting Started" section in Documentation.