-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange issue with vKey witness problem #133
Comments
Looks like there is a deeper issue with the signing, this is a tx with just a simple metadata included: Transaction created: {
"type": "Unwitnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a600818258207924b21c32851af9113ee850b1853a9f65ce8753bdd7f71263698b188a24bea30001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a00626df9a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e0b021a0002d535031a005d12fa09a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e0107582079ecea5c9901f2d1c810838fda536d4c0140a17462f1e226029742b1eb6893c5a101818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a11902a2a1636d7367816c746573746d65746164617461"
} After it went thru the HW-CLI autocorrection: {
"type": "Unwitnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a600818258207924b21c32851af9113ee850b1853a9f65ce8753bdd7f71263698b188a24bea30001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a00626df9a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e0b021a0002d535031a005d12fa07582079ecea5c9901f2d1c810838fda536d4c0140a17462f1e226029742b1eb6893c509a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e01a101818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a11902a2a1636d7367816c746573746d65746164617461"
} Notice that nothing has changed other than the order of the array entry No7 vs No9 before and after the canonical correction. But no change in the metadata hash or so, because nothing in the metadata was changed. Signed via HW-Wallet: {
"type": "Witnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a600818258207924b21c32851af9113ee850b1853a9f65ce8753bdd7f71263698b188a24bea30001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a00626df9a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e0b021a0002d535031a005d12fa07582079ecea5c9901f2d1c810838fda536d4c0140a17462f1e226029742b1eb6893c509a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e01a200828258201287e9ce9e00a603d250b557146aa0581fc4edf277a244ce39d3b2f2ced5072f5840b489b560acef6638b46e5a6a2c959ca8969503131452b973607cc090951e996bd71c03db8ad223ae666cb0b918ecbc568d42db86ee8ffdbb712a77c884468f0f8258200186abff41121414f856fd8cf613399f9a30e413bb1c75c2413f46121f0203495840cea580f56b5bcc34ef5e7b989afce1310e58f58c8d248ae7088a629cdc2e2dd79b829bd6bca54c9a635e13b0b3e7b1fd0178b972a0a2f20622858b16c8b2780101818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a11902a2a1636d7367816c746573746d65746164617461"
} -> SUBMIT -> ERROR Submitting the transaction via the node... Command failed: transaction submit Error: Error while submitting tx: ShelleyTxValidationError ShelleyBasedEraAlonzo (ApplyTxError [UtxowFailure (WrappedShelleyEraFailure (InvalidWitnessesUTXOW [VKey (VerKeyEd25519DSIGN "1287e9ce9e00a603d250b557146aa0581fc4edf277a244ce39d3b2f2ced5072f")]))]) Notice - If no metadata is included in the transaction it is going straight thru. |
UPDATE: This one FAILED... After creating {
"type": "Unwitnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a60081825820bf45f88d729d0af72e24d2d1debe011df2fb3da3ce7b83c31a17ed921df65c9a0001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a005cc38fa1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e0d021a0002d535031a005d156109a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e0107582079ecea5c9901f2d1c810838fda536d4c0140a17462f1e226029742b1eb6893c5a101818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a11902a2a1636d7367816c746573746d65746164617461"
} After canonical correction: {
"type": "Unwitnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a60081825820bf45f88d729d0af72e24d2d1debe011df2fb3da3ce7b83c31a17ed921df65c9a0001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a005cc38fa1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e0d021a0002d535031a005d156107582079ecea5c9901f2d1c810838fda536d4c0140a17462f1e226029742b1eb6893c509a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e01a101818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a11902a2a1636d7367816c746573746d65746164617461"
} After signing: {
"type": "Witnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a60081825820bf45f88d729d0af72e24d2d1debe011df2fb3da3ce7b83c31a17ed921df65c9a0001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a005cc38fa1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e0d021a0002d535031a005d156107582079ecea5c9901f2d1c810838fda536d4c0140a17462f1e226029742b1eb6893c509a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e01a200828258201287e9ce9e00a603d250b557146aa0581fc4edf277a244ce39d3b2f2ced5072f5840e6b4223e1cd0f32c1e3b026278ab3a11e1d82336a57a732e7e9cab3c13744e5533cf8e3f2e8f571f481d85e0ba2ddeff2be7565647ff158cb786d2ea8fd4c90f8258200186abff41121414f856fd8cf613399f9a30e413bb1c75c2413f46121f0203495840965166ab0d518bb0baca89a93fbe0118cbe9ee8d1a62502e2949cc7a937ebda1a9ecca9e0d5b069a83a0185306b56dcbd25ccf40ca4f09ada9b0c8862c37ab0d01818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a11902a2a1636d7367816c746573746d65746164617461"
} -> SUBMIT -> ERROR Submitting the transaction via the node... Command failed: transaction submit Error: Error while submitting tx: ShelleyTxValidationError ShelleyBasedEraAlonzo (ApplyTxError [UtxowFailure (WrappedShelleyEraFailure (InvalidWitnessesUTXOW [VKey (VerKeyEd25519DSIGN "1287e9ce9e00a603d250b557146aa0581fc4edf277a244ce39d3b2f2ced5072f")]))]) This one went thru again, same transaction builing! After creation: {
"type": "Unwitnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a60081825820bf45f88d729d0af72e24d2d1debe011df2fb3da3ce7b83c31a17ed921df65c9a0001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a005cc38fa1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e0d021a0002d535031a005d15d009a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e0107582079ecea5c9901f2d1c810838fda536d4c0140a17462f1e226029742b1eb6893c5a101818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a11902a2a1636d7367816c746573746d65746164617461"
} After canonical correction: {
"type": "Unwitnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a60081825820bf45f88d729d0af72e24d2d1debe011df2fb3da3ce7b83c31a17ed921df65c9a0001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a005cc38fa1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e0d021a0002d535031a005d15d007582079ecea5c9901f2d1c810838fda536d4c0140a17462f1e226029742b1eb6893c509a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e01a101818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a11902a2a1636d7367816c746573746d65746164617461"
} After signing: {
"type": "Witnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a60081825820bf45f88d729d0af72e24d2d1debe011df2fb3da3ce7b83c31a17ed921df65c9a0001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a005cc38fa1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e0d021a0002d535031a005d15d007582079ecea5c9901f2d1c810838fda536d4c0140a17462f1e226029742b1eb6893c509a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e01a200828258201287e9ce9e00a603d250b557146aa0581fc4edf277a244ce39d3b2f2ced5072f5840928a3b63e2f789cbeed6372dc303eefbcd38e4dba5acd814ff9de03ee47a3c2d8c7faae713fb859e5b3e5ae0b22ba5ebe1f06f0770b3e1377f0046b1a27f040d8258200186abff41121414f856fd8cf613399f9a30e413bb1c75c2413f46121f02034958401e0a0f3b5b09b6ba58048c016aad4719230e3949013b3aa0a59c259859ff77d1d99567131fb9b7b1c3f3b75d7a93783e577a4a517e7f7a51de25f383c63fa20801818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a11902a2a1636d7367816c746573746d65746164617461"
} -> SUBMIT -> OK |
Again, this one went thru: After creating: {
"type": "Unwitnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a60081825820c8194a0e3e8687a76dbf8dbf2c0351c41b3c0e1cf07124d0644e68cac0e7a6710001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a00a49046a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e08021a0002e195031a005d1bce09a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e010758206f06a72a7e5e681582a35158205d77394390e939a0dfaffc8c826c71a1c9cb4ba101818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a301a164746573746c7365636f6e6420656e74727902a164746573746b666972737420656e7472791902a2a1636d736781782c6d696e74696e672077697468206e6f6e2d63616e6f6e6963616c206d65746164617461206174746163686564"
} After canonical correction: {
"type": "Unwitnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a60081825820c8194a0e3e8687a76dbf8dbf2c0351c41b3c0e1cf07124d0644e68cac0e7a6710001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a00a49046a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e08021a0002e195031a005d1bce0758206f06a72a7e5e681582a35158205d77394390e939a0dfaffc8c826c71a1c9cb4b09a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e01a101818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a301a164746573746c7365636f6e6420656e74727902a164746573746b666972737420656e7472791902a2a1636d736781782c6d696e74696e672077697468206e6f6e2d63616e6f6e6963616c206d65746164617461206174746163686564"
} After signing: {
"type": "Witnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a60081825820c8194a0e3e8687a76dbf8dbf2c0351c41b3c0e1cf07124d0644e68cac0e7a6710001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a00a49046a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e08021a0002e195031a005d1bce0758206f06a72a7e5e681582a35158205d77394390e939a0dfaffc8c826c71a1c9cb4b09a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e01a200828258201287e9ce9e00a603d250b557146aa0581fc4edf277a244ce39d3b2f2ced5072f58403ee83a08984e05a0cf137a09980eba51634562714e99a6f4019ddb362430fe3d6cba7aed42c1fad11e0b03b571ad16e570f1758300dc948f4620ac331b2def028258200186abff41121414f856fd8cf613399f9a30e413bb1c75c2413f46121f020349584083bc3549c542913c79b0f89a65c284cfd27d7351d4b8a4b5d42a71e5f8c426b11fe4dd21228dcc021303ce0a78c1ea61457d5b41e9f1fb2abdf5783928507d0801818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a301a164746573746c7365636f6e6420656e74727902a164746573746b666972737420656e7472791902a2a1636d736781782c6d696e74696e672077697468206e6f6e2d63616e6f6e6963616c206d65746164617461206174746163686564"
} -> SUBMIT -> OK Same command again... After creating: {
"type": "Unwitnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a6008182582076ec1b51e8073c2f2a48266ddf10eff415b697fe6866153861c7b415182ca0a20001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a00a1aeb1a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e09021a0002e195031a005d1be909a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e010758206f06a72a7e5e681582a35158205d77394390e939a0dfaffc8c826c71a1c9cb4ba101818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a301a164746573746c7365636f6e6420656e74727902a164746573746b666972737420656e7472791902a2a1636d736781782c6d696e74696e672077697468206e6f6e2d63616e6f6e6963616c206d65746164617461206174746163686564"
} After canonical correction: {
"type": "Unwitnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a6008182582076ec1b51e8073c2f2a48266ddf10eff415b697fe6866153861c7b415182ca0a20001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a00a1aeb1a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e09021a0002e195031a005d1be90758206f06a72a7e5e681582a35158205d77394390e939a0dfaffc8c826c71a1c9cb4b09a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e01a101818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a301a164746573746c7365636f6e6420656e74727902a164746573746b666972737420656e7472791902a2a1636d736781782c6d696e74696e672077697468206e6f6e2d63616e6f6e6963616c206d65746164617461206174746163686564"
} After the signing: {
"type": "Witnessed Tx AlonzoEra",
"description": "Ledger Cddl Format",
"cborHex": "84a6008182582076ec1b51e8073c2f2a48266ddf10eff415b697fe6866153861c7b415182ca0a20001818258390074976c54afaf444f7cd499bd8519aac6592b13b22b9d5817f0da5c5203d205532089ad2f7816892e2ef42849b7b52788e41b3fd43a6e01cf821a00a1aeb1a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e09021a0002e195031a005d1be90758206f06a72a7e5e681582a35158205d77394390e939a0dfaffc8c826c71a1c9cb4b09a1581c34250edd1e9836f5378702fbf9416b709bc140e04f668cc355208518a1494154414441636f696e01a200828258201287e9ce9e00a603d250b557146aa0581fc4edf277a244ce39d3b2f2ced5072f584026675a33243f5445977a3d9f7a5cd1d1f471cefe974263d94fc9a7ca2d136b538d40c1205ca6591ecb202cdb4b4140ef5004b0bb707c64201221ad76f924a5018258200186abff41121414f856fd8cf613399f9a30e413bb1c75c2413f46121f020349584005c4e8042e1386953a4c9a7c4acc623f81f44a238174ff247ae31b6868f94c4a74713303049063d998c46d094ef804483dbd4e4b2bcb26cda79ca0d45871d20101818200581c45d70e54f3b5e9c5a2b0cd417028197bd6f5fa5378c2f5eba896678df5d90103a100a301a164746573746c7365636f6e6420656e74727902a164746573746b666972737420656e7472791902a2a1636d736781782c6d696e74696e672077697468206e6f6e2d63616e6f6e6963616c206d65746164617461206174746163686564"
} -> SUBMIT -> ERROR Command failed: transaction submit Error: Error while submitting tx: ShelleyTxValidationError ShelleyBasedEraAlonzo (ApplyTxError [UtxowFailure (WrappedShelleyEraFailure (InvalidWitnessesUTXOW [VKey (VerKeyEd25519DSIGN "1287e9ce9e00a603d250b557146aa0581fc4edf277a244ce39d3b2f2ced5072f")]))]) Something strange is going on here... |
@janmazak @gabrielKerekes not sure if this is a node/cli issue or a hw/signing issue |
i can kind of replicate the issue, i mint an asset (+1), signing, submit -> ok, wait for the next block. mint again an asset (+1) -> fails with vkey witness error. |
The metadata hash (called the auxiliary data hash in alonzo) is inside of the transaction body. The transaction signature is a digital signature of the transaction ID, which is a hash of the transaction body. So if you rearrange the fields in the transaction body, you will get a different transaction ID and invalidate the signature. Indeed that's what the |
This doesn't make sense to me. The fields for map entry 7 and 9 changed position, but the auxiliarydata at the end didn't change so also no change in the auxmetahash. And this was done before the tx was signed. Not afterwards. It also does not explain the strange behaviour after a block or after two blocks. Same transaction building over and over again is one time working, the other time not. |
Are you sure that the transaction that you submitted had the same ID as that which you signed? The signature will only be valid for one of the two transaction bodies that you have above (even though they are semantically the same). |
The steps above are in order. First the generation via cardano-cli build-raw. After that it is going thru hw-cli which will do a canonical order to be ready for hw-wallet-signing. After that it is singed via the hw-wallet and after that its submitted. No jumps. |
Hm, I'm not sure what the issue could be 🤔 @gitmachtl Can't there be some concurrency problem within the scripts you are using? E.g. the transaction file has not yet been fully written before being read, parsed and sent to the HW wallet? Which would mean that you are sending the previously built transaction to the HW wallet 🤔 Have you tried re-signing and/or re-submitting the failed transaction manually after your script failed? Did that work? Could you confirm that the data displayed on Ledger are the data you expect (mainly the fee, which is the only thing which changes between the failed and passed attempts)? |
I doubt that, here you can see the sequence of the txfile correction. The filename of the txfile after the building via cardano-cli transaction build-raw is passed. After the correction the file is overwritten with the corrected one and again checked about the error code. After the function the txfile is passed to the hw-cli for signing. And as you can see in the screen shots, the output of the corrected txfile is directly made via a cat command: $ cat ${TxBodyFile} https://github.com/gitmachtl/scripts/blob/e905dd84c1a0c2315aca87ea0b6aa8a1c643f47a/cardano/mainnet/11a_mintAsset.sh#L366 |
The timing is a bit hard on that, because once another new block is coming in, it works again. Its really a weird thing, because nothing changes for the transactions, only the input utxo, the slotnumber and the amount of the tokens. |
The shown error with the vKey witness is the one for the asset policy, not the payment vkey. |
The issue is also showing up with a simple Asset mint and singing via HW-CLI ! This is without additional metadata attached.
This was tested on PreProd - 1.35.3 node/cli - alonzo era |
I can also reproduce it on 1.35.2 node/cli - legacy testnet - babbage era, the errormessage of the 1.35.2 cli is a bit different than:
|
Downgraded the Cardano-App to 4.1.2 and did a minting Transaction without any other metadata attached, also no auto-canonical-correction:
|
Ok, so it could be a rare issue with the hw-signing and the used policy for the assets. I retried the same transactions over and over again with another policy and i think 15-20 transactions in a row without an issue at all. Than switched back to the original policy and the third try failed again. Using the same policy with cli key signing for the payment, does not generate a single error at all. I am running automated minting transaction with that policy on the testnets for traffic generation if i am not doing this testing here. I also downgraded hw-cli to 1.10 and cardano-app to 4.1.2 for that. Will repeat this same test again. |
@JaredCorduan @gabrielKerekes SORRY GUYS! Turns out it was a testing issue, i had an additional testroutine running in a loop in the background that also used the same policy and wrote out to the same temporary witness file. So while doing the Signing on the HW-Wallet, the policy witness file changed in the meantime from time to time and was than assembled. That caused of course the witness error for the policy vkey. But i saw the following: I extracted the secret keys from the Ledger Mnemonic to compare the signing between CLI keys and HW-CLI signing. The witness via cardano-cli looks like: {
"type": "TxWitness AlonzoEra",
"description": "Key Witness ShelleyEra",
"cborHex": "8258200186abff41121414f856fd8cf613399f9a30e413bb1c75c2413f46121f02034958405d25f1333ffe436a318b5877082183d4b1657ff5d012f3124a4a3c6f7652af35519c74e2ecbe54bfff32891d1750895b13f39d911b745d8a7fbd667205754703"
} same signing keys via HW-CLI witness looks like: {
"type": "TxWitness AlonzoEra",
"description": "",
"cborHex": "82008258200186abff41121414f856fd8cf613399f9a30e413bb1c75c2413f46121f02034958405d25f1333ffe436a318b5877082183d4b1657ff5d012f3124a4a3c6f7652af35519c74e2ecbe54bfff32891d1750895b13f39d911b745d8a7fbd667205754703"
} So the HW-CLI adds
infront, why? Looks like it doesn't bother cardano-cli assemble much, but i was wondering why it is there. |
great to hear the mystery is solved @gitmachtl ! I'll try to have a look soon to see what that |
I'm also glad the issue is resolved 👍 I'm not sure about the 0 🤔 It seems that it was used for distinction between Byron and Shelley keys - perhaps cardano-cli used that too at some point? 🤷 Maybe @janmazak has some more insight. Anyways, we don't even support Byron keys anymore so if the nested array is an issue, it could be removed, but if it's just a detail I'd rather not touch it. |
@gitmachtl @JaredCorduan The 0 in the outer array marks the witness as Shelley witness. The value would be 2 for Byron witness (and it seems to me we still support them? @gabrielKerekes ). Apparently, that's how cardano-cli did it in the past, and they might have changed it in the meantime. Cardano-hw-cli mimicks behaviour of cardano-cli. However, since lots of that behaviour is undocumented and kind of random (e.g. serialization format not a canonical CBOR), we just observed and copied it as best as we could, and we don't track changes in cardano-cli in detail, so basically while it works, it works, and if something breaks, then we investigate and change something in the hw-cli code. So I'd agree that while it works, it is best not to touch it. It does not have any effect on tx size and fees, it's just a discrepancy in the temporary file of cli tools. |
The following command fails with
Is this a bug then? |
@gabrielKerekes I'd say it is a bug. That function only adds description, getting the key from the HW wallet etc. should not fail. I am not sure what the correct description should be, but I'd go with "Payment Verification Key" (the same as for Shelley) since cardano-cli does not care about derivation paths, it only works with derived keys. |
Closing this as the issue is resolved. I created a new issue for the Byron paths #134. |
Asset Minting transaction + 2x metadata files attached, the following example works:
Transaction creation:
After it went thru HW-CLI canonical order correction:
After the signing via HW-Wallet:
-> SUBMIT -> OK
$ cardano-cli transaction view ... <above signed txfile>
This is the same transaction again with the only difference that the order of the 2x metadata files have switched places during the cardano-cli build-raw command:
Transaction creation:
After it went thru HW-CLI canonical order correction:
After the signing via HW-Wallet:
-> SUBMIT -> ERROR
Submitting the transaction via the node... Command failed: transaction submit Error: Error while submitting tx: ShelleyTxValidationError ShelleyBasedEraAlonzo (ApplyTxError [UtxowFailure (WrappedShelleyEraFailure (InvalidWitnessesUTXOW [VKey (VerKeyEd25519DSIGN "1287e9ce9e00a603d250b557146aa0581fc4edf277a244ce39d3b2f2ced5072f")]))])
Transaction View shows the following:
$ cardano-cli transaction view ... <above signed txfile>
The text was updated successfully, but these errors were encountered: