Allow explicitly setting TransactionOutput serialization format

[refi93]

We (NuFI wallet) are facing issues with Dapp(s) that use the Post-Alonzo era outputs in the transaction bodies sent to be signed via the CIP30 dapp connector because we are unable to properly serialize them with cardano-serialization-lib, because as mentioned in spacebudz/lucid#180, this lib automatically serializes outputs without Datum to alonzo-era outputs, which saves bytes, but doesn't play well with out architecture that relies on trying to rebuild the transaction from the parsed entries to ensure our tx parsing didn't miss any field of the raw tx which could otherwise result in signing a different tx than shown to the user (user sees parsed tx and its effects in a user friendly way) which is a security measure. So currently, due to this limitation of CSL, we are unable to securely (without resorting to blind-signing the raw tx from the dapp) process external txs with Post-alonzo outputs without datums.

I see a similar issue being raised earlier where this choice of serialization format for tx output has been discussed but it was closed with no change to the current approach: #609 (comment) - given the use-case of reserialization of the tx to ensure integrity of data shown to the user vs the real tx body, would you be open to re-consider the option to be able to specify the serialization_format in the TransactionOutput class (

cardano-serialization-lib/rust/src/lib.rs

Line 674 in 23caa65

pub fn new(address: &Address, amount: &Value) -> Self {

)?

[lisicky]

Hi @refi93 ! Thanks for your issue : )
Unfortunately we don't have priority to add this feature, but CSL is open source project and you can contribute to it.
Also I wanna warn you that "reconstructing" a tx by yourself it is a not the best idea because cbor is very wordy standard, I mean there are plenty ways how the same data can be serialized into cbor and all of them will be valid. Small example: array or map can have definite and indefinite length. If you wanna to show a tx before signing you can use FixedTransaction type, it preserves a transaction body unchangeable and you can easily add a new vkey witness to a tx without any concerns about changes in tx body original bytes.

[refi93]

thanks for the quick reply - yeah, we ended up using FixedTransaction for signing and to ensure that the raw tx doesn't contain any field we didn't parse (and show to the user in a user-friendly way/mindfully omit) we try to at least serialize our parsed transaction data (custom structure different from CSL, containing additional details about derivation paths/serialization format) back with CSL and compare it with the re-serialized result of what CSL parsed from the raw transaction body. This seems to be a good enough solution for us for now, closing the issue