[BUG] - Cardano-cli creates transactions with witness-set as an array, not a map - this is invalid.

[kieransimkin]

Summary
Cardano-cli generates transactions which do not meet the ledger specification. Furthermore, if you're trying to sign these transactions in a browser wallet such as Nami - it will not parse them, because serialization-lib (correctly) detects the transactions produced by Cardano-cli as invalid. This is a major stumbling block for dApps looking to integrate a Cardano-node backend with any browser wallet which uses serialization-lib - as things stand, that's just not possible - due to such a simple error:

In the case of an empty witness set, the field should be an empty map {}, not an empty array [].

Steps to reproduce
Generate a transaction with Cardano-cli and observe the witness-set field - in the case of an empty witness set, you will find that it is an empty array, when the ledger spec indicated that it should be a map.

Expected behavior
Witness set field should be an empty map: {}

System info (please complete the following information):
Latest everything

Screenshots and attachments
Example cbor:
86a600828258207a9ae75e073a713791cc3045c2c2f62b925c4d33ae670da445ec80f20c459d7f0082582093ce7d39fc764e8ec9026a50f1f41f0d18649e18378718e91c45060fead0c703010d80018382583900af035fb9a547276bbb86a1936882524463eccb82465fcdf44489013713a39f099c533eb97b848aea0ae05850b4b40ec1ec05541a3f84c9b11a0483d91a83581d70eb18d99e0c392b18a436d595b5223e8fff559c4643118c1d403dfaab821a001e8480a1581c79e78a324e27842aa2ccaa21a710198b1db2c2a835b70d663b68a9dca1534d79546573746e6574547231303030303237310158201db43f14402b617c93f860381ec852799320d35c1be86386dffa53d792d846d582583900af035fb9a547276bbb86a1936882524463eccb82465fcdf44489013713a39f099c533eb97b848aea0ae05850b4b40ec1ec05541a3f84c9b1821a01312d00a2581c6b8d07d69639e9413dd637a1a815a7323c69c86abbafb66dbfdb1aa7a14002581c79e78a324e27842aa2ccaa21a710198b1db2c2a835b70d663b68a9dca2534d79546573746e65745472313030303032363701534d79546573746e65745472313030303032363801021a0002d8a50e8007582053d1932595c943555dd467aa2d3a36efdc865caf35ad77c04c270edcfd2dc39c9fff8080f5d90103a100a119013863626172

Additional context
We're trying to complete our smart validator integration at Artifct.app - our architecture involved having cardano-cli generate transactions which were then sent to Nami wallet for signing in the browser. Nami uses serialization-lib to parse the transactions, but it fails on every transaction we generate from Cardano-cli due to this invalid witness set field. I have discussed this with an Emurgo developer on their issues tracker:
Emurgo/cardano-serialization-lib#259

[Mercurial]

Also had this issue where we are trying to construct a tx with Plutus script in the cli and get it signed by nami wallet / Cardano-Serialization-Lib but it's just not compatible hopefully this gets resolved

[AngelCastilloB]

Same here, I had to perform several hacks and magic tricks (thanks to the serialization lib dev guidance) to make it work. I believe this is really important, the discrepancies between the CLI and the emurgo serialization lib are hindering and slowing down a lot of dApps. Would be awesome to hear from the dev team if they are working on this or at least aware of it :).

[JaredCorduan]

@kieransimkin can you provide the steps to reproduce this? This is what I see:

$ cardano-cli transaction build-raw --tx-in 0000000000000000000000000000000000000000000000000000000000000000#1 --out-file no-wit.txb --fee 0
$ cardano-cli transaction assemble --tx-body-file no-wit.txb --out-file no-wit.tx
Missing: (--witness-file FILE)

So I don't know what you mean by using the cli to create a transaction with no witness set. and similarly for transaction sign.

[kieransimkin]

