Cardano-wallet: Major Wallet locking Issue with NativeAssets overflow in UTXOs

[gitmachtl]

Essential Information

Daedalus 3.3.0#16328 Frontend
Public-Testnet

Steps to Reproduce

Wallet-Owner:

• Create a new Wallet in Daedalus/Cardano-Wallet via SeedPhraseMethod
• Sends 10M Ada to fund the Wallet to the first Receive-Address

Now a bad actor starts to come in:

• Sends 18446744073709551614 XCoins to the first Receive-Address
• Sends again 18446744073709551614 XCoins to the first Receive-Address
• Sends again 18446744073709551614 XCoins to the first Receive-Address

Now the wallet looks like this:

Wallet-Owner:

• Sees the 6 additional ADA but yes, they are just there, Wallet-Owner is happy about free ADA
• Wallet-Owner wants to send 8M ADA out of the Wallet
• Transaction fails

Why does it fail? Because cardano-wallet is also using two of the additional UTXOs that the bad actor sent over. It tries to consolidate the Native Assets of course, but the sum of two of the UTXOs generates an overflow. Because the maximum possible value is 18446744073709551614 or 18446744073709551615, doesn't matter.

The Wallet is now locked up.

You can maybe send out smaller pieces with the hope that the auto UTXO picking algo is not using any of the asset UTXOs again.

You also can't get rid of the assets, because first - Daedalus does not support it right now, but second - You will also end up with more than the maximum amount in the transaction and the node will fail.

Resolution

We need a much better UTXO selection algo ASAP! Or even an advanced mode in the wallets to hand-pick the UTXOs you wanna use. If this happens on a cli based account like for SPOs, this is solvable. But a normal User can't solve this. Funds are locked up, or kind of. But imagin the reaction of the Wallet-Owner. Also, restoring the wallet on another Frontend like Yoroi or Adalite results in the same error.

I can provide the DevTeam a SeedPhrase if someone wants to restore the TestWallet i created.

Jira Issue number

ADP-726, ADP-826

[Crypto2099]

I have also independently verified this in my Daedalus Testnet 3.3.0 wallet using a wallet with utxo's with sub-max tokens as well as several max-token utxo's and a few non-token utxo's. The amount that can be sent either to your own wallet or to an external wallet randomly fails depending upon which utxo's Daedalus selects for the tx-in. In a wallet with ~28 Ada total in it, 20 non-tokened and 8 tokened, the first value I was able to send successfully was ~14 Ada, then the maximum I could send decreased to 8 Ada, then 4 Ada, then finally 1 Ada per send operation.

[KtorZ]

@gitmachtl Thanks for reporting this. I was actually discussing this very limitation with the team this morning. The underlying issue is not an overflow, but actually the opposite. The wallet does handle the high token quantity just fine... but does it a bit too much. As a matter of fact, the serialization codecs do expect asset's quantities to fit in a uint64. Yet, in case you have assets with very large quantity (i.e. > 2^64), the wallet may end up creating a change output that is _too large_ and can't be serialized and eventually, fails to be submitted.

There's some remaining work to be done on the creation of change outputs. In the meantime, an immediate work-around is to "manually" send out extra money to yourself, forcing the wallet to create those "small enough" change outputs. This is however not acceptable as a long-term solution.

We're on it :)

---

We need a much better UTXO selection algo ASAP!

Please don't be too harsh on months of efforts :). Remember that we are the first blockchain ever to try to tackle this problem natively. It's something whic has been developed with great care and the UTxO selection algorithm is the result of good engineering. Yet, there are many aspects to it and it spans over multiple components and as always, it's the integration of end components which is the most painful.

[gitmachtl]

Please don't be too harsh on months of efforts :)

I am on your side, thats why i am testing such stuff on the edge cases. We all care much about cardano, so also about possible backlashes from 3rd parties about such issues. Its no problem to sort theses things out on the CLI, but its not possible for the "normal" cardano user using the major wallets. So maybe we need an "expert" mode to make handpicking of input utxos possible in the future. A possible solution is to detect larger --tx-out numbers than 18446744073709551615 and automatically split them into multiple --tx-outs to the same destination address.

[dcoutts]

There's no cause for alarm here. There's no overflows here and no risk to anyone's funds.

Yes the wallet will need a few more tweaks to the coin selection to account for the new things we can do with multi-assets. The wallet team are aware of that. They've been updating the wallet in phases, starting with basic support for multi-asset.

A possible solution is to detect larger --tx-out numbers than 18446744073709551615 and automatically split them into multiple --tx-outs to the same destination address.

Indeed. I'm sure the solution will be along those lines.

[jonathanknowles]

@gitmachtl wrote:

A possible solution is to detect larger --tx-out numbers than 18446744073709551615 and automatically split them into multiple --tx-outs to the same destination address.

@dcoutts wrote:

Indeed. I'm sure the solution will be along those lines.

That is indeed the solution we've opted to go for. (See https://github.com/input-output-hk/cardano-wallet/pull/2536)

