Couple of questions about wallets

[adds]

Hi,

I'm a little new to Bitcoin, and although I've learned a lot over the last week or so, I'm still a little unclear about a few things which I hope the community will be able to help me out with!

I understand (I think!) that each public key (the wallet address?) has corresponding private key.  You could have an "off-line" wallet, by writing down your private and public keys, and then deleting the wallet file(?).  You should then me about to import both your keys at some point in the future into any Bitcoin wallet software, and access your bitcoins again.  In the meanwhile, you can still give people your public key, and it can still be used to send Bitcoins too.

(Is that right?)

I'm using Bitcoin QT, and it allows me to create a number of different wallets.  Presumably if I wanted to make a note of the private key for each one, I'd ender the console mode in Bitcoin QT, and type the command to display the private key for any one of the wallets?

What confused me, is that the other day I used BTC to buy something.  I had (for example) 1.5 BTC in my wallet, so I sent 1.2 BTC to the person I was paying, obviously leaving 0.3 in my wallet.  That all happened perfectly.  But today, when I thought I'd have a look at the blockchain, I see that, although Bitcoin QT correctly says my wallet contains 0.3 BTC, if I add up the "Final Balance" of the 3 different public key addresses I have listed, it comes to something like 0.1 BTC.  The remaining 0.2 BTC, although I can see see it, appears to have been transferred to a different public address at the same time I paid the 1.2 BTC the other day.

The point is, I know this is still "mine", because it shows up in my confirmed balance in Bitcoin QT, but I don't understand the mechanism which appeared to create a new(?) public address, and transferred the 0.2 to it.

Also, this presumably means the 0.3 BTC I have is arbitrarily spread around my different wallets?  If I wanted to take that 0.3 BTC off-line, how would I know which wallet, or wallets it was in? - And as it appears that a public address has been created for me without me knowing, how would I find it unless I did what I did, which was to look at that particular transaction in the blockchain?

I'm sorry for asking, what I suspect are quite basic questions, but I'm interested to know how it works!

Thanks.

[farlack]

You can send payments to the address even if its offline, someone please confirm, but offline wallets can only have 100 transactions sent to it without being updated.

If your bitcoin are spread between a bunch of wallets on the QT, and you send a payment, it will deduct from all the balances if it will leave a 0 balance.

[Remember remember the 5th of November]

You can send payments to the address even if its offline, someone please confirm, but offline wallets can only have 100 transactions sent to it without being updated.

If your bitcoin are spread between a bunch of wallets on the QT, and you send a payment, it will deduct from all the balances if it will leave a 0 balance.

That little bit there isn't exactly correct. If you have just a single address in cold storage you can send to it as many times as you like, the only time you need to update anything is the wallet.dat file once you've done 100 transactions with it, since when you send it usually sends the change back to a newly generated random address.

[acoindr]

You've asked a bunch of questions. First it's helpful to understand terminology.

Yes, in Bitcoin value is assigned to key pairs which consist of a public key and private key. A public key can be derived from a private key, but not the reverse; you can't find a private key by knowing the public key. The private key is what gives authorization to send coins.

Technically, a single public/private key pair can be thought of as an account. The word "wallet" generally means some sort of management of a number of these key pairs or accounts. Typically this is done with software such as Bitcoin-Qt. To store coins offline, or what's known as cold storage, you simply need to copy the private keys down in some way which can be retrieved, but which doesn't expose them to online computers in any way.

Yes, Bitcoin-Qt has a number of commands for navigating around and dealing with key pairs. However, it's generally believed to be safest and easiest to use bitcoinarmory to make paper wallet backups and manage coin transactions, because the way it works private keys are never exposed to online machines which might have viruses. Armory is still being improved but for now it's about the best we've got for simple rock solid coin security.

As for why your balances in Bitcoin-Qt looked weird, that's by design. When you create a Send transaction the "change" is sent back to a different address to enhance anonymity. This doesn't happen in all wallet clients. For example, Multibit doesn't currently do this.

You can send payments to the address even if its offline, someone please confirm, but offline wallets can only have 100 transactions sent to it without being updated.

If your bitcoin are spread between a bunch of wallets on the QT, and you send a payment, it will deduct from all the balances if it will leave a 0 balance.

That little bit there isn't exactly correct. If you have just a single address in cold storage you can send to it as many times as you like, the only time you need to update anything is the wallet.dat file once you've done 100 transactions with it, since when you send it usually sends the change back to a newly generated random address.

Correct. There is no limit to the number of transactions a private key/public key pair can receive, and neither needs to be "online" to receive payments. Refreshing backups of wallet.dat per number of transactions is due to the way Bitcoin-Qt works. I explained it in detail on Reddit.