Producing any transaction via cardano-cli using something like this:
cardano-cli transaction build-raw \ --fee 177293 \ --tx-in 172bafb41de4031be55a5227f0b4e33a55981dee1ebd623cbce7555eb62210cd#0 \ --tx-out addr1q9ry3srf6n4crvtnch432vpz8agfjhst2tl3v9kwklr2x05f7mwd3ll67jr7hs39dmdf4awgtr8ht2cp5cvqxgg2kxhqzuh6ls+1500000+"1000000 dd3a481f3e8feb0190830c4e664de69b1f819af352cb772d29c8831e.KMA" \ --tx-out addr1vx05dzjm3kjqsyz82vfl5r57hpw7axvkqseyeprkxkmfymshnauma+5147966+"0 dd3a481f3e8feb0190830c4e664de69b1f819af352cb772d29c8831e.KMA" \ --out-file rec_matx.raw

Serialization-lib fails to parse the cbor generated from this,.

[JaredCorduan]

Thank you @kieransimkin , now I understand.

The transaction build-raw command does not create a transaction. It creates a transaction body.

Note that you don't need to sign the transaction body, you need to sign the transaction ID, which is the hash of the body. You can get this from the cli with:

 cardano-cli transaction txid --tx-body-file <body_file>

Here's a bit more context, which you may or may not be interested in. I believe (but don't know for sure, I've not done any work myself on the cli) that the cli uses a different format for serializing the transaction body than is specified in the ledger, in order to better match how it constructs transactions. The transaction txid command, however, does use the ledger serialization in order to construct the correct ID. Moreover, the cli does put the transaction body in the ledger form when serializing a transaction.

I'm sorry this has caused so much confusion. I will make the relevant folks at IOHK aware of it.

[kieransimkin]

Thank you @kieransimkin , now I understand.

The transaction build-raw command does not create a transaction. It creates a transaction body.

Thanks - this is new information to me, and very helpful, thank you. I think it would be useful to the community if someone who knows what they're doing put up some kind of guide on how to get transactions generated by cardano-cli to be correctly parsed by Serialization-lib/Nami - whether that be Emurgo, IOHK, or Nami developers - someone please help us out!

[pyropy]

Thank you @kieransimkin , now I understand.
The transaction build-raw command does not create a transaction. It creates a transaction body.

Thanks - this is new information to me, and very helpful, thank you. I think it would be useful to the community if someone who knows what they're doing put up some kind of guide on how to get transactions generated by cardano-cli to be correctly parsed by Serialization-lib/Nami - whether that be Emurgo, IOHK, or Nami developers - someone please help us out!

Hi, I've posted solution to your issue over at cardano-serialization lib. In order to load transaction generated by cardano-cli into cardano-serialization-lib you should sign your transaction using some dummy signing keys. That way transaction witness-set should be created. Later on you just override that "dummy" transaction witness-set with real one and sign the transaction.

[rooooooooob]

I believe (but don't know for sure, I've not done any work myself on the cli) that the cli uses a different format for serializing the transaction body than is specified in the ledger, in order to better match how it constructs transactions. The transaction txid command, however, does use the ledger serialization in order to construct the correct ID. Moreover, the cli does put the transaction body in the ledger form when serializing a transaction.

@JaredCorduan It looks like this difference applies going back into the CLI too when it comes to witnesses. See input-output-hk/nami#85 - people are reporting that the witness format the CLI takes is different from the binary spec as well. Using @pyropy 's workaround @jinglescode posted some CBOR (82008258209b8e0e4205180b4a2ac3511b39435e7e472c6cd817c1f05aaa7545c4b816601a584036b135996644821b84ccd31ad0b8ee07ef9b16eca8046aec96e8e756c0fcef293aeb0cd78866823239de10f98e5f9ddf223b814aaf2140183777d4fc742a3009) that they have confirmed worked to allow it to be accepted by the cli which I ran through a CBOR decoder and it is almost identical to the alonzo.cddl definition but with an array tag instead of a map tag - granted this is a vkey only witness so I'm not sure if the format similarity holds true for other witness types. It's still using the general key, value format as if it were a CBOR map as well. The value is as if it were an array though (2 not 1) since the keys are just any other element since it's an array.

