BUG - node is not validating UTXO integrity with input token combined with mints

[ashisherc]

A transaction (linked below) on preprod testnet which has below spec,

• input utxo has the token of amount 2 (asset - 414c414c415f54455354)
• output utxo as well has the token of amount 2 (asset - 414c414c415f54455354)
• the tx has a mint of this same asset for amount of 1

The node should be rejecting this tx due to invalid utxo integrity, but instead its accepted and the mint amount is ignored.

the tx = https://preprod.cardanoscan.io/transaction/3f79ac84ce62fb0223176905c757594130177c21963ab1964aa5d4def04a861e?tab=utxo

the block cbor -

820685828a1a0018ba521a02ae24895820413ca2266bac4f438bb66be88bc805ca5d1f4d2a8c3bdeb583c42df7474e14b958200339649fecc4224156494435a46d783d72c8b47fe54e411e6b8fdadda3a7585058203997f8cde4ebadc8993fb0e73c88a7058ec089a6311cc1f930388b9114fc3c99825840180f8b92442933ddb1d6e7a51c2e446fec230c72ff2924df1211cd698212534b488c2b1af6d12109fd2880aa43bbdd92cd0c12f08e50826abb80de13d44b075d5850da506b142cc8d33ae6d2aecfdb327622e9721e49417679f1f05f5229a0924577b80bb0b457fd99fbabd117e758bb49edf17a9a0a52b3a40b923e0faa369e687125787b70361442be3d7b91cebb53da0c19093c58200e3d4834a4dd7a556937b6c1b36a9d766cfff56b9ca28431fe4c7271008fa473845820d35f6405c9d73869b4a9ee42ac578af5d32faa1d79b4013bc620b97a61a8b7da0419014358405c6face300da458ca9453363480a961522daa402e852ba808f2ca9360ffe81e16bc4a8619e0872aeb2b6108b0809c6a0c7b3333162a0c33ffcbde8db6dad440f8208005901c0db84609ce526a38235eea695e2ed42aa2dafc739b23d395edc8e65c33553f987386182dc2a02d8a098e0e688ed9361c036704d16781489e6adca39989b436a035f17db62b490762330be236cf92e5a1bf20a9b671d062b4b38f2581498cd75fbfc4f24e21239468edbea69397a03ce91c1682c08975fc92a4873370722d6fe50876ffb1bf5c2b541cee23ac6e716788630c00d94335589dfd6161efaaa67e56dbe773acbe8c8c8e63f3ad4490342670aac252efed07b51fd082d80c78c4acf07bcc60377ae9ec07b705131841c99e5eb297355b9196d9b63aa1737dd9fdbf7a9282251a6f2e8e157aa141640fd347e18194788e13496abe4b7b2339bdad4ce5c12c25effc103e9ea2b91adf81ef9b6efd23dfe1a86f9b8d594ec536c277876365cd43984ac6ebb89df693036fc01b70cec8f3d64ca49577dc924ab08c71ef3869916e8e934b81b95c427a9d04733707887064620f05869a556d043658324654684d6e8a3a439b5e50a9cac1684ca857fe73cc12fb9ab5ac91a4b12345152344cb5edf6d226a581bb29fea7947ee7b5f1639b2a3bd5032ba2a15308c10d3d3fd75516f7b3f3ed4e24a1c9985c934984cbf867f1c3787accd5034ffec5b26f3abf83aa008282582055ba023aaccefe6888628a8513805ddad2a65f8278ca5c3397a80da6c7890b66018258208d9181649b3671475686851153eadbb8c0b90103d0c10c2ac6a9b1973d4abf49000d818258207aa9cd4999a21c3951de9e330e0ce1fba5943d79ef5bfd90628c2d41e982becd001281825820c59678b6892ba0fbeeaaec22d4cbde17026ff614ed47cea02c47752e5853ebc8010182a200581d600a11b0c7e25dc5d9c63171bdf39d9741b901dc903e12b4e162348e07011a018d55b0a2005839007ea04a6b4942fc0db5f81a86847d2545c3810717ca95f546901cd08cfffa1d082a6132fd1789d48fd348fae9e88d5521c20fb8e1045b0048011a001e848010a200581d600a11b0c7e25dc5d9c63171bdf39d9741b901dc903e12b4e162348e07011a0054cc87111a000a6361021a0006eceb031a02b574ff081a02ae246b0b58204e15e4b830f4f5f029a4779f51735b5dd8462c23a85319166ada33c56ea2ab5aa600818258201d3ae3ffec2d9228c7d5bb9870f5cff032d0f31c83c22c4bd7c5e3ffead4470c0001818258390079467c69a9ac66280174d09d62575ba955748b21dec3b483a9469a65cc339a35f9e0fe039cf510c761d4dd29040c48e9657fdac7e9c01d94821b0000000253e00ccca1581cf923673e7bc027eba929a9086b7b04a126a18ef524b41db6fb014a26a24a414c414c415f54455354024c4741474147415f544553543202021a0002c20e09a2581cf923673e7bc027eba929a9086b7b04a126a18ef524b41db6fb014a26a14a414c414c415f5445535401581cf923673e7bc027eba929a9086b7b04a126a18ef524b41db6fb014a26a14c4741474147415f5445535432010b5820e4af6dc836dada8e84d698b26252f8586f4261ddc6090fc22eac4a059bfe6b040d8382582078869651d619a1832d90b7c843f6d674707fc4c1c2a24e205145656aba7533f600825820c111c9d57fb9ee06f54f0f8bc035f9762db24eada643509afbdbbae98b3ae8f800825820ceff84520384d2f4cdf2017bab6b86a7b46b81ef8e40c3d4f08b699a8a27bade00ab00838258201388fc6611c1aea7ddb4071ce03ee041c7ae2a3b809f730c99ea5d737cb9836b03825820a4d5f23d70af6e494237da29ebd3d0c13f8fde2c3c3b169980a4b63417753a7700825820fd12b648ce816a3aee8f0f0235303958b57bccf3929c88b1f99d6605f1c648ca020183a300581d70f5542fa9d9c61b4dbccd71654cc5a72a9fddc9d563f503682e772ec901821a001e8480a1581c5e4a2431a465a00dc5d8181aaff63959bb235d97013e7acb50b55bc4a1484e6f64654665656401028201d818583cd87a9fd8799f581c4ad1571e7df63d4d6c49240c8372eb639f57c0ef669338c0d752f29bd8799fd8799f1a0025ebd11b0000018bf6a73cbdffffffff82581d604ad1571e7df63d4d6c49240c8372eb639f57c0ef669338c0d752f29b1a0089544082581d604ad1571e7df63d4d6c49240c8372eb639f57c0ef669338c0d752f29b1a005ed7c4021a00044e78031a02ae24e3081a02ae246b0b58205f658fa6994cd9157a48835760a4421da6fec59400f666b343e114283f454eea0d81825820a4d5f23d70af6e494237da29ebd3d0c13f8fde2c3c3b169980a4b63417753a77020e81581c4ad1571e7df63d4d6c49240c8372eb639f57c0ef669338c0d752f29b1082581d604ad1571e7df63d4d6c49240c8372eb639f57c0ef669338c0d752f29b1a004df682111a00370c3f12818258204b61acedca6426ec989ef78a85ed97a8b4ffd47d9c40d4155e453d7e6b25ae580083a30081825820669ed15b1bc5e97ec45af8951e9cbcbd33a3b5878943704d054a1a3ec46be28258407861d1a46731116eb7b140c1a9efbd19e2727f472d4e3503ff96d3125fcc3e11982320322e99fafb61d7016443ac815d909e573bd721efbbeba0cd7a78a11f020481d8799fd8799f40ffd8799fa1d8799fd8799fd87980d8799fd8799f581c7ea04a6b4942fc0db5f81a86847d2545c3810717ca95f546901cd08cffd8799fd8799fd8799f581cfffa1d082a6132fd1789d48fd348fae9e88d5521c20fb8e1045b0048ffffffffffd8799f4040ffff1a001e8480a0a000ffd87c9f9fd8799fd87a9fd8799f5545766572797468696e6720697320616c7269676874d8799fd87980d8799fd8799f581c7ea04a6b4942fc0db5f81a86847d2545c3810717ca95f546901cd08cffd8799fd8799fd8799f581cfffa1d082a6132fd1789d48fd348fae9e88d5521c20fb8e1045b0048ffffffffffff9fd8799f0000ffffffd87980ffd8799fd87a9fd8799f4e5265706f72742070726f626c656dd8799fd87980d8799fd8799f581c7ea04a6b4942fc0db5f81a86847d2545c3810717ca95f546901cd08cffd8799fd8799fd8799f581cfffa1d082a6132fd1789d48fd348fae9e88d5521c20fb8e1045b0048ffffffffffff9fd8799f0101ffffffd87980ffd8799fd87a9fd8799f5243686f696365206265747765656e20312d33d8799fd87980d8799fd8799f581c7ea04a6b4942fc0db5f81a86847d2545c3810717ca95f546901cd08cffd8799fd8799fd8799f581cfffa1d082a6132fd1789d48fd348fae9e88d5521c20fb8e1045b0048ffffffffffff9fd8799f0103ffffffd87980ffd8799fd87a9fd8799f5243686f696365206265747765656e20312d34d8799fd87980d8799fd8799f581c7ea04a6b4942fc0db5f81a86847d2545c3810717ca95f546901cd08cffd8799fd8799fd8799f581cfffa1d082a6132fd1789d48fd348fae9e88d5521c20fb8e1045b0048ffffffffffff9fd8799f0104ffffffd87980ffff1b0000018bf65a9496d87980ffff058184000080821a002f80a61a339742d1a30081825820489ef28ea97f719ee7768645fc74b811c271e5d7ef06c2310854db30158e945d584023dcbaf18dff2ed33a436cbc9036c70deacb573d810df73c41c72c0ebc6183f3d5b44d24d9689db9d3254f3a6720f71175bc1ac32607758276c2cf64ca7dbb0403815251010000322253330034a229309b2b2b9a0105828401000182190bb91a000c79f88401000282190bb91a000c79f8a200818258204b5d869e21e1d1d6f84fdc1e5811eda837ca9fdf2068c69255cd43f62e2711f25840888846f463da49f6f4fbbe4fbfc056901521852d203f1b8bf1a54af2c4efd1cf292ef983a8dbfd3b9266194025028ea59ce34453ddc6a4e0861ddc5db6ee01050581840001d87980821a0012c2f41a15f4bff0a080

