3 ms·

That's just how wallet backup works, I'm not sure how that is related to taint. Perhaps a better illustration of the taint issue is "change". Whenever you need

That's just how wallet backup works, I'm not sure how that is related to taint. Perhaps a better illustration of the taint issue is "change". Whenever you need to send an amount of bitcoin that does not exactly match one of the UTXOs ("unspent transaction output") in your wallet, you will - potentially need to use multiple UTXOs as input (thus linking together the past transaction that produced them) - very likely have a "change" output that sends the excess amount back to a new address in your own wallet. Which output is change can be guessed with heuristics, and that UTXO will eventually be used in a future transaction, linking it to the current transaction. Basically, all transactions associated with a wallet tend to become linkable over time.

xiphias2 6y ago
I think you don't have experience with the Trezor. It uses BIP32 wallet (hierarchical deterministic wallet) which derives the private keys from one master seed stored on the device. Older wallets could import separate private keys, but Trezor doesn't have this feature. If you want to move to a new device without having access to the master key, you need to make a transaction that connects all addresses (both inputs and change addresses). It's not just ,,linkable over time'', it means that you link all UTXOs in 1 transaction. What you are wrighting is also a problem, but different from what I had in practice.
- wmf 6y ago
  If you want to import N UTXOs into a Trezor you can generate N fresh addresses and use N independent transactions to move the money over. Then you have to be careful about joining those UTXOs later. I'm not aware of any wallet that allows this, but it's theoretically possible. I think the advantages of the BIP32 model are worth it considering how many people lost private keys in the old wallet.dat model.
  - xiphias2 6y ago
    Thanks, but no thanks! Have you tried doing it? For me it was easier to locate the original paper backup even though it meant significant amount of travelling to the place where it was kept just so that the UTXOs don't get joined. I'm talking about the UX itself trying to make me lose privacy, and you suggest a solution that is even more complicated and especially expensive. Also what you suggest needs to be done slow enough so that the transactions can't be joined by the time of sending. I'm writing about a real problem that happened to me just a few days ago and getting answers without practical real solutions that would be better than what I have done.

xiphias2 6y ago

I think you don't have experience with the Trezor. It uses BIP32 wallet (hierarchical deterministic wallet) which derives the private keys from one master seed stored on the device. Older wallets could import separate private keys, but Trezor doesn't have this feature. If you want to move to a new device without having access to the master key, you need to make a transaction that connects all addresses (both inputs and change addresses). It's not just ,,linkable over time'', it means that you link all UTXOs in 1 transaction. What you are wrighting is also a problem, but different from what I had in practice.

wmf 6y ago
If you want to import N UTXOs into a Trezor you can generate N fresh addresses and use N independent transactions to move the money over. Then you have to be careful about joining those UTXOs later. I'm not aware of any wallet that allows this, but it's theoretically possible. I think the advantages of the BIP32 model are worth it considering how many people lost private keys in the old wallet.dat model.
- xiphias2 6y ago
  Thanks, but no thanks! Have you tried doing it? For me it was easier to locate the original paper backup even though it meant significant amount of travelling to the place where it was kept just so that the UTXOs don't get joined. I'm talking about the UX itself trying to make me lose privacy, and you suggest a solution that is even more complicated and especially expensive. Also what you suggest needs to be done slow enough so that the transactions can't be joined by the time of sending. I'm writing about a real problem that happened to me just a few days ago and getting answers without practical real solutions that would be better than what I have done.