By the end of this post, readers will be able to:

• Summarize asymmetric and symmetric cryptography.
• Describe the process in which digital signatures authorize blockchain transactions.
• Evaluate the roles of hot and cold wallets.
• Detail how wallets use public- and private-key pairs and store cryptocurrency.
• Articulate the role of Bitcoin improvement proposals (BIPs), specifically BIP-39 and BIP-44, and how to use them to generate mnemonic phrases.
• Develop an Ethereum account by using BIP-44, BIP-39, and Python.
• Use mnemonic phrases and Web3.py to create a verifiable transaction.
• Create, sign, and send a transaction using a Ethereum account.

Blockchain developers have created a mechanism for identifying participants in a blockchain and associating those identities with transactions: the digital signature.

A participant’s digital signature proves that they authorized a given transaction on the blockchain.

Cryptography and Wallets

Symmetric cryptography essentially means that for one lock, there is one key. This one-to-one relationship provides the symmetry. Blockchain needs a way to share confidential data without having to also share the data’s password, or key. This is where asymmetric cryptography comes in.

Asymmetric cryptography splits up the key into a key pair. Each key pair includes a public key and a private key. Blockchain leverages public-private key pairs to create secure digital signatures for all network participants.

A blockchain participant uses their wallet to store their private key, confirm their cryptocurrency balance, create cryptocurrency transactions, and then authorize the transactions using their private key.

After the transaction has been created and authorized from within the wallet, it is sent to the blockchain. Then, it waits in the mempool to be validated by a miner and added to a new block on the chain.

Hardware wallets store the cryptographic keys inside of a special chip. Some hardware wallets are cold wallets. This type of wallet rarely, if ever, connects to the internet. The keys stored in a hardware wallet are completely disconnected from the digital world, except in the rare moments when they are used to withdraw or transact with the participant’s funds.

A hot wallet, on the other hand, is a digital wallet that connects to the internet directly through a computer or cell phone. A hot wallet can be a software application on your phone or computer, or it can be a hardware wallet that connects to the internet via the USB port on your computer.

The following image visualizes the differences between a hot wallet and a cold wallet:

Generating a Private Key

A BIP is a proposed standard that would alter current Bitcoin protocols or processes. In other words, it proposes changes to the protocol. The procedure that’s used to generate a mnemonic seed phrase, which is used to generate a private key, involves two different BIPs (BIP-39 and BIP-44). Like many aspects of Bitcoin, many BIPs are also adopted by other blockchains, including Ethereum.

BIP-39 sets a standard for using a mnemonic phrase, or seed phrase, which serves as a backup that can recover your private key if your wallet is compromised, lost, or destroyed.

BIP-39 includes a list of 2,048 words that can be included in seed phrases. To generate a seed phrase, a digital wallet typically selects either 12 or 24 words from this list at random.

The following steps highlight how the seed phrase generates the private key on the Ethereum blockchain.

• The first step is to derive a private key from a seed phrase using BIP-44, which is similar to BIP-39.
• BIP-44 will convert the seed phrase to a corresponding private key that can be used to authorize transactions on a blockchain network.
• Remember, blockchain participants store private keys in their wallets. Like BIP-39, BIP-44 was designed for hierarchical deterministic wallets, or HD wallets.
• HD wallets automatically generate the public-private key pair from the seed phrase rather than having the user do it manually.

Signing and Verifying Messages with Web3.py

Use the Web3.py library and include the encode_defunct function from the eth_account.messages module. An instance of w3 will also need to be imported using Web3.py’s auto function.

import os
from dotenv import load_dotenv
load_dotenv()
from mnemonic import Mnemonic
from bip44 import Wallet
from web3 import Account
from web3.auto import w3
from eth_account.messages import encode_defunct

mnemonic = os.getenv("MNEMONIC")

type(mnemonic)

private, public = wallet.derive_account("eth", account=0)
private

account = Account.privateKeyToAccount(private)

print(account.address)

• dotenv will hide the mnemonic phrase.
• Mnemonic to produce the phrase.
• web3 to talk to blockchain.
• Wallet to produce the wallet.

After writing a message, the next step is to encode it from a text format into a byte format. In a byte format, the message can be read by computers and signed using our private key.

message = encode_defunct(text=msg)

Sign the message using the w3.eth.account.sign_message function. This function accepts the message as the first argument and the private key as an argument named private_key. Then, it returns the encoded, signed message.

signed_message = w3.eth.account.sign_message(message, private_key=private)

signed_message

The SignedMessage object consists of several parts:

• The signature consists of a HexBytes hash code. Together, the r, s, and v variables that the object contains can be used to independently verify the signature.
• To validate this transaction’s signature against our public key, we must call w3.eth.account.recover_message().

Pass this function our original encoded message as well as the digital signature contained within our SignedMessage object.

w3.eth.account.recover_message(message, signature=signed_message.signature)

This returns the account address (a shortened version of the public key) of the participant who signed the message.

• Only the participant whose private key pairs with the message public key (and therefore, the account address) could have signed the message.
• The value returned from the recover_message function should match the value of the account.address function associated with the participant's Ethereum account. If they match, then we’ve verified who sent the message.

Congrats! You’ve learned how to sign and send authorized transactions from your local machines to an Ethereum blockchain node.

Until next time, here’s a twitter thread summary of this post:

https://twitter.com/jackofcrypto/status/1475241566721568771?s=20