When we construct a change output, if we detect that any quantity would exceed the maximum, we partition the output into _n_ outputs whose bundles are approximately equal in size. (We cannot guarantee exact equality, as sometimes a token quantity may not be exactly divisible by the number of parts in which we'd like to divide it.)

In order to determine the number of parts _n_ in which to split a given bundle, we choose the smallest value for _n_ that allows us satisfy the goal of not exceeding the maximum allowable quantity in any given bundle.

[gitmachtl]

The solution is not yet implemented in the Flight Version 4.0.2-FC3#17097 i guess?

[rvl]

Hi @gitmachtl, Daedalus 4.0.2-FC2 is using cardano-wallet v2021-03-04, so it should include the fix for this particular issue.

When it says "An error occurred," the actual error from cardano-wallet is probably a different one to before. The tx may now be rejected for a new reason. @jonathanknowles will have more details.

[piotr-iohk]

Hi @gitmachtl, Can you share what is the error that cardano-wallet throws when you hit "Send"?
Errors should be displayed in Daedalus developer console. To open it click (Ctrl + Alt + i) and go to console tab.

Once you click "Send" the actual error that is coming from cardano-wallet backend should be displayed there.

[gitmachtl]

Can you share what is the error that cardano-wallet throws when you hit "Send"?

It is a Ledger HW-Wallet with Ledger Cardano App 2.2.0.

Here is the console output. Verification on the Ledger is working normal.

(anonymous) @ renderer.js:34
emit @ events.js:210
onMessage @ init.ts:50
renderer.js:34 [2021-03-19T18:16:25.605Z] [daedalus.*testnet*:error:ipcRenderer] {
  "msg": "AdaApi::createExternalTransaction error",
  "data": {
    "error": {
      "code": "malformed_tx_payload",
      "message": "I couldn't verify that the payload has the correct binary format. Therefore I couldn't send it to the node. Please check the format and try again."
    }
  }
}
(anonymous) @ renderer.js:34
emit @ events.js:210
onMessage @ init.ts:50
asyncToGenerator.js:6 Uncaught (in promise) ApiError {isFinalError: false, id: "api.errors.GenericApiError", defaultMessage: "!!!An error occurred.", values: {…}, code: "malformed_tx_payload", …}tempError: (...)clause: (...)forceSet: (...)additionalValues: (...)isFinalError: falseid: "api.errors.GenericApiError"defaultMessage: "!!!An error occurred."values: {code: "malformed_tx_payload", message: "I couldn't verify that the payload has the correct… the node. Please check the format and try again."}code: "malformed_tx_payload"Symbol(mobx did run lazy initializers): trueSymbol(mobx administration): e {target: ApiError, values: Map(4), name: "ApiError@1060078", keysAtom: e, defaultEnhancer: ƒ}get tempError: ƒ ()set tempError: ƒ (t)get clause: ƒ ()set clause: ƒ (t)get forceSet: ƒ ()set forceSet: ƒ (t)get additionalValues: ƒ ()set additionalValues: ƒ (t)__proto__: Object
asyncGeneratorStep @ asyncToGenerator.js:6
_throw @ asyncToGenerator.js:29
Promise.then (async)
asyncGeneratorStep @ asyncToGenerator.js:13
_next @ asyncToGenerator.js:25
(anonymous) @ asyncToGenerator.js:32
(anonymous) @ asyncToGenerator.js:21
(anonymous) @ HardwareWalletsStore.js:271
(anonymous) @ Action.js:35
trigger @ Action.js:35
t @ vendor.dll.js:316
WalletSendConfirmationDialogContainer._this.handleWalletSendFormSubmit @ WalletSendConfirmationDialogContainer.js:35
onSuccess @ WalletSendAssetsConfirmationDialog.js:253
execHook @ vendor.dll.js:36
n @ vendor.dll.js:340
(anonymous) @ vendor.dll.js:340
Promise.then (async)
r @ vendor.dll.js:340
submit @ vendor.dll.js:340
we @ vendor.dll.js:22
r @ vendor.dll.js:22
WalletSendAssetsConfirmationDialog._this.submit @ WalletSendAssetsConfirmationDialog.js:235
u @ vendor.dll.js:332
p @ vendor.dll.js:332
(anonymous) @ vendor.dll.js:332
v @ vendor.dll.js:332
ot @ vendor.dll.js:332
it @ vendor.dll.js:332
ut @ vendor.dll.js:332
pt @ vendor.dll.js:332
R @ vendor.dll.js:332
F @ vendor.dll.js:332
Xt @ vendor.dll.js:332
Jt @ vendor.dll.js:332
t.unstable_runWithPriority @ vendor.dll.js:340
Bi @ vendor.dll.js:332
C @ vendor.dll.js:332
Kt @ vendor.dll.js:332

[piotr-iohk]

@gitmachtl thank you! It seems to be different issue related with HW wallets support. I've managed to reproduce it as well and we will look into it.