nami: Nami wallet signing transactions with the wrong keys

Hello!

We recently launched our ISO portal, and we’re having a number of users reporting that the Nami wallet (often with a Ledger attached) is signing the transaction with the wrong private keys.

Here’s a sample transaction:

84a600838258200316be61ac5f8cc3afbd1c9b7bf354fa7ee523bfb291aef70538ca24a7a478b001825820b5ebbdf4d432bb0975938619b1ab953db626e3fed22fbefb0bab919a14d215bb01825820f7dc00bd344e9dfc53f866edac97ae13baf0d4cfce14d0409fafabcc522fdb69010183a20058390151a2a3b41fc1a80af9e1f4e902d26ac264fc2028a13ee629af3c6d9beef8120e0298c457bd0c4b0b65648d269cbb80616f8ca04d2aa8e38b01821a001e8480a1581c9a9693a9a37912a5097918f97918d15240c92ab729a0b7c4aa144d77a14653554e4441451ae062ff90a200583901fde279f027aff73ea3fed34959236d0bbcbc96a0350b0a329a4556ded7244b4a8777b7dc6909f4640cf02ea4757a557a99fb483b05f87dfe01821a002dc6c0a1581c9a9693a9a37912a5097918f97918d15240c92ab729a0b7c4aa144d77a14653554e4441451b00000001f8d3e33ea20058390151a2a3b41fc1a80af9e1f4e902d26ac264fc2028a13ee629af3c6d9beef8120e0298c457bd0c4b0b65648d269cbb80616f8ca04d2aa8e38b011b0000005cfb02f017021a00032af9031a04bbf72a0758208d86230c246148a5a0a76434377780136011b31de0070cd6afee893de1c8a39f0e81581ceef8120e0298c457bd0c4b0b65648d269cbb80616f8ca04d2aa8e38ba100818258201d2c6f36ea927f2efe65932ce4af8da467211f6f837ee17612577c414e4dca845840d05f24a476e483f623ede64769bcc5096e0d6e57defedd1e0daaef6f03b4ed589bfd0660e1b2f36003f36db85c674b5a482fcbe4a55210a7f82d15297e5e8404f5d90103a100a11a000df3f9a178386565663831323065303239386334353762643063346230623635363438643236396362623830363136663863613034643261613865333862a1645249534fa2676e756d44617973016b746f74616c416d6f756e741ae062ff90

Essentially, we take a UTXO from the users wallet, a UTXO from our wallet, and transfer an appropriate amount of SUNDAE in the process.

We include the users staking key in the requiredSigners, to prove they have ownership of the staking address which earned the ISO rewards. I suspect this might be the root cause of the issue.

The user receives the following error:

transaction submit error ShelleyTxValidatorError ShelleyBasedEraBabbage (ApplyTxError [UtxowFailure (FromAlonzoUtxowFail (WrappedShelleyEraFailure (InvalidWitnessUTXOW [VKey (VerKeyEd25519DSIGN \"79acaa9baf732d775bb19120899399da9db0e12a38bbf93db3c6940c3ec4bf84\")]))),UtxowFailure (FromAlonzoUtxowFail (MissingRequiredSigners (fromList [KeyHash \"eef8120e0298c457bd0c4b0b65648d269cbb80616f8ca04d2aa8e38b\"])))])"

(I may have transcribed that from the screenshot wrong, but you get the idea; Screenshot below)

Other wallets have been able to sign these transactions, so I suspect it’s some crossed wires around the API call to the ledger device.

Let me know if there’s any other details I can provide to be helpful!

Regards, Pi Lanningham

image

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Comments: 23 (9 by maintainers)

Most upvoted comments

@alessandrokonrad I got a report today from someone on Nami 3.4.4 and is still receiving this error.

"transaction submit error ShelleyTxValidationError ShelleyBasedEraBabbage (ApplyTxError [UtxowFailure (FromAlonzoUtxowFail (WrappedShelleyEraFailure (InvalidWitnessesUTXOW [VKey (VerKeyEd25519DSIGN \"13ca17a21fa5d19d9f83d333afeb18767c2d3b89bf479558318f7027afd039a2\"),VKey (VerKeyEd25519DSIGN \"4b8cd2675f10442457897f78d9a9d1cb3cebc83d39b81c0cee70ed608fa04fb5\")])))])"

Here’s the CBOR Hex for the transaction we send to Nami:

84a600828258206e3f964d860c875fc543eb62cd428ccee9f4dc11c6c4ccdfc9315663f08c669501825820bd892dddbf5c3c00c8da431f41feaca92f5440a213450425fa5f6a084462ff66184c0183a2005839014306719d301c555a059222c83eb3d6d1a5436246a8803d17640affefb96186f2d8974fd49051478441bf677b3d50275646c241064140b01801821a001e8480a1581c9a9693a9a37912a5097918f97918d15240c92ab729a0b7c4aa144d77a14653554e4441451a09cec2d1a200583901fde279f027aff73ea3fed34959236d0bbcbc96a0350b0a329a4556ded7244b4a8777b7dc6909f4640cf02ea4757a557a99fb483b05f87dfe01821a0016e360a1581c9a9693a9a37912a5097918f97918d15240c92ab729a0b7c4aa144d77a14653554e4441451b000000037443132fa2005839014306719d301c555a059222c83eb3d6d1a5436246a8803d17640affefb96186f2d8974fd49051478441bf677b3d50275646c241064140b018011a00f62052021a000322b9031a04fa1ab807582092f0ff0b7998705936014bd4296c4eec3d940783d63582eb8b00bfd1c48fba480e81581cb96186f2d8974fd49051478441bf677b3d50275646c241064140b018a100818258201d2c6f36ea927f2efe65932ce4af8da467211f6f837ee17612577c414e4dca84584031eae0b858cd83f8bb982335dd4b1bbcf86cacfe0a45903770ce0c4782af6748c3cab2e26e928a62570d86ca053417b41abd139779f7cc56d72071175a74750ff5d90103a100a11a000df3f9a178386239363138366632643839373466643439303531343738343431626636373762336435303237353634366332343130363431343062303138a26349534fa2676e756d44617973016b746f74616c416d6f756e741a051e0127645249534fa2676e756d44617973016b746f74616c416d6f756e741a04b0c1aa

User is using a Ledger Nano X and confirmed that it is also updated to the latest version.

13ca17a21fa5d19d9f83d333afeb18767c2d3b89bf479558318f7027afd039a2 for the error message hashes to 4306719d301c555a059222c83eb3d6d1a5436246a8803d17640affef, which is the payment key for both of the input UTXOs, and 4b8cd2675f10442457897f78d9a9d1cb3cebc83d39b81c0cee70ed608fa04fb5 hashes to 4b8cd2675f10442457897f78d9a9d1cb3cebc83d39b81c0cee70ed608fa04fb5, which is the staking key.