[odolvlobo]

Bitcoin-qt has a pool of 100 hidden addresses. When you send BTC somewhere, Bitcoin-qt sends the "change" to one of those hidden addresses. The hidden addresses are just like all the other addresses in your wallet, but they are hidden because you don't really need to worry about them.

BTW, An address is where you send bitcoins. It generally looks like this: 1PccLTjsKBHJ4znhwmo8uN6CPkyf6zrRYa. A wallet contains one or more addresses and the associated private keys. People tend to use "public key" and "bitcoin address" interchangeably, but they are actually not the same thing.

[tvbcof]

It's kind of cool to see a new user actually explore some of this stuff.  I think you'll be well rewarded for doing so.  The wiki (if it still exists) and the whitepaper are good resources.

Below are some of my (possible incorrect) understandings phrased in a way which you might find interesting:

A 'bitcoin' can mostly be considered the value of a summation of all of the prior economic activity which impacts and address going back to the beginning of Bitcoin time.

The wallet and transactions in general have some surprising characteristics.  One of them is as you've noted that new key-pairs are created all of the time.  Spends often spend more than the desired amount and then return change to newly created keys.  A default wallet has (had?) a certain number of keys (100) by default, but would create more of them as needed if it were highly active.

An annoyance of this property was that the newly generated keys were unpredictable.  This means that one needed to back up their wallet regularly or miss newer keys.  The solution was to generate new keys from a seed such that newly generated addresses could be predicted and thus one only needed to back up the seed.  Armory, iirc, sort of pioneered this technique.

Another problem which became more significant with the recent 'malleability' issue is that because spends can exceed the value that one intends (with 'change' to be returned) one can loose access to a higher value than one expects until the transaction succeeds in being locked into the blockchain or is rejected by the network.  So, if you have 10 BTC and spend 1 BTC, you might not have access to 9 BTC for a while.  In times past clients would make an educated guess that they probably could scrape up 9 BTC to spend even when things were not confirmed and attempt to do so.  The malleability threw a wrench into how reliable this was and some clients have recently modified this behavior.  (Nobody wants to live with or even really admit that native Bitcoin has a block cycle time in the 10 minute range since if fucks up their day for trinket buying adventures.)

Why was the system designed with these features?  It was subject to some debate even among the devs when I was trying to get a handle on things some years ago.  The devs seemed fairly universally confused and also somewhat irritated.  It may have been a somewhat aborted attempt at privacy.  Or the designer may have had thoughts of how clean-up of the blockchain might be accomplished (by draining to zero addresses and thus allowing them to be purged.)  Or some combination.  Or something else.

[DannyHamilton]

each public key (the wallet address?) bitcoin address has corresponding private key.  You could have an "off-line" wallet, by writing down your private key and public keys bitcoin address, and then deleting whatever you used to create them (which might be the a wallet file(?)).  You should could then me about to import both your keys at some point in the future into any some Bitcoin wallet software, and access your bitcoins again.  In the meanwhile, you can still give people your public key bitcoin address, and it can still be used to send receive Bitcoins too.

(Is that right?)

Fixed that for you.

[Remember remember the 5th of November]

each public key (the wallet address?) bitcoin address has corresponding private key.  You could have an "off-line" wallet, by writing down your private key and public keys bitcoin address, and then deleting whatever you used to create them (which might be the a wallet file(?)).  You should could then me about to import both your keys at some point in the future into any some Bitcoin wallet software, and access your bitcoins again.  In the meanwhile, you can still give people your public key bitcoin address, and it can still be used to send receive Bitcoins too.

(Is that right?)

Fixed that for you.

With all the scribbles it's difficult to tell what you meant. But it's also not incorrect to say that a public key has a corresponding private key. I mean, a Bitcoin address is a just a base58 representation of the ripemd160 hash of the sha256 hash(double) of the public key + checksum whereas the private key is just base58 encoded.

[DannyHamilton]

each public key (the wallet address?) bitcoin address has corresponding private key.  You could have an "off-line" wallet, by writing down your private key and public keys bitcoin address, and then deleting whatever you used to create them (which might be the a wallet file(?)).  You should could then me about to import both your keys at some point in the future into any some Bitcoin wallet software, and access your bitcoins again.  In the meanwhile, you can still give people your public key bitcoin address, and it can still be used to send receive Bitcoins too.

(Is that right?)

Fixed that for you.

With all the scribbles it's difficult to tell what you meant. But it's also not incorrect to say that a public key has a corresponding private key.