the tx cbor in question -

a600818258201d3ae3ffec2d9228c7d5bb9870f5cff032d0f31c83c22c4bd7c5e3ffead4470c0001818258390079467c69a9ac66280174d09d62575ba955748b21dec3b483a9469a65cc339a35f9e0fe039cf510c761d4dd29040c48e9657fdac7e9c01d94821b0000000253e00ccca1581cf923673e7bc027eba929a9086b7b04a126a18ef524b41db6fb014a26a24a414c414c415f54455354024c4741474147415f544553543202021a0002c20e09a2581cf923673e7bc027eba929a9086b7b04a126a18ef524b41db6fb014a26a14a414c414c415f5445535401581cf923673e7bc027eba929a9086b7b04a126a18ef524b41db6fb014a26a14c4741474147415f5445535432010b5820e4af6dc836dada8e84d698b26252f8586f4261ddc6090fc22eac4a059bfe6b040d8382582078869651d619a1832d90b7c843f6d674707fc4c1c2a24e205145656aba7533f600825820c111c9d57fb9ee06f54f0f8bc035f9762db24eada643509afbdbbae98b3ae8f800825820ceff84520384d2f4cdf2017bab6b86a7b46b81ef8e40c3d4f08b699a8a27bade00

[lehins]

the tx has a mint of this same asset for amount of 1

