Open MCM-Mike opened 3 years ago
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.
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) .
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.
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.
Describe the bug In reference to https://github.com/mimblewimble/grin-wallet/pull/530 and https://github.com/mimblewimble/grin-wallet/pull/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 theLibwallet Error: not enough funds
error triggersTo 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.
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.