Liquid support

[cryptoquick]

Describe the enhancement
Ideally BDK could optionally support showing an L-BTC balance and spending L-BTC outputs. I would think support for other assets would be out of scope, but the L-BTC asset could be hardcoded for basic Liquid support.

Use case
This would help users receive and spend L-BTC on the Liquid network using BDK.

Additional context
In the rising fee economy, we're being asked to support scaling solutions. I'm a developer for the BitMask wallet, bitmask.app.

One thing that helps is that Esplora / Mempool already supports the Liquid API.

[LLFourn]

Hey @cryptoquick I think this is far out of scope for the main bdk Wallet api. However, bdk_chain and bdk_coin_select probably already mostly support liquid conceptually. I'd like to know more about what supporting liquid in bdk_chain would look like. I can pick out a few things like we couldn't get the output values. I think what you'd want to do is add a type parameter to TxGraph that indicates the transaction type. We'd then keep the default for this as rust bitcoin's Transaction and have special impls based on what the transaction type parameter was set to. As long as it can all be nicely contained in its own module I think it'd be ok. Others might disagree.

[apoelstra]

I think this would be a fairly big maintenance burden unfortunately -- it would require a rust-elements dependency, and rust-elements is currently in a weird API no-mans-land which started analogous to rust-bitcoin 0.23 or something and has slowly grown cruft to stay current with rust-bitcoin's changing APIs.

So it's fine, it'll work, but the API is weird and old-feeling and not much of the existing bitcoin code will transfer trivially.

When rust-bitcoin 1.0 comes out we plan to substantially rewrite the rust-elements API so that again rust-bitcoin and rust-elements feel pretty-much the same. But we haven't been doing that work in real time because of how rapidly rust-bitcoin has been changing.

[cryptoquick]

Okay, well maybe we can keep this around for later, then. Am I correct in getting the sense that, there is an intention to have some measure of Liquid support someday, it just has to be done in a way that makes sense from an architectural perspective?