@ashisherc Are you sure it is the same asset that is being minted?

There are two assets in the outputs:

1. 414C414C415F54455354 (ALALA_TEST): 2
2. 4741474147415F5445535432 (GAGAGA_TEST2): 2

Minted is one asset:

1. 4741474147415F5445535432 (GAGAGA_TEST2): 1

Then we have two assets in the inputs:

1. 414C414C415F54455354 (ALALA_TEST): 2
2. 4741474147415F5445535432 (GAGAGA_TEST2): 1

It all balances out.

[lehins]

After further investigation looks like there is a problem with serialization of this transaction. Mint field is malformed. It specifies two maps of element 1, instead of a map with two elements. In Babbage era we do the same thing as cbor.me does, we just ignore the second entry in the mint field map, while cardanoscan apparently wrongfully decodes the second entry ignoring the specified number of elements.

So, this issue of accepting malformed CBOR like that was fixed in Conway and you will get a deserialization error:

Final number of elements: 1 does not match the total count that was decoded: 2

when submitting such transaction.

Closing as already fixed, since we can't change this behavior for Babbage.

[lehins]

FYI, this is the transaction in Babbage, see there is only one entry in the mint field:

TxBodyConstr
  BabbageTxBodyRaw
    { btbrSpendInputs =
        fromList
          [ TxIn
              (TxId
                 { unTxId =
                     SafeHash
                       "1d3ae3ffec2d9228c7d5bb9870f5cff032d0f31c83c22c4bd7c5e3ffead4470c"
                 })
              (TxIx 0)
          ]
    , btbrCollateralInputs =
        fromList
          [ TxIn
              (TxId
                 { unTxId =
                     SafeHash
                       "78869651d619a1832d90b7c843f6d674707fc4c1c2a24e205145656aba7533f6"
                 })
              (TxIx 0)
          , TxIn
              (TxId
                 { unTxId =
                     SafeHash
                       "c111c9d57fb9ee06f54f0f8bc035f9762db24eada643509afbdbbae98b3ae8f8"
                 })
              (TxIx 0)
          , TxIn
              (TxId
                 { unTxId =
                     SafeHash
                       "ceff84520384d2f4cdf2017bab6b86a7b46b81ef8e40c3d4f08b699a8a27bade"
                 })
              (TxIx 0)
          ]
    , btbrReferenceInputs = fromList []
    , btbrOutputs =
        StrictSeq
          { fromStrict =
              fromList
                [ Sized
                    { sizedValue =
                        ( Addr
                            Testnet
                            (KeyHashObj
                               (KeyHash
                                  "79467c69a9ac66280174d09d62575ba955748b21dec3b483a9469a65"))
                            (StakeRefBase
                               (KeyHashObj
                                  (KeyHash
                                     "cc339a35f9e0fe039cf510c761d4dd29040c48e9657fdac7e9c01d94")))
                        , MaryValue
                            (Coin 9997126860)
                            (MultiAsset
                               (fromList
                                  [ ( PolicyID
                                        { policyID =
                                            ScriptHash
                                              "f923673e7bc027eba929a9086b7b04a126a18ef524b41db6fb014a26"
                                        }
                                    , fromList
                                        [ ("414c414c415f54455354", 2)
                                        , ("4741474147415f5445535432", 2)
                                        ])
                                  ]))
                        , NoDatum
                        , SNothing)
                    , sizedSize = 128
                    }
                ]
          }
    , btbrCollateralReturn = SNothing
    , btbrTotalCollateral = SNothing
    , btbrCerts = StrictSeq {fromStrict = fromList []}
    , btbrWithdrawals = Withdrawals {unWithdrawals = fromList []}
    , btbrTxFee = Coin 180750
    , btbrValidityInterval =
        ValidityInterval {invalidBefore = SNothing, invalidHereafter = SNothing}
    , btbrUpdate = SNothing
    , btbrReqSignerHashes = fromList []
    , btbrMint =
        MultiAsset
          (fromList
             [ ( PolicyID
                   { policyID =
                       ScriptHash
                         "f923673e7bc027eba929a9086b7b04a126a18ef524b41db6fb014a26"
                   }
               , fromList [("4741474147415f5445535432", 1)])
             ])
    , btbrScriptIntegrityHash =
        SJust
          (SafeHash
             "e4af6dc836dada8e84d698b26252f8586f4261ddc6090fc22eac4a059bfe6b04")
    , btbrAuxDataHash = SNothing
    , btbrTxNetworkId = SNothing
    }
  (blake2b_256
     : SafeHash
         "3f79ac84ce62fb0223176905c757594130177c21963ab1964aa5d4def04a861e")

[ashisherc]

@lehins thanks for looking into this, Great to know this is fixed in Conway. Can you please confirm the right way of decoding such a malformed mint? Do we always ignore the second entry or is there some kind of sorting done?

Can you please confirm if this was documented in Babbage spec? if not, do you need me to create an issue to document the same, potentially as a wart?

[ashisherc]

@lehins also it looks like the first entry is ignored and not the second entry, so not sure if its just a simple first/second ignore rule? what happens when there are multiple such entries?