Scenario: I receive a transaction CBOR from an external service, where the redeemers are structured as a Map (introduced in the conway era) instead of an array (the legacy format).
Bug 2: After bypassing the bug above, and after signing the transaction, during the .complete() step, I've noticed that the redeemers are changed to the array (legacy) structure. This causes the transaction to be rejected because the script hash of the transaction in the tx body doesn't match the one computed by the node.
Steps to reproduce:
Get a transaction CBOR with the redeemers structured as a Map (as indicated here)
Bug 1: Build a TxSignBuilder using the method fromTx
Bug 2: Sign and submit the transaction. The node will reject it with error PPViewHashesDontMatch.
Scenario: I receive a transaction CBOR from an external service, where the redeemers are structured as a Map (introduced in the conway era) instead of an array (the legacy format).
Bug 1: when constructing a new TxSignBuilder from the tx CBOR, the following implementation: https://github.com/Anastasia-Labs/lucid-evolution/blob/57719ab8e1407fc0946aec021725951dafdfdc35/packages/lucid/src/tx-sign-builder/TxSignBuilder.ts#L91 causes the program to crash, because the redeemers are in the conway format, not the legacy.
Bug 2: After bypassing the bug above, and after signing the transaction, during the
.complete()step, I've noticed that the redeemers are changed to the array (legacy) structure. This causes the transaction to be rejected because the script hash of the transaction in the tx body doesn't match the one computed by the node.Steps to reproduce:
fromTx