Add Sweep Private Key Tab

[nopara73]

No description provided.

[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.

[fideo1]

Are we still not able to sweep keys??

[yahiheb]

Are we still not able to sweep keys??

Yes still not able to do that.

[TsDevDe]

are there any updates?

[lontivero]

I think it is a huge security risk but some people could need to sweep the keys for some valid reason so, we could simply add it to the listkeys rpc and with the wcli users could get it similar to other pieces of info like:

$ ./wcli.sh listkeys | head -10 

fullkeypath       internal  keystate  label  p2wpkhscript                              secret                     pubkey                                                              pubkeyhash
84'/0'/0'/1/0     true      2         0      b0ba6bb14314bacd1f908eb2b9ecc74e0b041717  <secret private key here>  039d67f2c7c3dd1ed0ac301e677fe3abf6f059067796553211d562f46f2e420043  b0ba6bb14314bacd1f908eb2b9ecc74e0b041717
84'/0'/0'/1/1     true      2         0      6b470de643697581b2717e6d2b878470a26d5e83  <secret private key here>  02efaf8fddc729e51826439ebac6e5782f60890262fd6c0702f537062bc4fe00f2  6b470de643697581b2717e6d2b878470a26d5e83
84'/0'/0'/1/2     true      2         0      6e16974cb396a40fed7a0beaa561dcc411056843  <secret private key here>  0230a07c357acc2d1ff18f7d9efbd4d33fb18e5d57d65402a6a454e5afe7c03078  6e16974cb396a40fed7a0beaa561dcc411056843
84'/0'/0'/1/3     true      2         0      af3a7f07b296d3523f0d6860c6ca232bbcb8c87f  <secret private key here>  02b6aca09cb632ac208dd2396a74dc20a67b955faf6688211a08584bc291470018  af3a7f07b296d3523f0d6860c6ca232bbcb8c87f
84'/0'/0'/1/4     true      2         0      469d19d3db1967ffc54e9f73f66568d5370e7fd3  <secret private key here>  032c92e3dd33a79795fbc494ee49212a12e0e052d7342921288b9d2be9ea5c06bf  469d19d3db1967ffc54e9f73f66568d5370e7fd3

[nopara73]

I don't share the security concerns. Hackers learn by burning themselves and it is a hacker feature. My issue is this cannot be done properly without a lot of work. We have two problems:

1. Wasabi uses client side filtering, which means sweeping a private key is similar to recovering a wallet, which takes forever. I think this would be still acceptable.
2. We cannot scan private keys properly, we can only do segwit (and hopefully soon taproot.) So we'd end up with a half-implemented feature. IMO we should not have any more half-assed feature in the software. I made this mistake many times in the past - our full node integration is still missing validation! - and we're suffering the complexity, maintenance and support consequences ever since. I'd prefer not having half-implemented features anymore. To resolve this we'd have to implement a new private balance retrieval mechanism, which yields a bad ROI.