Late locking

[jaspervdm]

Adding experimental late locking feature to the wallet. If this option is set during tx creation, no UTXOs will be locked on the wallet. Instead, they will only be locked as late as possible, namely when the transaction is finalized.

This feature is considered experimental. If during finalization we realize that the initial fee is not sufficient to pay for the transaction anymore, we simply return an error. This scenario will probably be rare for regular users, but wallets that have many transactions outstanding simultaneously might encounter this. The solution to this would be to add another kernel that makes up the fee difference. This will be addressed in a future PR.

Thanks to @yeastplume for helping with this new feature.

TODOs:

• Remove the 3*fee and output a nice warning when the final fee does not match the initial fee
• Add CLI flag to enable late locking

[Paouky]

Great!
Do you think it should be set as the default option once these 2 items on the TODO list are crossed?

[antiochp]

Great!
Do you think it should be set as the default option once these 2 items on the TODO list are crossed?

Eventually yes, but there is a fair amount of testing and simply trying this out in various scenarios and under various conditions before we would consider making it the default.

This is still very much "experimental" and will likely remain so for a while.

[antiochp]

Still reviewing.
Commented on a couple of very tiny cleanups in comments etc.

Looks 👍 so far.

[jaspervdm]

Resolved the TODO items. Currently the finalization step errors if the intial fee is different from the final fee. Technically we could handle the case where the initial fee is higher than the final fee with relative ease. It means we slightly overpay for the tx but it would be better than the tx failing to finalize.

[antiochp]

Currently the finalization step errors if the intial fee is different from the final fee.

This is probably fine to go with for now? I'm assuming this would be a minor change that affects only a single wallet (the one finalizing the tx) so rolling out an improvement for this would be a minor task.

[antiochp]

👍
This is cool.
Tested locally generating a bunch of "competing" slatepacks with different sends and able to choose any one of them to actually receive and finalize.

No locked outputs.
No unconfirmed change outputs.
Nothing to cleanup afterwards.

[antiochp]

"Coin control" gets interesting with "late locking" (see #529).

We need to specify a large enough fee up front, but we do not need to select explicit outputs to spend until the finalize step.

I'm actually kind of excited about how "coin control" would look with "late locking". You have a lot of freedom to pick and choose outputs in any way you want once you come to finalize it. Selection strategies can be very flexible this way.