[cffls]

Thanks for reporting this issue! I also saw this problem when trying to decode an unsigned transaction generated from cardano-cli. It seems like the bug is gone after the transaction is signed by cardano-cli. I pasted more evidence below. Hope it helps!

Unsigned transaction

Create an unsigned transaction

$ cardano-cli transaction build --tx-in 732bfd67e66be8e8288349fcaaa2294973ef6271cc189a239bb431275401b8e5#0 --tx-out addr_test1vrm9x2zsux7va6w892g38tvchnzahvcd9tykqf3ygnmwtaqyfg52x+100000000000 --testnet-magic 42 --change-address addr_test1vrm9x2zsux7va6w892g38tvchnzahvcd9tykqf3ygnmwtaqyfg52x --out-file tx0 --alonzo-era

$ cat tx0
{
    "type": "TxBodyAlonzo",
    "description": "",
    "cborHex": "86a50081825820732bfd67e66be8e8288349fcaaa2294973ef6271cc189a239bb431275401b8e5000d80018282581d60f6532850e1bccee9c72a9113ad98bcc5dbb30d2ac960262444f6e5f41b000000ba43b4b7f782581d60f6532850e1bccee9c72a9113ad98bcc5dbb30d2ac960262444f6e5f41b000000174876e800021a000288090e809fff8080f5f6"
}

Decode cbor hex

$ echo 86a50081825820732bfd67e66be8e8288349fcaaa2294973ef6271cc189a239bb431275401b8e5000d80018282581d60f6532850e1bccee9c72a9113ad98bcc5dbb30d2ac960262444f6e5f41b000000ba43b4b7f782581d60f6532850e1bccee9c72a9113ad98bcc5dbb30d2ac960262444f6e5f41b000000174876e800021a000288090e809fff8080f5f6 | xxd -r -p | base64 | python -m cbor2.tool -d | jq
[
  {
    "0": [
      [
        "s+\\xfdg\\xe6k\\xe8\\xe8(\\x83I\\xfc\\xaa\\xa2)Is\\xefbq\\xcc\u0018\\x9a#\\x9b\\xb41'T\u0001\\xb8\\xe5",
        0
      ]
    ],
    "13": [],
    "1": [
      [
        "`\\xf6S(P\\xe1\\xbc\\xce\\xe9\\xc7*\\x91\u0013\\xad\\x98\\xbc\\xc5۳\r*\\xc9`&$D\\xf6\\xe5\\xf4",
        799999834103
      ],
      [
        "`\\xf6S(P\\xe1\\xbc\\xce\\xe9\\xc7*\\x91\u0013\\xad\\x98\\xbc\\xc5۳\r*\\xc9`&$D\\xf6\\xe5\\xf4",
        100000000000
      ]
    ],
    "2": 165897,
    "14": []
  },
  [],  # ------\
  [],  # -------> These three arrays are problematic. They should've been an empty witness set ({}).
  [],  # ------/
  true,
  null
]

Signed transaction

Problem is gone after I sign the transaction.

Sign the transaction created above

$ cardano-cli transaction sign --tx-body-file tx0 --signing-key-file code/configs/local/shelley/utxo-keys/utxo1.skey --testnet-magic 42 --out-file tx.signed
$ cat tx.signed
{
    "type": "Tx AlonzoEra",
    "description": "",
    "cborHex": "84a50081825820732bfd67e66be8e8288349fcaaa2294973ef6271cc189a239bb431275401b8e5000d80018282581d60f6532850e1bccee9c72a9113ad98bcc5dbb30d2ac960262444f6e5f41b000000ba43b4b7f782581d60f6532850e1bccee9c72a9113ad98bcc5dbb30d2ac960262444f6e5f41b000000174876e800021a000288090e80a100818258208be8339e9f3addfa6810d59e2f072f85e64d4c024c087e0d24f8317c6544f62f5840e4445d095478a3e2ce3d8a81e482404bb316296694b13585b1c99e3d369548ed9927632ca798c000217d62bee24be7637fad9156b27721ed256d792dab8edf01f5f6"
}

