v5 - Wallet - Late locking - pre-generate transaction not working correctly

[MCM-Mike]

Describe the bug
In reference to #530 and #485

I was trying to setup two wallets (hot/cold wallets) and pre-generate slate transactions between them without finalizing them.
As long as I did have funds on the sending wallet it was working , but when I started to generate transactions which where bigger then the remaining funds on my sending wallets the Libwallet Error: not enough funds error triggers

To Reproduce
/grin-wallet -t /tmp/wallet/v5-1 send --late-lock --outfile /tmp/wallet/v5-1/slatepack/1-GRIN-Cold-storage..slatepack --dest grin1tt74pwyywxds403nydk5rjk9tlxvpkf9u9t50u3td69a6dfrrs4qxvwhg3 20

This was more then the sending wallet had in funds.

20201205 15:33:07.225 DEBUG grin_wallet_impls::lifecycle::seed - Using wallet seed file at: /tmp/wallet/v5-1/wallet_data/wallet.seed
No recipient Slatepack address or provided address invalid. No payment proof will be requested.
20201205 15:33:07.874 DEBUG grin_wallet_libwallet::internal::updater - Refreshing wallet outputs
20201205 15:33:07.881 INFO grin_wallet_controller::command - Tx not created: Not enough funds. Required: 20.012500000, Available: 5.000000000
Wallet command failed: LibWallet Error: Not enough funds. Required: 20.012500000, Available: 5.000000000

Expected behavior
Have some kind of an command-line flag to allow this even with not enough funds on the sending wallet.

Desktop (please complete the following information):
[1] HOT-Wallet: https://github.com/mimblewimble/grin-wallet/releases/tag/v5.0.0-beta.2

[2] Cold-Wallet: https://github.com/mimblewimble/grin-wallet/releases/tag/v5.0.0-beta.2

[3] Node: https://github.com/mimblewimble/grin/tree/v5.0.0-beta.2

[4] Linux System 64bit

Additional context
It is a good solution you are not deducting the pre-generated and not yet finalized transaction from the sending wallet.

[antiochp]

If I understand this correctly you want to do some "extreme" form of late locking with outputs to be spent that do not yet exist?
For example a tx that spends 1,000,000 grin regardless of actually having the funds available. With the intent of finalizing (and locking) the outputs when they do exist at some point in the future.

This is interesting. This was not (as far as I know) a use-case that we considered for "late locking". But its not that different to what we currently have.

[MCM-Mike]

At the moment, sending multiple transactions at the same time, without having the late locking implemented , was always possible when using the --change_outputs function to pre-generate change outputs. But the limitation was the funds where blocked on the total amount if finalized or not.

The current late locking, to my understanding, allows us to send multiple transactions successively without having to wait for a output to be spendable. Also the transaction amount, if not finalized is not deducted from the total amount until finalization . This is working perfectly if you have funds on the wallet.

If I understand this correctly you want to do some "extreme" form of late locking with outputs to be spent that do not yet exist?
For example a tx that spends 1,000,000 grin regardless of actually having the funds available. With the intent of finalizing (and locking) the outputs when they do exist at some point in the future.

Correct, the idea is to empower the possibility of having a hot and cold wallet and send any funds from the hot wallet to the cold wallet regardless of its current funds total. These transactions would be pre-generated to archive this and only finalized if needed. This also allows you, to keep one wallet without any internet connection in an offline state (cold wallet) .

[antiochp]

This suggests there might be an existing edge case that we potentially don't have test coverage for.

Say I have 100 grin in my wallet.
I generate a "late locked" transaction spending all 90 grin. I have sufficient funds here.
I then spend 50 grin, leaving <90 grin funds available.
I then attempt to finalize the "late locked" transaction with insufficient funds.

The transaction will clearly fail, just not sure if we check for sufficient funds in a user friendly way during the finalize step.

[MCM-Mike]

Say I have 100 grin in my wallet.
I generate a "late locked" transaction spending all 90 grin. I have sufficient funds here.
I then spend 50 grin, leaving <90 grin funds available.
I then attempt to finalize the "late locked" transaction with insufficient funds.
The transaction will clearly fail, just not sure if we check for sufficient funds in a user friendly way during the finalize step.

Yes this is the correct behavior, as you don't have enough funds. You could after you did send 50 GRINs add another 50 GRINs and the pre-generated late locked transaction would work again.
Not sure about your current test cases.

In your example you are pre-generating late locked transaction within the total amount of your funds. This should be the normal use case of late locked transactions.

But when you try, generating a late locked transaction > (bigger) then the remaining funds on the wallet. you get the error I was giving above.

Use case would be after you would receive sufficient funds, you then can use one of the pre-calculated late locked transaction to send it to your cold wallet.