[feature request] add sweep private address option to bitbox-wallet

[wilya7]

Crypto ATMs allow to buy bitcoins using cash. Due to the confidential nature of the transaction they are very valuable to increase the privacy level of a bitcoin holder. These machines work by printing a "paper wallet" that contains two strings of characters, represented by QR codes, one for a private key and the other for the corresponding public key that the ATM machine load with the bitcoins bought by the customer.

Once the transaction is concluded, the buyer should quickly send a new transaction to the bitcoin network to move the whole content of the bitcoin purchased to a new address of its own wallet. This function is supported by few software wallets, including electrum, and it is called "sweep private address". By the way, I find this name very confusing.

It would be very useful if bitbox-wallet would introduce this ability with a decent user interface. It would be great to have the possibility to read the qr code from the printed paper and prepare a transaction, to be signed using the bitbox, moving the purchased bitcoins to an address of the bitbox wallet.

Thanks for considering this request.

[NickeZ]

Since you will have to go through a "compromised" unit (your phone or laptop) to get the private key onto the bitbox02 I don't see any benefit in the bitbox02 actually signing the transaction. However, it would be nice if the BitBoxApp could create and sign such a transaction and sweep the coins to an address of a connected BitBox02. This should preferable be done on an offline computer though.. So many security implications...

[jadzeidan]

@wilya7 We have thought about it and like the idea. As @NickeZ mentioned, we need to think about the security aspect since the private key will be exposed to the wallet so the coins will be "hot" until the transaction is made. We have other features in the pipeline so might take a little while to get to this one. Thank you for the feature request!

[wilya7]

Thanks for the comments. Please be aware of this issue concerning implementing this feature and having a customer using electrum personal server as a backend.

[wilya7]

@NickeZ Of course. You are absolutely correct. I did not think this trough. Thanks for pointing it out.

[benma]

Thanks for the comments. Please be aware of this issue concerning implementing this feature and having a customer using electrum personal server as a backend.

Thanks for the warning :+1:

[wilya7]

Question about this request.

Say that a user has a compromised laptop with some malware that wants to empty his/her wallet. The user asks Bitbox wallet to prepare a transaction to sweep the purchased coins using the private key visible on the print out from the ATM. Then, the wallet asks for the qr code or manual input of the private key. Then, it generates the receiving address, prepare the transaction but it waits for confirmation on the hardware wallet. Bitbox2 hardware wallet at this point asks for confirmation of the correctness of the coins amount, then asks to confirm the receiving address, and finally the private key from the ATM. Only after the user approval, the software wallet sends the transaction to the mempool. No signing from the hardware wallet happens, this is only a way to interact with the user using a different channel than the keyboard and screen of the laptop.

Would this procedure be able to resist a possible attempt from the malware to steal the coins? Would this be a valid UI for such a feature? To me it looks like the malware has to intercept the USB communication from the compromised laptop and the hardware wallet to inject a different receiving address. Otherwise, shouldn't the visual inspection be enough to resist the classical copy and paste attach?

[benma]

@wilya7 if the private key is entered in any way in the app, it is potentially compromised. Checking it on the device does not help unfortunately, as if malware gets hold of it, it could sweep the funds to the attacker's address before the user does.

[jadzeidan]

Question about this request.

Say that a user has a compromised laptop with some malware that wants to empty his/her wallet. The user asks Bitbox wallet to prepare a transaction to sweep the purchased coins using the private key visible on the print out from the ATM. Then, the wallet asks for the qr code or manual input of the private key. Then, it generates the receiving address, prepare the transaction but it waits for confirmation on the hardware wallet. Bitbox2 hardware wallet at this point asks for confirmation of the correctness of the receiving address, and after that, for confirming the private key as well. Only after the user approval, the software wallet sends the transaction to the mempool. No other signing from the hardware wallet happens, this is only a way to interact with the user using a different channel than the keyboard and screen of the laptop.

Would this procedure be able to resist a possible attempt from the malware to steal the coins? Would this be a valid UI for such a feature? To me it looks like the malware has to intercept the USB communication from the compromised laptop and the hardware wallet to inject a different receiving address. Otherwise, shouldn't the visual inspection be enough to resist the classical copy and paste attach?

When you say BitBox wallet, I assume you mean the user enters the paper wallet seed into the BitBox02 device and not on the computer via the BitBoxApp, correct?

With regards to the receive address, the receive address is generated on the BitBox02 device, so it is not supplied by the BitBoxApp to the BitBox02. So you can't give the BitBox02 a false receiving address via USB.

[wilya7]

@jadzeidan I was thinking about the software wallet, as @benma correctly guessed. Clearly I am not good at thinking in terms of security. I see now my question was really stupid.

What if the private key is entered on the bitbox2 hardware wallet then?

[jadzeidan]

@wilya7 In this case I assume the BitBox02 would need to create a "temporary" wallet with the paper wallet seed in parallel to your original wallet. And then create a tx to send all the coins from the temporary wallet to your orginal wallet (where of course the BB02 would show you the receive address of your orginal wallet so you know you are sending it to the correct address).

[thisconnect]

What if the private key is entered on the bitbox2 hardware wallet then?

👍

[wilya7]

@wilya7 In this case I assume the BitBox02 would need to create a "temporary" wallet with the paper wallet seed in parallel to your original wallet. And then create a tx to send all the coins from the temporary wallet to your orginal wallet (where of course the BB02 would show you the receive address of your orginal wallet so you know you are sending it to the correct address).

sounds perfect. Or, as perfect as it can be given the security issue. Please let me know if I can help testing this feature, should it be implemented of course.

[jadzeidan]

sounds perfect. Or, as perfect as it can be given the security issue. Please let me know if I can help testing this feature, should it be implemented of course.

Thanks. I imagine this features would be quite complex to implement, since you basically need two wallets to be "active" on the BitBox02 at the same time.

[wilya7]

Thanks. I imagine this features would be quite complex to implement, since you basically need two wallets to be "active" on the BitBox02 at the same time.

Yes, and this is probably a corner case for the few lucky enough to have access to an ATM where to buy bitcoin. I understand that you have way higher priority now.

Regardless, whether you find the resources to code this feature or not, I am grateful you are considering it.

[jadzeidan]

@wilya7 Yeah, but this would be a cool feature regardless. Will definitely keep you in the loop if we ever decide to pursue it :)

[benma]

Not to forget, entering a private key on the BitBox02 difficult - a private key is quite long, so it would take a long time to enter it via the BitBox02 keyboard input. This feature would be more feasible if there was a QR code scanner.