Decode cbor hex

echo 84a50081825820732bfd67e66be8e8288349fcaaa2294973ef6271cc189a239bb431275401b8e5000d80018282581d60f6532850e1bccee9c72a9113ad98bcc5dbb30d2ac960262444f6e5f41b000000ba43b4b7f782581d60f6532850e1bccee9c72a9113ad98bcc5dbb30d2ac960262444f6e5f41b000000174876e800021a000288090e80a100818258208be8339e9f3addfa6810d59e2f072f85e64d4c024c087e0d24f8317c6544f62f5840e4445d095478a3e2ce3d8a81e482404bb316296694b13585b1c99e3d369548ed9927632ca798c000217d62bee24be7637fad9156b27721ed256d792dab8edf01f5f6 | xxd -r -p | base64 | python -m cbor2.tool -d | jq
[
  {
    "0": [
      [
        "s+\\xfdg\\xe6k\\xe8\\xe8(\\x83I\\xfc\\xaa\\xa2)Is\\xefbq\\xcc\u0018\\x9a#\\x9b\\xb41'T\u0001\\xb8\\xe5",
        0
      ]
    ],
    "13": [],
    "1": [
      [
        "`\\xf6S(P\\xe1\\xbc\\xce\\xe9\\xc7*\\x91\u0013\\xad\\x98\\xbc\\xc5۳\r*\\xc9`&$D\\xf6\\xe5\\xf4",
        799999834103
      ],
      [
        "`\\xf6S(P\\xe1\\xbc\\xce\\xe9\\xc7*\\x91\u0013\\xad\\x98\\xbc\\xc5۳\r*\\xc9`&$D\\xf6\\xe5\\xf4",
        100000000000
      ]
    ],
    "2": 165897,
    "14": []
  },
  {
    "0": [
      [
        "\\x8b\\xe83\\x9e\\x9f:\\xdd\\xfah\u0010՞/\u0007/\\x85\\xe6ML\u0002L\b~\r$\\xf81|eD\\xf6/",
        "\\xe4D]\tTx\\xa3\\xe2\\xce=\\x8a\\x81\\xe4\\x82@K\\xb3\u0016)f\\x94\\xb15\\x85\\xb1ɞ=6\\x95H\\xed\\x99'c,\\xa7\\x98\\xc0\u0000!}b\\xbe\\xe2K\\xe7c\u007f\\xad\\x91V\\xb2w!\\xed%my-\\xab\\x8e\\xdf\u0001"
      ]
    ]
  },  # --------> Witness set is created correctly.
  true,
  null
]

[JaredCorduan]

@cffls notice that cardano-cli transaction build does not create a transaction, but rather a transaction body. It is the same situation that I described above for build-raw: #3370 (comment)

[kieransimkin]

There seems to be a lot of confusion around this - I wonder if anyone could actually post a guide - I think we're all fundamentally trying to do the same thing - make transactions that we're producing server-side somehow work with serialization-lib in the browser. Seems there are several different hurdles people are stumbling on here and a guide would really be appreciated, still not quite at the level where I understand it well enough to write that guide myself yet I'm afraid.

[cffls]

@cffls notice that cardano-cli transaction build does not create a transaction, but rather a transaction body. It is the same situation that I described above for build-raw: #3370 (comment)

Thanks Jared for the response. I don't think cardano-cli transaction build create a pure transaction body either. From my post above, you can see that its output is not a map, but an array that includes other fields, such as is_transaction_valid and auxiliary_data.