And yet if you pay attention, you'll see that the scribbled scratch out all the stuff he got wrong, and the bold replaces it with the correct info.

For those who are finding it difficult to see what it says:

each bitcoin address has corresponding private key.  You could have an "off-line" wallet, by writing down your private key and bitcoin address, and then deleting whatever you used to create them (which might be a wallet file(?)).  You could then import both your keys at some point in the future into some Bitcoin wallet software, and access your bitcoins again.  In the meanwhile, you can still give people your bitcoin address, and it can still be used to receive Bitcoins.

(Is that right?)

Yes, it is accurate that each public key has a corresponding private key, but I think it is clear from context that the OP was attempting to ask about bitcoin addresses.

[acoindr]

With all the scribbles it's difficult to tell what you meant. But it's also not incorrect to say that a public key has a corresponding private key. I mean, a Bitcoin address is a just a base58 representation of the ripemd160 hash of the sha256 hash(double) of the public key + checksum whereas the private key is just base58 encoded.

Right.

Most casual users won't go this deep, so hopefully nobody gets confused. It's fine to think of Bitcoin as simply having two parts: a public component, and private component. The world can know your public component and not be able to access your coins. As long as you protect your private component (private key) your coins are safe.

However, technically it goes: private key -> public key -> final public Bitcoin address

More info: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses

[DannyHamilton]

Why was the system designed with these features? It was subject to some debate even among the devs when I was trying to get a handle on things some years ago. The devs seemed fairly universally confused and also somewhat irritated.  It may have been a somewhat aborted attempt at privacy.  Or the designer may have had thoughts of how clean-up of the blockchain might be accomplished (by draining to zero addresses and thus allowing them to be purged.)  Or some combination.  Or something else.

While most of tvbcof's response was accurate and useful.  I'm having a harder time understanding what he's trying to say here.  It is not clear to me what "features" he is talking about when he asks "Why was the system designed with these features?"

Malleability is a byproduct of the mathematics that are used for digital signatures.

The average 10 minute block time was chosen as a compromise between expediency and network latency.

Using a new address for every transaction increases security and privacy.

[DannyHamilton]

Technically, a single public/private key pair can be thought of as an account.

At the casual user level, this is fine.  If you are trying to understand the technical details of how bitcoin works, ignore this statement.  It tends to lead to confusion as you discover that the bitcoin protocol doesn't treat addresses like accounts at all.

[adds]

Thanks Guys.

This has been both very helpful and extremely interesting.

With regards to the private key / public key / Bitcoin address thing, are we saying:

1) A Bitcoin address can be calculated from a public key,
2) A public key can be calculated from a private key.

So the *only* thing one needs to worry about (from a backup point of view, and for each Bitcoin address) is it's corresponding private key, which *must* be kept secure - Presumably this is one of those calculations such as 10 * 3 (always) = 30, but 30 could be derived from a number of different calculations (1 * 30, 2 * 15, 3 * 10 etc). - Except obviously slightly more complex than that :-)

So, sometimes when I send Bitcoins, behind the scenes, I'm actually sending more, and waiting for change (just as I would in the local store with paper money).  However, when that chance comes back, it may/will go into a new Bitcoin address which I wasn't previously aware of.

Does that mean that if I'm using cold storage, it's not good enough to simply restore the private key, spend some Bitcoins, and take it off-line again, as I may find more has gone *from that Bitcoin address* than I was expecting - Unless I sweep(?) all Bitcoins to the same address.

I think I'm starting to understand! Thanks :-)

[DannyHamilton]

Thanks Guys.

This has been both very helpful and extremely interesting.

With regards to the private key / public key / Bitcoin address thing, are we saying:

1) A Bitcoin address can be calculated from a public key,
2) A public key can be calculated from a private key.

So the *only* thing one needs to worry about (from a backup point of view, and for each Bitcoin address) is it's corresponding private key, which *must* be kept secure -

Correct.

Presumably this is one of those calculations such as 10 * 3 (always) = 30, but 30 could be derived from a number of different calculations (1 * 30, 2 * 15, 3 * 10 etc). - Except obviously slightly more complex than that :-)

Quite a bit more complex than that, but yes.  It is a calculation that can be done very quickly in one direction (elliptic curve point multiplication), and is prohibitively slow in the other direction (elliptic curve point division).

So, sometimes when I send Bitcoins, behind the scenes, I'm actually sending more, and waiting for change (just as I would in the local store with paper money).

Not just sometimes.  Usually.

However, when that chance comes back, it may/will go into a new Bitcoin address which I wasn't previously aware of.

That depends on the wallet program you are using to create the transactions.  Bitcoin-Qt will always create a new address to send the change to.  It keeps this new address hidden from you.  Other wallets choose other ways of handling what address receives the change.

Does that mean that if I'm using cold storage, it's not good enough to simply restore the private key, spend some Bitcoins, and take it off-line again, as I may find more has gone *from that Bitcoin address* than I was expecting

Correct.  If you are using Bitcoin-Qt to import the private key, then you will likely lose significant amounts of bitcoins if you don't send the entire balance to an address with a known/stored private key before deleting the wallet.  The safest thing to do is to consider any private key that has been imported from a paper wallet to be no longer secure.  Create a new paper wallet, and send the entire balance of the wallet to the new paper wallet before deleting.

I think I'm starting to understand! Thanks :-)

You are definitely making progress.  Note that this discussion us mostly about implementation details in the Bitcoin-Qt wallet.  Most of this isn't specified in the bitcoin protocol, and is left up to the wallet creator to decide how they want their wallet to handle things like change, backups, and generating keys.

[tvbcof]

Why was the system designed with these features? It was subject to some debate even among the devs when I was trying to get a handle on things some years ago. The devs seemed fairly universally confused and also somewhat irritated.  It may have been a somewhat aborted attempt at privacy.  Or the designer may have had thoughts of how clean-up of the blockchain might be accomplished (by draining to zero addresses and thus allowing them to be purged.)  Or some combination.  Or something else.

While most of tvbcof's response was accurate and useful.  I'm having a harder time understanding what he's trying to say here.  It is not clear to me what "features" he is talking about when he asks "Why was the system designed with these features?"

Ya, I started to ramble a bit.

By 'feature', I meant the somewhat surprising scenario where one actually spends more than they intend but get 'change' back.  A more straightforward approach would be to simply send the desired amount.

The strongest hypothesis on why this design was choose by the inventor was that it was an attempt at fostering privacy.  If so, however, it was only marginally successful.  True, it did slow down analysis by smaller parties, but probably not much for lager ones.  That result is useful, but also problematic in that it produces a false sense of privacy.

Another hypothesis is that by habitually re-formulating value assignments methods of optimization could be developed.  I think from the get-go there was some efforts to police up dust transactions and reduce certain values to zero.  The author had some ideas about resource usage via Merkle tree pruning and such as described in the whitepaper document, but they were never really followed up on in later developments as best I can see.

Malleability is a byproduct of the mathematics that are used for digital signatures.

It's worth note that there are several things which can provoke the malleability 'issue'.  (That is, the transaction ID as computed by the spender not matching that which was accepted into the blockchain (though the spend values are right.))  One of them was associated with the implementation of OpenSSL which the author relied heavily upon and I tend to suspect that he was not aware of it.

The average 10 minute block time was chosen as a compromise between expediency and network latency.

My point was that waiting for a block cycle is something that does not fit with a lot of the use-cases that many economic players wish to use Bitcoin for.  It is seen as limiting (and is) and thus a lot of work-arounds are employed.  One of the work-arounds is to basically ignore the issue.  The other was to try to use the Transaction ID...and that is where the malleability issue bit people who were unaware of it in the ass.  When it started to be used as a systematic attack at least.
[/quote]

Using a new address for every transaction increases security and privacy.

I wish it would work even better, but it's an extremely difficult problem to solve in an encompassing manner.  There were a lot of problems to solve in getting Bitcoin functional enough for release and a lot of them conflict with the goal of privacy.  And it seems that there was limited development resources.

[DannyHamilton]

By 'feature', I meant the somewhat surprising scenario where one actually spends more than they intend but get 'change' back.  A more straightforward approach would be to simply send the desired amount.

The strongest hypothesis on why this design was choose by the inventor was that it was an attempt at fostering privacy.  If so, however, it was only marginally successful.  True, it did slow down analysis by smaller parties, but probably not much for lager ones.  That result is useful, but also problematic in that it produces a false sense of privacy.

Another hypothesis is that by habitually re-formulating value assignments methods of optimization could be developed.  I think from the get-go there was some efforts to police up dust transactions and reduce certain values to zero.  The author had some ideas about resource usage via Merkle tree pruning and such as described in the whitepaper document, but they were never really followed up on in later developments as best I can see.

I thought the current transaction design was a byproduct of creating a trustless system.  It allows any new user to enter the system and check for themselves that every transaction is valid.  If the system only maintained total balances (instead of specific spent and unspent outputs), then there would be no way for a new user to bootstrap their system without having to rely on a trusted source of current balances.  That single trusted source of current balances becomes a point of complete centralization.