Adding outputs to a wallet at runtime

[LLFourn]

In several of the more cutting edge Bitcoin protocols you end up in a situation where there is a 2-of-2(A,B) where Alice and Bob own the two keys respectively. Later on, one of the parties (let's say Alice) learns the secret key for B through the execution of the protocol. Now Alice owns the output but needs to store and recall the secret key for B and the details of the output.

I was thinking it would be nice for magical to manage this for me. What I think I want is to be able to add some kind of auxiliary descriptors to a wallet. The wallet could store it in its database and treat it like any of its other unspent outputs. Here are some considerations that come to mind:

1. You would probably want a coin selection policy that spends these higher priority than outputs derived from your main descriptor (because they are lost if you lose database backup).
2. When doing things like get_balance you're probably going to want to see how much of your balance is derived from the main descriptor and how much is from these transient descriptors. Likely you will want to "sweep" all of these in one go back to the main wallet descriptor.
3. Sometimes these outputs have a pending tx that may spend from it in the future (e.g. revoked lightning commitment transactions) so the user needs to spend from it right away. Although it should be the application's job to make sure this happens, it would be cool if you could mark the auxiliary descriptor with a block height or time for which it must be spent before.

I was thinking about trying to implement something like this myself but wanted to check if you had an existing vision for this.

[afilini]

I think that would be an interesting use case to support, but I would also like to keep the current Wallet struct as simple as possible and potentially build those extra features in external modules/structures.

I think what you are describing could be generalized a bit into the concept of a "super-wallet" structure, basically a group of Wallets that have different descriptors. This super-structure would kinda act as a wallet itself, meaning it would expose a similar interface, but we could make changes where we feel like it's needed, and share resources whenever possibile.

This is actually a problem I encountered while working on neerg, due to the way Green handles subaccounts. Every subaccount is a separate Wallet and having a "container" type that can be used to group all of them would be nice.

On the other end, as I said I generally prefer to make a first very simple iteration of a concept and then potentially expand it in the future. So I wouldn't really focus too much on the part where you can describe which outputs can be spent with arbitrary rules, because if you really try to make that super generic, it probably becomes a mess. Since the users of the library can always implement custom coin selection algorithms or choose which utxos can/cannot be spent, I would just let them implement the rules they need with code.

So basically what I would do is:

• Make a structure that contains multiple wallets and shares resources, like Blockchain, through Arcs¹.
• Define a trait for a "MultiDatabase", a structure that can create and return a Database for each inner Wallet of the container. ²
• Make the "MultiDatabase" structure expose an interface similar to Wallet but potentially with some changes where needed. Probably create_tx and sign will need some tweaks in that sense. Maybe a "MultiTxBuilder" is needed.

Then, on a very high level what you described would look something like:

let multi_wallet = MultiWallet::from(vec![main_wallet, temp_wallet]); // create a new container with the main wallet and a temporary one
multi_wallet.sync(...)?; // sync all the inner wallets

let temp_utxos = mutli_wallet.get_inner(<some_reference_to_temp_wallet>).list_unspent()?; // get the utxos for `temp_wallet`
let (psbt, details) = multi_wallet.create_tx(TxBuilder::new(...).utxos(temp_utxos))?; // create a tx that spends all the utxos for `temp_wallet`
let (psbt, finalized) = multi_wallet.sign(psbt)?; // sign
assert!(finalized);

mutli_wallet.broadcast(psbt.extract_tx())?; // broadcast

---

If you wanna discuss this further in a more direct way feel free to join our new discord server. There's a "development" channel that is specifically made for these kind of discussions.

---

1: Blockchain is already implemented for every Arc<T: Blockchain>. It was done exactly for this reason, being able to share the same backend across multiple Wallets.

2: I wouldn't share Databases directly because adding a "wallet_id" field or something like that to basically every entry would complicate accessing data later. I would again try to handle this on an extra layer: for instance, with the default database sled, you can create multiple sub-trees from a single sled::Db, which I think is a much better way to keep everything organized. The "MultiDatabase" trait I was describing earlier could be implemented on sled::Db and it would return a sled::Tree for every individual wallet. sled::Tree already implements the required Database traits.

[notmandatory]

This is one of our oldest still open issues. @LLFourn is it still relevant enough to keep open?

[LLFourn]

Approaches to this can be developed when refactoring tx building. I think the solution will fall out naturally so there's no need to keep this around.