The confusion probably comes from the some developers' assumption that cardano-cli transaction build will create a valid and complete transaction as defined in alonzo cddl [1], which is not the case. If the command is not intended to do so, it should state very clearly in its description about what exactly it produces and the format of it. At the moment, it is producing neither a complete transaction [1] nor a transaction body [2]. I believe either scenario would work, although my preference is to have this cli produce a complete transaction so that we don't need to wrap the transaction in a transaction after. The bottom line is that we should have a clear definition for the output of this command and the command should produce what it claims to produce. As regards to cardano-cli transaction txid --tx-body-file, it will definitely be useful in some cases, but probably not the case where wallet connector API[3] is used, because signTx only accept a transaction cbor instead of a transaction ID as input.

@kieransimkin A workaround solution for the use case you described (creating unsigned transactions from server and have user's wallet to sign it using the signTx API from wallet connector) is to deserialize the cbor output from cardano-cli transaction build, take the transaction body, place the body to a new transaction with a clean witness set and two other necessary fields , and serialize the transaction into a new cbor, which is to be sent to client's wallet to sign.

Nevertheless, imho, the long-term solution is for IOG to fix the behavior of cardano-cli transaction build.

[1] Transaction definition: https://github.com/input-output-hk/cardano-ledger/blob/master/eras/alonzo/test-suite/cddl-files/alonzo.cddl#L13-L18
[2] Transaction body definition: https://github.com/input-output-hk/cardano-ledger/blob/master/eras/alonzo/test-suite/cddl-files/alonzo.cddl#L50-L65
[3] SignTx: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#apisigntxtx-cbortransaction-partialsign-bool--false-promisecbortransaction_witness_set

[kieransimkin]

Just as a general tip to IOHK and IOG in general - We need documentation for this stuff! How am I supposed to know that cardano-cli generates some kind of half-baked transaction? It doesn't say that anywhere, or at least not in any of the documentation that I scoured looking for answers on this.
Why would Cardano-cli build a half-baked transaction anyway? I think I understand the issue, but not the cause of it - cardano-cli, in the way that most people are using it, generates some kind of transaction that is not compatible with other libraries. I don't know anything of the ledger spec, I'm a PHP and Javascript programmer trying to integrate here, I shouldn't have to understand the intricacies of this - and Cardano-cli should not generate transactions that don't load into Serialization-lib - I do not care about the technical specifics of why this is, it's just wrong and needs to get fixed.

We've now solved this problem at our end, but it's frustrating for me to see other people suffering the same problem, and nothing done about it. IOHK/IOG/Emurgo (whichever part of this multiheaded beast wants to take responsibility for this mess) needs to write some docs, and fix cardano-cli - because right now you're creating a lot of very frustrated programmers out there - programmers who will quite happily drop Cardano and go to a chain that actually bothers to write documentation and fix hurdles that are tripping up 90% of the developers trying to integrate them.

I would really like to see something from IOG/IOHK/Emurgo in the way of documentation - why is the Cardano documentation so bad? Every programmer I work with says it - I understand Cardano is a work-in-progress, but so are most software projects, and most have better documentation. If a problem is tripping up most of the people who are integrating with your system, fix it and document it!

[kieransimkin]

Thanks for all the information @cffls - hopefully this will save someone else a lot of time when they're solving this problem. I would really like to see something official in the way of a fix for this - to be honest because my confidence in Cardano has gone from very high to almost zero, thanks to the issues we've had with this, and the lack of communication and general uselessness of the people who have created this mess in the first place.

I can tell you there are a lot of programmers in the community right now who really need to have their faith restored in Cardano, because it's taken quite a battering over the last few months - with the announcement of smart contracts before PAB was ready (PR disaster for Cardano), the nightmares we've had with integrations, and the general uselessness of IOHK, IOG and Emurgo. And to top it all off, turns out Emurgo have been quietly setting up in competition with us! Not good - makes me want to chuck out our Cardano integration, even though it's now working, and replace it with a Solana integration (and that's saying something!) I'm really hoping we see something of substance out of Cardano soon rather than just continued hot air from Charles.

I apologise if my messages come across as irritated - I don't mean any negativity towards any particular person - it's IOHK/IOG/Emurgo all together here that I'm annoyed with. I'm just hoping one of them might listen to the community for once rather than hiding in ivory towers.

