Walletwasabi: Add Sweep Private Key Tab

[nopara73]

[MaxHillebrand]

I'm not sure what you mean here, but we now have the button with Select All / Select All Private / Select All Non-Private. It even shows the total value selected, and a privacy warning for consolidation.

I'd say we have everything, and can close this issue.

[johnnyasantoss]

I think this is a feature to transfer all funds from another private key ("sweeping" it). At least this is how it is on other wallets that I've tested :)

[btcpirate]

Woild be great to have it similar like electrum. Just a simple option to sweep private keys would be great

[nopara73]

Actually we don't even need to constrain this feature to bech32-only, because a single address balance query from a new Tor circuit is private.

[btcpirate]

that means it will be possible to sweep coins from any address? is it far back on the roadmap or soon?
thx for answer

[nopara73]

that means it will be possible to sweep coins from any address?

Yes.

is it far back on the roadmap or soon?

It's not even on any roadmap, just a concept ACK from me, which makes me sad, because I'd personally have a great use for this feature.

[MaxHillebrand]

FYI, I did put this on the ToDo list, since it is a feature that many do request. Hopefully a Wasabika finds the time to implement it :)

[btcpirate]

would be great, i do think this is a very important feature for many use cases! hope to see it some day in wasabi

[dooberdoober]

I concur. This feature will be greatly appreciated. Its a bummer to have to use another wallet to sweep keys in order to send to wasabi.

[nopara73]

To make some progress here, I'd like to bring up the largest decision to be made here for discussion.
First of all, I'd like to note that, this is a sweep, not an import function. There are numerous issues with importing.

Now, creating the UI elements are easy. The behavior is also straightforward: the user provides a privkey, we get the associated p2pkh/p2wpkh/etc keys to it. Then a call must be made to some service to get the utxos those to be swept. The dilemma is how should we get these? The issue is that Wasabi's backend runs on Bitcoin Core and it doesn't index addresses, so we would have to overcome that in one way or another. There are multiple solutions:

• Build our own address indexing service to our backend (this is the cleanest, but also the most time consuming.)
• Use an existing service to add to our backend, like esplora. (This is dangerous, introduces a lot of potential issues we wouldn't be able to fix. I think this small feature doesn't justify it.)
• Finally take a shorcut and just make a call to smartbit/coinbase/blockchain.info/blockstream.info/etc... (over Tor of course.)

[dooberdoober]

I think most users would prefer waiting longer for this feature to be implemented using option 1 or 3 ... versus using an option that introduces the potential for dangerous issues that cannot be fixed.

Other wallets exist if an address NEEDS to be swept clean.

[lontivero]

I think that having an addresses index service is very useful and would allow us to do many things in the future but for this feature we need an utxos index, am I right?

[nopara73]

So, I was thinking, maybe it'd be better if we'd distribute this across many block explorers. This'd provide more reliability. Also we could use this to recover from the "spent" issue that we are too incompetent to properly fix. So here's what would happen ideally:

We could feed a block explorer with a pubkey and the block explorer would give us back a list of transactions to the associated P2WPKH, P2PKH, P2PK, P2SH (wrapped segwit) addresses.
We could do this in a way that we use 3 different block explorers for this, (if something doesn't work we fall back to the next). Obvious candidate is Blockstream's because it can be accessed with an onion, but I guess for the rest we'd need exit nodes. Anyhow, creating this fault tolerant class with tests would be the first PR to make and from here on, both the privkey sweep and the spent issue recovery would be a childplay.

Of course having an address index on the backend would be ideal, but so many things we could get wrong and would take weeks to code it, and also possibly weeks to index the whole blockchain. But if someone feels the affinity for that, then I'm not stopping him.