2. Why are public keys(33 bytes) longer than private keys(32 bytes)?
3. How does the verification process using the public and private keys work?
Soln- The message’s hash is encrypted using the private key by the sender, this is decrypted using the public key by the receiver.
If the decrypted hash code matches the original message’s hash code the sender is verified.
4. In case of a loop-hole in the public key derivation function, how is the private key protected as the public key is visible to
everyone?
Soln- Public keys directly are not listed in the spreadsheet, instead Public Key Hash(PKH) are listed. Public keys are doubly
hashed- by SHA256 and RIPEMD160 to generate shorter(20 bytes) PKHs which can easily to stored are protect the Private
keys to some extent.
5. How can we avoid burning i.e. transferring coins to a non-existing PKH?
Soln- The main reason of burning coins is typing errors in the PKH. To counter that a two-way function Base58check and
checksum is used. First a version “00”(1 byte) is added at the beginning of the PKH, then the 4 byte checksum is added at the
end. Checksum is the first 4 bytes of the doubly hashed(SHA256) PHK with the version. Now this is base58check encoded and
sent to the other user. The user at the other end will base58check decode, extract the checksum and verify it thus make typing
errors less likely.
6. How to store the seed efficiently and minimize the typing errors?
Soln- The 128-bit seed is stored using mnemonic sentences. Firstly a 4-bit checksum is added to the end of seed making it 132
bits. Now these bits are grouped into 12 groups of 11 bits. These groups are then mapped to the list of 2048 words resulting in
conversion of seed to 12 simple English words.
7. What is the need of generating tree of public keys using the wallet?
Soln- Sometimes we need to make the wallet accessible from a website to handle a large volume of input transactions, now the
problem is that giving access to all the private keys is quite vulnerable. Hence generating tree of public keys is a useful feature
provided by the HD wallets.
8. If the hardened private keys are more secure, why don’t they completely replace the normal xprv derivation? Are there any
caveats of using the hardened keys?
9. What is length-extension attack?
10. Isn’t there a security lapse when the public key is visible in the transaction?
Soln- The public key needs to be revealed to verify the signature but it is only revealed after spending the transaction’s input.
Due to this lapse everyone is advised to not reuse the key-pair. Later we replace the signature with proof of work hence public
key is not required.
11. What do you mean by Block ID?
Soln- Block ID is simply the doubly hashed block header.
12. What is the use of lightweight wallets?
Soln- Lightweight wallets are used to extract the partial Merkle tree for the set of transactions filtered by the bloom filter which
also includes some false positive. This helps the user to verify that the filtered transaction is present in the block.
13. Shouldn’t there be mechanisms to control the sensitivity of bloom filters i.e., increasing or decreasing the number of false
positive thus offering different levels of security?
14. Assume that in a split there are two branches- one with a lone block and other with a long chain. Now the miner of that lone
block abandons the block but does not mark its transactions as pending, so what happens to those transactions?
Name: Yash Bhanushali Book- Grokking Bitcoin: 01-08
Questions: 1. How are private keys generated?
2. Why are public keys(33 bytes) longer than private keys(32 bytes)?
3. How does the verification process using the public and private keys work? Soln- The message’s hash is encrypted using the private key by the sender, this is decrypted using the public key by the receiver. If the decrypted hash code matches the original message’s hash code the sender is verified.
4. In case of a loop-hole in the public key derivation function, how is the private key protected as the public key is visible to everyone? Soln- Public keys directly are not listed in the spreadsheet, instead Public Key Hash(PKH) are listed. Public keys are doubly hashed- by SHA256 and RIPEMD160 to generate shorter(20 bytes) PKHs which can easily to stored are protect the Private keys to some extent.
5. How can we avoid burning i.e. transferring coins to a non-existing PKH? Soln- The main reason of burning coins is typing errors in the PKH. To counter that a two-way function Base58check and checksum is used. First a version “00”(1 byte) is added at the beginning of the PKH, then the 4 byte checksum is added at the end. Checksum is the first 4 bytes of the doubly hashed(SHA256) PHK with the version. Now this is base58check encoded and sent to the other user. The user at the other end will base58check decode, extract the checksum and verify it thus make typing errors less likely.
6. How to store the seed efficiently and minimize the typing errors? Soln- The 128-bit seed is stored using mnemonic sentences. Firstly a 4-bit checksum is added to the end of seed making it 132 bits. Now these bits are grouped into 12 groups of 11 bits. These groups are then mapped to the list of 2048 words resulting in conversion of seed to 12 simple English words.
7. What is the need of generating tree of public keys using the wallet? Soln- Sometimes we need to make the wallet accessible from a website to handle a large volume of input transactions, now the problem is that giving access to all the private keys is quite vulnerable. Hence generating tree of public keys is a useful feature provided by the HD wallets.
8. If the hardened private keys are more secure, why don’t they completely replace the normal xprv derivation? Are there any caveats of using the hardened keys?
9. What is length-extension attack?
10. Isn’t there a security lapse when the public key is visible in the transaction? Soln- The public key needs to be revealed to verify the signature but it is only revealed after spending the transaction’s input. Due to this lapse everyone is advised to not reuse the key-pair. Later we replace the signature with proof of work hence public key is not required.
11. What do you mean by Block ID? Soln- Block ID is simply the doubly hashed block header.
12. What is the use of lightweight wallets? Soln- Lightweight wallets are used to extract the partial Merkle tree for the set of transactions filtered by the bloom filter which also includes some false positive. This helps the user to verify that the filtered transaction is present in the block.
13. Shouldn’t there be mechanisms to control the sensitivity of bloom filters i.e., increasing or decreasing the number of false positive thus offering different levels of security?
14. Assume that in a split there are two branches- one with a lone block and other with a long chain. Now the miner of that lone block abandons the block but does not mark its transactions as pending, so what happens to those transactions?