[Feature] Persistency for locking unspents

ghost commented at 6:48 am on December 10, 2018: none

In the way that this is currently implemented, you can lock/unlock unspents using coin control however after a software restart those locks disappear. This can lead to unintended spending of UTXO due to simply forgetting to lock them every time that the software is booted up.

fanquake added the label Wallet on Dec 10, 2018

promag commented at 2:29 pm on December 10, 2018: member

You could dynamically load/unload multiple wallets to do that kind of management.

promag commented at 2:35 pm on December 10, 2018: member

BTW, from #1861

It might be nice to store this in the wallet

6 years later and still not stored 😄

madeken commented at 5:21 pm on December 10, 2018: none

It would be amiss if I didn’t mention that locking unspents is most often far too low level to use correctly. I think without exception all times I have hoped to or actually locked an unspent, what I have actually meant is: “lock this address, with the possible exception of this output”.

I think the correct thing to store would actually be an address freeze-list, along with some per-output overrides.

promag commented at 1:05 am on December 11, 2018: member

I think you are better served with loading/unloading multiple wallets. I think we should avoid persisting state in the wallet file.

madeken commented at 2:10 am on December 11, 2018: none

Multiple wallets doesn’t really solve the typical case for wanting to lock inputs/addresses which is because you’ve had (tiny amounts) of unsolicited funds that if you spend would harm your privacy.

promag commented at 3:26 pm on December 11, 2018: member

@madeken I don’t understand your comment.

madeken commented at 6:35 pm on December 11, 2018: none

@promag A typical reason to wanting to lock an unspent is because someone sent you money (often dust) and if you spend it, you will generally be spend linking with other transactions which will future erode your privacy for typically no benefit. In fact, often the small dust ends up costing more to spend than its value.

An easy solution to this is to “lock” the unspent, so you don’t spend it. But in reality what you are actually wanting to do is lock an address (with the exception of the “real” unspent). None of this is benefited by using multiple wallets

promag commented at 8:29 pm on December 11, 2018: member

@madeken I think there can be alternative solutions for that instead of persisting unspent locking state.

MarcoFalke commented at 11:23 pm on May 8, 2020: member

The feature request didn’t seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Closing due to lack of interest. Pull requests with improvements are always welcome.

MarcoFalke closed this on May 8, 2020

ghost commented at 2:46 pm on May 28, 2021: none

I think you are better served with loading/unloading multiple wallets. I think we should avoid persisting state in the wallet file. @promag Sorry but I dont understand the first part. How does loading and unloading wallet solve this problem because if I restart bitcoind/bitcoin-qt, locks are gone.

What are the issues in saving locks in wallet file? I see only positives

promag commented at 5:35 pm on September 22, 2021: member

@prayank23, my suggestion was as simple as splitting the wallet in two and then load the 2nd only when you want to spend. Obviously this is limited especially with address reuse. In the past, I had to store utxos locks on the side and sync the wallet with that.. so I’d appreciate this feature at the time.

laanwj referenced this in commit 09cb5ec6c8 on Sep 26, 2021

DrahtBot locked this on Oct 30, 2022

[Feature] Persistency for locking unspents #14907