Support for CT Descriptor wallet to also handle unblinded outputs

[i5hi]

Currently a CT Descriptor Wallet only recognizes blinded outputs. If the user of the wallet shares a confidential address and the sender does not blind the outputs and instead sends to the unblinded address, the wallet does not detect the transaction.

It would be nice if the CT Descriptor Wallet can also recognize and handle unblinded outputs.

[LeoComandini]

Hi @i5hi

We are currently evaluating how to handle unblinded outputs.

To start, we went for the conservative approach.
We only show confidential addresses, thus we only expect blinded outputs.

If we select unblinded utxos, that might not align with the user privacy expectations.
A user might be thinking that a transaction is fully blinded,
while some of its inputs might be explicit.

Also, selecting unblinded utxos, might make blinding fail,
and we should get coverage and proper management for that case as well.

Nevertheless we want to allow users to spend those funds.
We need to discuss a way that is reasonable for callers.

We'll post updates here.

[apotdevin]

Thanks for the update!

We currently have a swap flow that uses covenants and we need to send to an unconfidential address to be able to compare amounts during the swap.

This is a big blocker for us :S we will need to add some extra logic to at least show that the utxos are there

[RCasatta]

I guess it's impossible to find a way in the protocol to use confidential address and pass blinding factors to entities needing to compare amounts like the explorer unblind outputs if the blinding factors are provided

[LeoComandini]

Hi @i5hi @apotdevin

A possible approach that we might pursue is #43 (which still needs some work)

Check test_unblinded_utxo to see how an unblinded utxo can be spent.

It's not first class support for handling unblined UTXOs, but it allows spending them.

[LeoComandini]

We went for the approach in #43

Let us know if the new interface is enough for you @i5hi @apotdevin

Still some more fixes and test but we'll add them in the coming days.

[jtrivinop]

@i5hi @apotdevin wondering what you guys think about this approach. Let us know if this is enough to cover your use case

[apotdevin]

For now, we reverted to using a non-covenant flow that allows us to claim funds to a confidential address. While it's not the ideal solution, it allows us to maintain all other aspects of the wallet as they are.

[i5hi]

@jtrivinop @LeoComandini

Haven't had the chance to test it yet. Will look into it over the next week and let you know.

From a quick review of the test in lwk_wollet/tests/e2e.rs - test_unblinded_utxo this has been my observation:

We mainly have 2 problems:

1. Detecting an unblinded utxo: in the test, it seems the txid is used to find the unblinded utxo, which in the case of the wallet - we will not have. In the test, the transaction is made by server.tonodeaddress which returns the txid that is used to find the relavant utxo. So I am still unsure if this problem is fully addressed for a wallet that does not know when a transaction has been sent to it. Is there an alternative way? Manually checking with electrum if the scriptpubkey has a transaction?

2. Spending an unblinded utxo: this seems fixed by the add_external_utxos method to TxBuilder

[LeoComandini]

Hi @i5hi

Is there an alternative way?

Yes, check the current version of https://github.com/Blockstream/lwk/blob/master/lwk_wollet/tests/e2e.rs ,
it was updated in following PRs.

Now we have Wollet::explicit_utxos to fetch unblinded utxos,
if you want something more to be exposed,
we can add that.