Addresses

Understanding Bitcoin on a deep technical level

Disclaimer: Content is summarised from Chapter 3 of 'Grokking Bitcoin' by Kalle Rosenbaum

Contents:

3. Addresses • Cookie-eating habits disclosed

• Replacing names with public keys

• Shortening the public key

• Avoiding expensive typing errors

• Back to privacy

• Summary

3.1 Cookie-eating habits disclosed

E.g. Your coworkers & you have health insurance with Acme Insurances. Acme has persuaded John to give it a copy of the spreadsheet. Acme will adjust premiums or hold workers’ cookie-eating habits against them in an eventual insurance dispute. Note that on the spreadsheet, every coworker can look up other coworkers’ balances & their cookie- eating habits. How do we resolve this?

3.2 Replacing names with public keys

Lisa has been constantly updating the table of names & public keys since users started using digital signatures. To save time & improve privacy, Lisa will replace all names in the spreadsheet with their respective public keys

Users should no longer use names when making payments but use the sender’s public key & recipient’s public key. Payment is now pseudonymous: names are replaced with corresponding public keys.

New payment process

Company will send a new coworker Faiza 100 CT as a gift. The company needs the recipient’s, Faiza’s, public key. As Faiza hasn’t used CT, she needs to create a key pair & give the public key to the sender, the company.

Faiza creates a private & a public key but she doesn’t give her public key to Lisa. Instead, Faiza gives the public key to the entity that wants to pay her CT, the company.

Company creates a message asking Lisa to move 100 CT from 037e944a...36de9496 to 029a726c...ad8f436d & digitally signs the message & sends it to Lisa. Lisa uses

• The message

• The sender’s public key

• The signature

to verify that the message is signed with the private key belonging to the sender’s public key & she verifies that the sender’s public key has enough funds in the spreadsheet. These changes have improved privacy & simplified Lisa’s work: • Names have been replaced with public keys in the spreadsheet • Lisa has thrown away table of names and public keys • Payments are made using public keys instead of names to denote sender & recipient Note: Email to Lisa in probably reveals, to Lisa, who the sender is as the From field of the email. Think about what Acme Insurances can now figure out from the spreadsheet.

3.3 Shortening the public key (Hashing the public key to 20 bytes)

Some developers suggest replacing each public key in the CT spreadsheet with a cryptographic hash of the public key to shorten senders & recipients in the spreadsheet but also protect users’ money in the event of a flaw in the public key derivation function. The hashing is made with 2 different cryptographic hash functions.

Public key is first hashed with SHA256 & is then hashed with RIPEMD160 which outputs a 160-bit (20-byte) number. Final hash is the "public key hash (PKH)". All public keys in the spreadsheet are replaced with their respective PKHs. E.g. John wants to buy a cookie

John must use the cafe’s PKH as the recipient. Sender is still a public key in the message as that public key is needed to verify the signature. Lisa doesn’t keep people’s public keys around anymore. As spreadsheet now contains PKHs, Lisa must calculate the PKH from the sender’s public key to check the sender’s balance & be able to enter the payment into the spreadsheet.

Why SHA256 & RIPEMD160?

Using RIPEMD160 as last cryptographic hash function makes the PKHs shorter. Output from SHA256 vs output from RIPEMD160:

• SHA256: 85ae273f0aa730eddf2285d3f3ab071eb29caba1e428db90e6dfbd71b8e1e918

• RIPEMD160: 5f2613791b36f667fdb8e95608b55e3df4c5f9eb

We can only speculate why we have 2 different cryptographic hash functions for Bitcoin as its inventor, Satoshi Nakamoto, has stopped corresponding with the Bitcoin community

If either hash function isn’t pre-image-resistant, the other still is. Thus, if you can calculate an input to RIPEMD160 that gives a certain PKH output, you still need to pre-image attack SHA256 (with about 2255 guesses) to find the public key. If you can calculate an input to SHA256 that gives a certain output, you first need to pre-image attack RIPEMD160 before you can use that pre-image to calculate the public key.

But if output set of either cryptographic hash function is smaller than anticipated, then the security of the combined hash-function chain suffers. Pretend SHA256 has only 100 possible output values. You can steal money from anyone by trying different random private keys & calculating the corresponding PKHs. If a PKH matches your target, you’ve found a private key you can steal the money with. On average, you’d only have to test 50 different private keys to steal from one PKH. If either of the 2 functions is weak, the whole chain is weak. But probability that any function has this flaw is small. We’ve yet to find any collision in any of these cryptographic hash functions.

Note: RIPEMD160 was developed at a European university in open collaboration with a broad community of cryptographers while SHA256 was developed by the US National Security Agency (NSA).

Note: Using PKHs doesn’t hide personal info any more than using public keys.

3.4 Avoiding expensive typing errors

**When Lisa verifies a payment before executing it, she doesn’t care who the recipient is or if it’s even an existing recipient. She’ll put into the recipient column of the spreadsheet whatever the payer asks her to. She can’t even know if a recipient is valid or not, because she no longer knows everyone’s public keys.

This is convenient for Lisa, but it can cause people to lose money if they aren’t careful. Imagine once again that John wants to buy a cookie. This time, he’s not careful enough when writing the message, as figure 3.8 shows.