[JaredCorduan]

you are correct @cffls , cardano-cli transaction build does not create a transaction body that conforms to the ledger CDDL, but rather its own intermediate form. And I agree completely that this adds unnecessary confusion and should be changed to conform. In hindsight, it's clear what the right thing is to do here, but previously I think no one foresaw this mixing and matching of libraries. I'll escalate this issue again, now that the holidays are ended this is a good time to get a prioritization on it.

I am very sorry that you are frustrated @kieransimkin , all I can say is that the cardano node team is doing our best. We have written a ton of documentation, but there is still much more to write. And indeed there are still rough edges around the Alonzo release.

[kieransimkin]

Thanks @JaredCorduan - I appreciate you're doing your best and am very thankful that you've recognised the problem and are now going to take steps to rectify it.

I feel like I should point out - this seems to be a common theme in Cardano - not foreseeing things which, to anyone with a body of real-world development experience would see these things a mile off. I am guessing this is due to Cardano's academic background? Academics simply don't have real world development experience.

I'm not sure whether there is an internal tension between the experienced real world developers and the academics, but I can only assume there are either no programmers with any depth of real world experience within IOHK, or those programmers exist but their voice isn't heard over the louder voices of academic purity. I'm not sure if this is a correct assessment of the situation or not, but it is my guess.

This is very concerning to me, as I have bet the entire future of my company on Cardano - I am relying on people at IOHK to take a pragmatic approach and have a bit of real-world foresight - to not be making really stupid mistakes like this. And I'm sorry but that's what this is - to a developer highly experienced in API integrations - it's almost unfathomable that these kinds of mistakes would happen.

Similarly - announcing SCs without any of the infrastructure around it to make them work - utter stupidity. Whoever is making these decisions needs to be fired.

[JaredCorduan]

For what it is worth, I am proud of the engineers at IO, it's a harmonious blend of academics and real world developers (and many academics turned engineers with much experience). The intermediate serialized data produced by build and build-raw is actually very helpful fol shielding users from details about the protocol that they do not need to know about, such as the redeemer pointers and other book keeping which exists as optimizations for the protocol. We now see how folks are using the CLI, in ways that we didn't predict, and we are going to do our best to clear up the confusion.

[cffls]

@JaredCorduan Thank you for confirming the issue! Looking forwards to a fix in the upcoming releases.

@kieransimkin I really appreciate that you found this issue, which saved me a good amount of time. Your frustration is totally understandable. However, I have to say that IOG definitely has many great engineers who are building high quality softwares. For example, the stableness of cardano-node (which can run weeks without any interruption) has impressed me a lot. The wallet web bridge (CIP-0030) was proposed long after the existence of cardano-cli, so it is understandable that IOG didn't expect the output of cardano-cli transaction build to be directly used by softwares other than itself. Needless to say, my confidence in Cardano has never changed. The more I dig into Cardano's design, the more I find the beauty and simplicity of it. Let's keep our confidence and continue building on Cardano!

[kieransimkin]

For what it is worth, I am proud of the engineers at IO, it's a harmonious blend of academics and real world developers (and many academics turned engineers with much experience). The intermediate serialized data produced by build and build-raw is actually very helpful fol shielding users from details about the protocol that they do not need to know about, such as the redeemer pointers and other book keeping which exists as optimizations for the protocol. We now see how folks are using the CLI, in ways that we didn't predict, and we are going to do our best to clear up the confusion.

I agree that what has been built so far in Cardano is something to be proud of, but I really think you need to take your heads out of the sand. There are serious problems with the decision-making and management structure in IOHK and Emurgo. It's clear for everyone to see, and pretending like everything is fine will do nobody any good. There is a reason Cardano is falling down the league tables, even though progress seems to be quite good.

Acting like nobody could ever have foreseen that people would use cardano-cli and serialization-lib together just doesn't wash with me - they are the two major ways of generating and parsing transactions on Cardano - what made you think people wouldn't want to use them together?

