Topic: Why is there "change"? (Read 823 times)
To Casascius: I was hoping for something simpler. Unfortunately, It seems that the simpler the scheme,the more vulnerable it is. I need to re-think the strategy. The non-computerized nest-eggs with the day-to-day checkbooks should work, but how to hide access needs more thought. Thanks again.
To D&T: Yes, I misunderstood. I did not think through the idea that someone could simply churn out zillions of pass-phrases and rip off the few-in-a-zillion that "hit". To protect against this, the pass-phrase must have as much entropy as a random string of gibberish, which puts us back at the computer-generated privkey again. Hmmm.
I think you misunderstand it doesn't require someone to target you. Hackers can simply target all possible addresses simultaneously. Passphrases are relatively low entropy and without salt and key stretching hackers can just continually try all probable passphrases and steal funds from the addresses they find.
i.e. try a particular pass-phrase, generate the private key, compute the corresponding address, see if the address has value, if it does steal it, if it doesn't move on.
Likely whoever brute forces the password doesn't even know who you are, nor do they care. They are just looking for an address with value to steal.
Say this address (just grabbed it randomly from blockchain.info) is derived from a private key which is produced from the passphrase "password".
http://blockchain.info/address/14dnpgFWkqxsxb8ZbMVSTKVWofuUAD77rB
Who owns this address? Who knows? Who cares. As soon as the hacker determines they have a private key for an address with value they will spend it. It is important to realize that with a brain wallet the funds can be stolen simply by discovering the passphrase. With a random key, or even an encrypted bitcoin wallet that isn't the case. It requires some physical or electronic access which is a significantly harder thing to achieve.
What Bitcoins? Prove how many Bitcoins I have.
i.e. try a particular pass-phrase, generate the private key, compute the corresponding address, see if the address has value, if it does steal it, if it doesn't move on.
Likely whoever brute forces the password doesn't even know who you are, nor do they care. They are just looking for an address with value to steal.
Say this address (just grabbed it randomly from blockchain.info) is derived from a private key which is produced from the passphrase "password".
http://blockchain.info/address/14dnpgFWkqxsxb8ZbMVSTKVWofuUAD77rB
Who owns this address? Who knows? Who cares. As soon as the hacker determines they have a private key for an address with value they will spend it. It is important to realize that with a brain wallet the funds can be stolen simply by discovering the passphrase. With a random key, or even an encrypted bitcoin wallet that isn't the case. It requires some physical or electronic access which is a significantly harder thing to achieve.
Quote
This is why I chuckle at those who think that bitcoins cannot be confiscated or stolen. If there is enough money at stake, thugs (including governments) find it cheaper and more effective to use violence than code-cracking.
What Bitcoins? Prove how many Bitcoins I have.
To D&T: Good point. Thank you for the advice. I appreciate it. To my eyes, it comes down to cost plus risk versus gain. Is our meager nest-egg worth someone putting the time (funds) into cracking my phrase? If so, would it not be cheaper and faster to just shoot one of our kids and then aim at our second child's head and demand the phrase, or simply demand that I send the money? This is why I chuckle at those who think that bitcoins cannot be confiscated or stolen. If there is enough money at stake, thugs (including governments) find it cheaper and more effective to use violence than code-cracking. (A court order is nothing more than a politely veiled threat of violence.) Please pardon my cynicism; I have worked for some very corrupt governments. YMMV.
To DannyHamilton: Yes indeed! Great idea. Thank you.
To DannyHamilton: Yes indeed! Great idea. Thank you.
I would suggest printing 10 password protected paper wallets, dividing your stash, storing them safely (e.g. safety deposit box), and then memorizing the password as well as sharing it with trusted few. Since the paper is required to redeem the funds, the password doesn't have to be so complex.
If you made 2 copies of the same batch of paper wallets and stored them in two separate places, you're protected from a bank fire.
The password protects you against the possibility the bank can get in to the box and steal your funds.
If you made 2 copies of the same batch of paper wallets and stored them in two separate places, you're protected from a bank fire.
The password protects you against the possibility the bank can get in to the box and steal your funds.
That isn't a bad plan (although D&T's suggestion to avoid using a "brainwallet" is worth considering).
My only suggestion would be:
Rather than having a single offline keypair for your "nest egg", perhaps consider having 10 of them and splitting your savings equally across the 10 addresses. That way if something should happen to damage/destroy one of them you'd only lose 10% of your savings. Also if you should run into an issue while importing the private key (like if your computer is compromised with a wallet stealing virus), you'd only lose 10% of your savings before discovering the problem.
My only suggestion would be:
Rather than having a single offline keypair for your "nest egg", perhaps consider having 10 of them and splitting your savings equally across the 10 addresses. That way if something should happen to damage/destroy one of them you'd only lose 10% of your savings. Also if you should run into an issue while importing the private key (like if your computer is compromised with a wallet stealing virus), you'd only lose 10% of your savings before discovering the problem.
I would recommend against a brain wallet unless you are very confident in your knowledge of cryptography.
It is unlikely any unsalted passphrase will have sufficient entropy to risk a brute force attack. For long term off line storage a purely random private key stored in multiple locations would be better. The offline printed private key could be encrypted for additional security.
It is unlikely any unsalted passphrase will have sufficient entropy to risk a brute force attack. For long term off line storage a purely random private key stored in multiple locations would be better. The offline printed private key could be encrypted for additional security.
Thank you all. I think I understand.
Based on what you said, my planned strategy will be to keep no more money in our day-to-day wallets than I am willing to lose if my smartphone or my wife's laptop are stolen, or if our desktop computer catches fire.
On the other hand, I shall collect part of my family's life savings into a non-computerized "brain" key-pair nest egg. The nest egg will often receive but (not being implemented anywhere) can never send. When I must spend some money out of the nest egg, I shall import its privkey into software for the first time, spend what I need, then immediately empty whatever is left in it, into a new non-computerized "brain" key-pair, which in turn becomes the new nest egg.
Thus, only trivial transactions are normally visible to others, and our nest egg is invisible and damn near invulnerable to anything short of teotwawki.
Based on what you said, my planned strategy will be to keep no more money in our day-to-day wallets than I am willing to lose if my smartphone or my wife's laptop are stolen, or if our desktop computer catches fire.
On the other hand, I shall collect part of my family's life savings into a non-computerized "brain" key-pair nest egg. The nest egg will often receive but (not being implemented anywhere) can never send. When I must spend some money out of the nest egg, I shall import its privkey into software for the first time, spend what I need, then immediately empty whatever is left in it, into a new non-computerized "brain" key-pair, which in turn becomes the new nest egg.
Thus, only trivial transactions are normally visible to others, and our nest egg is invisible and damn near invulnerable to anything short of teotwawki.
Thank you for patience. But this takes us back to question 1. If there is no harm in change lapping back to the sending key-pair, then why do most of the wallets spawn a new address each time to receive the change?
It adds needless complication, confuses newbies, frightened at least one other newbie in this subforum, and--as you say--makes it harder to track.
Normally, I am not that curious about what software designers must have had in mind, but since most spawn needless addresses, I fear that they must know something that I don't.
It adds needless complication, confuses newbies, frightened at least one other newbie in this subforum, and--as you say--makes it harder to track.
Normally, I am not that curious about what software designers must have had in mind, but since most spawn needless addresses, I fear that they must know something that I don't.
The purpose is to make it difficult for OUTSIDERS to track transactions through the blockchain. If everyone used a single address and always sent change back to that address it would be beyond trivial for an entity (banks, law enforcement, governments, your boss, etc) to track anything and everything you spent money on, down to when and where, and your current net worth.
The fact that in the reference client that is hidden means that almost no one know that and that backuped wallet can become outdated, wich means that someone will someday lose money without even knowing why....
In addition to the fact that sending change to a new address makes it more difficult for others to determine your economic activity and personal holdings when looking at the blockchain, there is also a security reason for using a new address for every transaction.
At the moment ECDSA hasn't been discovered to have a flaw, and it is quite possible that it never will.
However, if in the future a flaw were found that allowed ECDSA to be reversed (meaning you could determine the private key if you have the public key). then any bitcoin address that had been used to send bitcoins would no longer be safe (the public key of the inputs is included in the transaction). Since a bitcoin address is a hash of a public key, those addresses that had only been used to receive bitcoins would still be safe. SHA-256, RIPEMD-160, and ECDSA would all have to be broken at the same time to find a private key if all you have is an address.
Certainly if ECDSA was found to be broken, Bitcoin would be updated to use a new signature algorithm, but until the bitcoins were moved to an address using the new algorithm those that had been sent to an address that had been previously used for sending would be vulnerable to theft.
At the moment ECDSA hasn't been discovered to have a flaw, and it is quite possible that it never will.
However, if in the future a flaw were found that allowed ECDSA to be reversed (meaning you could determine the private key if you have the public key). then any bitcoin address that had been used to send bitcoins would no longer be safe (the public key of the inputs is included in the transaction). Since a bitcoin address is a hash of a public key, those addresses that had only been used to receive bitcoins would still be safe. SHA-256, RIPEMD-160, and ECDSA would all have to be broken at the same time to find a private key if all you have is an address.
Certainly if ECDSA was found to be broken, Bitcoin would be updated to use a new signature algorithm, but until the bitcoins were moved to an address using the new algorithm those that had been sent to an address that had been previously used for sending would be vulnerable to theft.
In the reference Bitcoin client, all change activity is hidden from you. It works without confusing anybody. It is only the availability of other tools, which reveal what is happening behind the scenes, that may confound.
Change is required for you to be able to send arbitrary amounts, since only a complete input (previous payment you received) can be spent.
It is not desirable to have your Bitcoin balance easily determined by any user worldwide, much as you wouldn't want anybody to be able to see how much is in your real wallet or your bank account. While Bitcoin doesn't promise anonymity, it does what it can to complicate remote payment observations, given that the blockchain of all transactions is public:
- A user can have a near infinite number of addresses, all centrally managed by the software,
- An address can be used once and never again (Bitcoin does this for change, and leaves it up to the user to do this with all other payments),
- When there is a payment and change sent, Bitcoin makes it harder to determine which is the actual payment.
The opposite extreme would be one single address per user, where anybody you transact with or share your address with would be able to see your bank balance and determine everybody you've been doing business with and how much you've been paying them. Few users would desire this behavior.
Change is required for you to be able to send arbitrary amounts, since only a complete input (previous payment you received) can be spent.
It is not desirable to have your Bitcoin balance easily determined by any user worldwide, much as you wouldn't want anybody to be able to see how much is in your real wallet or your bank account. While Bitcoin doesn't promise anonymity, it does what it can to complicate remote payment observations, given that the blockchain of all transactions is public:
- A user can have a near infinite number of addresses, all centrally managed by the software,
- An address can be used once and never again (Bitcoin does this for change, and leaves it up to the user to do this with all other payments),
- When there is a payment and change sent, Bitcoin makes it harder to determine which is the actual payment.
The opposite extreme would be one single address per user, where anybody you transact with or share your address with would be able to see your bank balance and determine everybody you've been doing business with and how much you've been paying them. Few users would desire this behavior.
Thank you for patience. But this takes us back to question 1. If there is no harm in change lapping back to the sending key-pair, then why do most of the wallets spawn a new address each time to receive the change?
It adds needless complication, confuses newbies, frightened at least one other newbie in this subforum, and--as you say--makes it harder to track.
Normally, I am not that curious about what software designers must have had in mind, but since most spawn needless addresses, I fear that they must know something that I don't.
It adds needless complication, confuses newbies, frightened at least one other newbie in this subforum, and--as you say--makes it harder to track.
Normally, I am not that curious about what software designers must have had in mind, but since most spawn needless addresses, I fear that they must know something that I don't.
The wiki does not answer question 2. What is the harm in having change lap back to the sending key-pair?
Functionally, there is no problem, but sending the change to a new address is more difficult tracing and linking different transactions with the same individual
The wiki does not answer question 2. What is the harm in having change lap back to the sending key-pair?
1. My desktop wallet (Armory on bitcoin) holds several key-pairs. When I send money from one key-pair, "change" usually comes back into one of the wallet's other addresses. Why?
2. To ask the same question differently: my Android smartphone wallet (Bitspinner) holds only one key-pair. When I send money from it, there is never any change (or the change laps invisibly back into the wallet's single address). What is the harm in that? If there is no harm, see question 1.
2. To ask the same question differently: my Android smartphone wallet (Bitspinner) holds only one key-pair. When I send money from it, there is never any change (or the change laps invisibly back into the wallet's single address). What is the harm in that? If there is no harm, see question 1.
Jump to: