How does wallet.dat work?

[rupy]

Ok, one last thing: if the wallet stores "only" the private keys, why does the wallet.dat filesize change upon every transaction to an address in it? It stores some reference to transactions there? Because you can make payments to an address in a wallet that isn't online without problems right?

[1715342255]

1715342255

[1715342255]

1715342255

[memvola]

Ok, one last thing: if the wallet stores "only" the private keys, why does the wallet.dat filesize change upon every transaction to an address in it? It stores some reference to transactions there?

Yes, it stores the transaction passively. The client is able to scan the blockchain to re-discover these transactions (the -rescan command-line option forces this), but storing them in the wallet is more convenient.

Because you can make payments to an address in a wallet that isn't online without problems right?

Of course. The private key can even be on paper or even in your head.

[rupy]

Ok, thanks! I think I get everything about bitcoin now!

But so there must be a chance in one gazillion that two private keys generate the same public key hash no?

Yes the odds are 1 in 2^256 however what really matters is that the odds of two public keys producing the same address (which is a 160bit hash of the public key with other meta data like version and checksum) are 1 in 2^160.  Note even the 1 in 2^160 is a very small number and for all practical purposes it can be considered 0%.

I understand the probability, but say you have all your savings on an address, and, god forbid, someone else "mints" an address that has the same public key, isn't that really HORRIBLE?! How would/could the system then help the real owner of these coins?

So I guess the only real hedge is to spread coins over many addresses?

I mean putting enough energy behind trying to generate an address with alot of coins on it would make sense if bitcoin value rises higher!

the public key is [0-9a-zA-Z] so its not really 2^160 right? It's 32 characters with 10+28+28 mutex no?

[memvola]

I understand the probability, but say you have all your savings on an address, and, god forbid, someone else "mints" an address that has the same public key, isn't that really HORRIBLE?! How would/could the system then help the real owner of these coins?

There are no real owners of coins. Having the only person/entity with the private key is the closest you can get to ownership with Bitcoin.

Having said that, if you think it is possible, you probably haven't grasped the improbability yet. This comes up pretty often, so you can search the forums to find very nice and funny analogies to explain the situation.

Basically, if 1 billion people began generating addresses at the rate of 1 million addresses per second, in about a century they would generate a total of 2⁸¹ addresses. 2¹⁰⁷ addresses until the death of our sun. Of course these aren't unique addresses, so you will never have all addresses at this speed. It might feel as if you could be unlucky enough to have your private key discovered in your lifetime, but you really aren't. The probability of you getting kidnapped and beaten until you reveal your password is much much higher.

So I guess the only real hedge is to spread coins over many addresses?