I imagine this disconnect has something to do with Serialization-lib being maintained by Emurgo, and Cardano-cli being maintained by IOHK. It's a mess.

Rather than patting each other on the back and pretending like everything is fine, I want people at IOHK to start asking questions - "how could we have missed this?"

You released smart contracts before they were ready - knowing everyone was going to want to start using them - it would not have taken much foresight at all to think through the main process people are going to be integrating. The main way people were generating transactions is with cardano-cli in the way I've specified - there's a reason this is the main way people were creating transactions - it was pretty much the only way way detailed in any of the documentation. Did nobody at IOHK really think this through?

This is why I keep making the comment about ivory towers - it feels like nobody at IOHK or Emurgo has actually placed themselves in the shoes of a person who might be using their software. Or indeed sought and responded to feedback from those people.

Cardano is not fine - it's bleeding heavily - stop pretending like everything is okay!

[NKT00]

@kieransimkin Ok, calm down. My reading of this is that you didn't sign the transaction, and so it didn't work. A simple mistake, hardly a devastating indictment of an entire blockchain ecosystem - but recognize that developing for any new platform has its frustrations.
Your project is an NFT marketplace. If you want to contact some of those successful projects, you could join the IOHK Discord and talk to them directly, perhaps, or some of the Discords of other already launched NFT projects. I can connect you with some if you'd like. The other, easy, option for you is to use a service like Blockfrost.io, who allow API access to the Cardano system through their existing integrations.

[kieransimkin]

Downplaying problems and sweeping them under the carpet again. Okay.

[Jimbo4350]

The plan is to make all relevant outputs from cardano-cli comply to the ledger's CDDL spec. See #3505.

[ghost]

Hello, I am building a tx body using cardano-cli build-raw. When I send the cbor of the tx body to cardano-serialization lib to buiild a TrasnactionBody from TransactionBody.from_byte(Buffer.from(cborHex,'hex')) I get the error that cbor is array but expected input is map. Can someone please assist on this issue?

[Jimbo4350]

@Fourzin which version of cardano-cli are you using?

[ghost]

Hi @Jimbo4350, I am using 1.35.3 version. After reading several conversations, I used the --cddl-format tag that output a tx compatible with cardano-sirialization lib (not tx body but rather tx, which is fine). I am now able to reconstruct the transaction on the web browser side. My current issue is that after successfully signing and adding the wallet as witness I get an error while submitting the tx with the error "MissingScriptWitnessesUTXOW".

I already signed the transaction with policy.skey in the cli side before sending the partially signed tx to web-browser.

[Jimbo4350]

@Fourzin please open a new issue and also include the commands you used to construct the tx

[ghost]

Ok I will

[while0x1]

For any weary traveler that stumbles upon this thread and wants to try sign cardano-cli transactions with a CIP-30 wallet the following worked for me. I used transaction build raw to make a simple transaction sending a utxo back to the wallet with a set fee of 200000 lovelaces in the cli and then copied the CBOR Hex part of the outfile. This requires a CIP-30 wallet connector and pycardano

Procedure:

take cbor from cardano cli remove first byte and last 2 bytes
create a transaction body with the parsed CBOR

restored_tx_body = TransactionBody.from_cbor(<remove first byte and last 2 bytes>)
import into py cardano transaction and set empty witness
tx = Transaction(restored_tx_body, TransactionWitnessSet())
tx.to_cbor()
take cbor from to_cbor and sign with CIP30 wallet
get signed cbor witness hex output from the signTx() call and set witness in pycardano
witness = TransactionWitnessSet.from_cbor()
import witness into transaction
tx.transaction_witness_set = witness
export cbor for tx submission
tx.to_cbor
submitTx() in your cip30 Wallet

[nielstron]

@while0x1 There is now the option --cddl-format (soon to be deprecated again thankfully and ending this madness) that gives you just the output you need to be compatible with the specification