This is a good measure, not only because your private key might accidentally get generated (it won't), but as a general precaution. If you store money in various private keys and divide them with separate access restrictions, it will make it harder for attackers to access all your money, even through physical torture. A more sci-fi scenario is; if an address never initiated a transfer, its public key is not revealed, which makes it practically immune to quantum computing attacks that we know can be possible in the far future; so the true paranoid might want to store their savings in virgin addresses.

the public key is [0-9a-zA-Z] so its not really 2^160 right? It's 32 characters with 10+28+28 mutex no?

A public key is 256 bits. An address is a 160-bit hash of the public key, plus version and checksum. What you are describing seems to be the encoding, which can be 27-34 characters long.

[DannyHamilton]

the public key is [0-9a-zA-Z] so its not really 2^160 right? It's 32 characters with 10+28+28 mutex no?

The public key is a 32 byte (256 bit) integer.  So that part is 2²⁵⁶.

The bitcoin address on the other hand is built off of a 20 byte (160 bit) hash of the public key.

This results in 2¹⁶⁰ possible addresses (1.46 x 10⁴⁸).

Then a 1 byte version number is tacked on to the front of the address, and a 4 byte checksum is appended to the end, resulting in a 25 byte number.

This 25 byte number is then encoded with Base58Check encoding using [1-9,A-H,J-N,P-Z,a-k,m-z] (note that 0, I, O, and l are not used).

That encoding typically results in 33 or 34 characters made up of 58 different symbols.

34⁵⁸ = 6.7 x 10⁸⁸.  You'll notice that is significantly larger than 2¹⁶⁰.  This is because 5 bytes (the version and the checksum) are dependent on the 160 byte hash.  There are many combinations of [0-9,A-Z,a-z] that are not valid bitcoin addresses, leaving only 1.46 x 10⁴⁸ that any well written wallet will recognize.

[DeathAndTaxes]

I understand the probability, but say you have all your savings on an address, and, god forbid, someone else "mints" an address that has the same public key, isn't that really HORRIBLE?!

You could also die tomorrow getting eaten by a shark while struck by lightning in a desert.  The odds of that are probably higher than a 160 bit collision.  You could also buy one ticket, win the powerball lottery jackpot, next day buy a ticket win that powerball lottery jackpot, next day buy another ticket win that powerball lottery jackpot, next day buy a ticket, win that jackpot, next day buy a ticket, buy that jackpot, next day buy a ticket, win that jackpot, next day buy a ticket, win that jackpot.  The odds of doing that is more probably than generating a 160bit collision.

the public key is [0-9a-zA-Z] so its not really 2^160 right? It's 32 characters with 10+28+28 mutex no?

Well not exactly. The address isn't the public key.  The address is a checksummed hash of the public key.

So in Bitcoin you have:
* private key - 256 bit number
* public key - 512 bit ECDSA (x,y pair) -essentially a number
* public address - 200 bits (8 bit version identifier) + (160 bit hash of public key) + (32 bit checksum - to prevent sending funds to invalid addresses)

Public addresses are simply 200 bit numbers.  We put them into Base58 format to make them human readable but they are just numbers to the network.  

All three of the following numbers are the same and represent a bitcoin address, they are just in different formats.

00010966776006953D5567439E5E39F86A0D273BEED61967F6 (in hexadecimal)

0110011101110110000000000110100101010100000000000000000000000000
0110101000001101001001110000000000000000000000000000000000000000 (in binary)

16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM (in Base58 format)

The Base58 is the most human readable (and compact) but all three formats have the same value.

Someone made this awesome graphic to show the details


More details:
https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

[DannyHamilton]

. . .
* public key - 256 bit ECDSA (x,y pair) -essentially a number
. . .

Don't "compressed key" addresses just use half of that pair?  The pair together (as indicated in your graphic) is 512 bits, but in the case of a compressed key address, only one of the 2 values is represented (and therefore only 256 bits), right?

[DeathAndTaxes]

Typos typos typos.  Your right Danny.  Although the compressed key is more than just the y value (32 bytes).  It also includes a byte to indicate which side of the curve the point lies on (ECDSA curve is like a U so a single y value can represent two points).

The protocol itself isn't aware of compressed keys and to make it aware would require a hard fork.  All that potential bandwidth and storage savings wasted.  Even if a compressed key is used in the client it is converted to a full key when creating a transaction on the network. - Incorrect.

[kjj]

Typos typos typos.  Your right Danny.  I learned that even compressed keys have are more than 256 bits.  It is the x value plus a flag which allows the client to identify it as such (and know if it is positive or negative y value).  I intended to leave compressed public keys out of the discussion so I should have wrote 512 bit (corrected).

The protocol itself isn't aware of compressed keys and to make it aware would require a hard fork.  All that potential bandwidth and storage savings wasted.  Even if a compressed key is used in the client it is converted to a full key when creating a transaction on the network.

No it isn't.  We pass the pubkey as a binary blob to openssl, and openssl will validate the signature using either form.  The same private key can actually correspond to two different addresses, because the hash of the compressed pubkey is different from the hash of the uncompressed pubkey.

[DeathAndTaxes]

Thanks for the clarification on how protocol handles both key forms.

When you said "no it isn't" that didn't refer to the key size did it?  My understanding is that compressed keys are 33 bytes. 32 bytes for y-value plus another byte to indicate which "side" of the curve the point is located on.

On edit:

More info on compressed keys (including wrong answer about compressed keys being incompatible with the protocol)
http://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key