Keys & Addresses - Obsidian Publish

- Cryptography can also be used to prove knowledge of a secret without revealing that secret (*digital signature*) or prove the authenticity of data (*digital fingerprint*) **Introduction** - Ownership of bitcoin is established through: - Digital keys - These are not actually stored in the network - They are created and stored by users in a wallet - Completely independent of the bitcoin protocol - Enable decentralized trust and control, ownership attestation, and the cryptographic proof security model - Bitcoin addresses - Digital signatures - Most bitcoin transactions require a valid digital signature to be included in the blockchain - The digital signature to spend funds is referred to as a witness - In the payment portion of a bitcoin transaction, the recipients public key is represented by its digital fingerprint (called bitcoin address) - In most cases, a bitcoin address is generated from and corresponds to a public key - However not all bitcoin addresses represent public keys; they can also represent other beneficiaries such as scripts **Public Key Cryptography and Cryptocurrency** - Bitcoin uses elliptic curve multiplication as its bases for its cryptography - There is a mathematical relationship between public and private key that allows the private key to be used to generate signatures on messages - This signature can be validated against the public key without revealing the private key - Signature is different each time but created from the same private key - Through the presentation of the public key and signature, everyone in the bitcoin network can verify and accept the transaction as valid - Confirming that the person transferring the bitcoin owned them at the time of transfer ![[Pasted image 20241205170946.png]] Why Asymmetric Cryptography? - It is not used to encrypt transactions, but the useful property is instead to generate digital signatures - A private key can be applied to the digital fingerprint of a transaction to produce a numerical signature - This signature can only be produced by someone with knowledge of the private key - Anyone with access to the public key and the transaction fingerprint can use them to verify the signature - The useful property of asymmetric cryptography is to make it possible for anyone to verify every signature on every transaction, while ensuring that only the owners of private keys can produce valid signatures ### Private Keys - Simply a number picked at random - Used to create signatures that are required to spend bitcoin proving ownership of funds used in a transaction **Generating a Private Key from a Random Number** - The first step in generating keys is to find a secure source of entropy (randomness) - Creating a bitcoin key is essentially the same as picking an number $\in \{1, \dots, 2^{256}\}$ - More precisely, the private key can be any number between $1$ and $n-1$ where $n$ is a constant (slightly less than $2^{256}$) defined as the order of the elliptic curve used in bitcoin - To create such a key, we randomly pick a 256-bit number and check that it is less than $n-1$ - In programmatic terms, this is usually achieved by feeding a larger string of random bits (collected from a cryptographically secure source of randomness) into the SHA256 hash algorithm, which will conveniently produce a 256 bit number - Do not use a "simple" random number generator - Use a cryptographically secure pseudorandom number generator (CSPRING) with a seed from a source of sufficient entropy - Bitcoin's key space is $2^{256} \approx 10^{77}$ while the entire visible universe is estimated to contain $10^{80}$ atoms ### Public Keys - Calculated from the private key using elliptic curve multiplication which is irreversible - $K=kG$ - Private key $k$ - Generator point $G$ - Public key $K$ - The reverse operation is known as "finding the discrete logarithm" - i.e. calculating $k$ if you know $K$ - As difficult as trying all possible values of $k$ i.e. brute force search - Elliptic curve multiplication - Known as a "trap door" function - Easy to do in one direction (multiplication) - Impossible to do in the reverse direction (division) - Owner of the private key can easily create the public key and share it knowing no one can reverse the function and calculate the private key **Elliptic Curve Cryptography** - Based on the discrete logarithm problem as expressed by addition or multiplication on the points of an elliptic curve - Bitcoin uses a specific elliptic curve and set of mathematical constants as defined in the standard called **secp256k1** established by NIST - The secp256k1 curve is defined by the following function - $y^{2} = x^{3}+7$ over $\mathbb{F}_{p}$ - or - $y^{2} \,\,\text{mod}\,\, p = x^{3}+7 \,\,\text{mod}\,\, p$ - Where $p=2^{256}-2^{32}-2^{9}-2^{8}-2^{7}-2^{6}-2^{4}-1$ is a very large prime number - Given a point with $(x,y)$ coordinates which lie upon the secp256k1 curve, you can verify that this point does lie on the curve via calculating: - (x ** 3 + 7 - y ** 2) % p - and verifying this $=0$ - Given 2 points on the elliptic curve $P_{1}$ and $P_{2}$, then there is a third point $P_{3}=P_{1}+P_{2}$ also on the elliptic curve - Geometrically, this third point $P_{3}$ is calculated by drawing a line between $P_{1}$ and $P_{2}$ - This line will intersect the elliptic curve in exactly $1$ additional place - Call this point $P_{3}'$ and then reflect over the x-axis to get $P_{3}=(x,-y)$ - There are a couple of special cases that explain the need for the "point at infinity" - If $P_{1}$ and $P_{2}$ are the same point, then the line between both should extend to be the tangent on the curve at this point, and this tangent will intersect the curve in exactly 1 new point - If $P_{1}$ and $P_{2}$ have exactly the same x values but different y values, the tangent line will be vertical in which $P_{3}$ = "point at infinity" - If $P_{1}$ is the point at infinity, then $P_{1}+P_{2}=P_{2}$ - Addition is associative - For a point $P$ on the elliptic curve, if $k$ is a whole number, then $kP = P + P + \dots + P$ (k times) - note that $k$ is confusingly sometimes called the exponent in this case **Generating a Public Key** - Starting with the private key in the form of a randomly generated number $k$ - We multiply it by a predetermined point on the curve called a *generator point* $G$ to produce another point somewhere else on the curve i.e. the corresponding public key $K$ - The generator point is specified as a part of the secp256k1 standard and is always the same for all keys in bitcoin - $K=kG$ - Since the generator point is always the same for all bitcoin users, a private key $k$ multiplied with $G$ will always result in the same public key $K$ - The relationship between $k$ and $K$ is fixed but can only be calculated in one direction (from $k$ to $K$) - This is why a bitcoin address (derived from $K$) can be shared with anyone and does not reveal the user's private key $k$ - Implementing the elliptic curve multiplication, we take the private key $k$ generated previously and multiply it with the generator point $G$ to find the public key $K$ - $K = \text{1E99423A...26AEDD} \cdot G$ - Public key is defined as a point $K=(x,y) = (\text{F02889...341A, 07CF33...5BDB})$ - To visualize the multiplication of a point with an integer, we will use the simpler elliptic curve over real numbers - Goal is to find the multiple $kG$ of the generator point $G$, which is the same as adding $G$ to itself $k$ times - In elliptic curves, adding a point to itself is equivalent of drawing a tangent line on a point, and finding where it intersects the curve again, then reflecting that point on the x- ![[Pasted image 20241205182040.png]] ### Bitcoin Addresses - Addresses produced from public keys consist of a string of numbers and letters beginning with digit $1$ - Bitcoin addresses are very flexible - They can represent the owner of a private/public key pair - They can represent a payment script - The bitcoin address is derived from the public key through the use of 1-way cryptographic hashing - Hash algorithm is a 1-way function that produces a fingerprint or "hash" of an arbitrarily sized input - Hash functions are used in bitcoin addresses, script addresses and in the mining PoW algorithm - The algorithms used to make a bitcoin address from a public key are the Secure Hash Algorithm (SHA) and the RACE Integrity Primitives Evaluation Message Digest (RIPEMD) - SHA256 and RIPEMD160 - Starting with public key $K$, we compute the SHA256 hash and then compute the RIPEMD160 hash, producing a 160-bit (20-byte) number - Bitcoin addresses are almost always encoded as "Base58Check" which uses 58 characters (a base 58 number system) and a checksum to help human readability, avoid ambiguity, and protect against errors in address transcription and entry - Base58Check is also used in many other ways in bitcoin, e.g. whenever there is a need for a user to read and correctly transcribe a number such as a bitcoin address, private key, encrypted key, or script ![[Pasted image 20241205183834.png]] **Base58Check Encoding** - Base64 is most commonly used to add binary attachments to email - Base58 is a text-based binary encoding format developed for use in bitcoin and used in many other cryptocurrencies - Removes 0, O, l, I, +, / since they can be hard to correctly read sometimes - To add extra security against typos or transcription errors, Base58Check is a Base58 encoding format frequently used, which has a built in error checking code - The checksum is $4$ additional bytes added to the end of the data that is being encoded - It is derived from the hash of the encoded data and can be used to detect and prevent transcription and typing errors - When presented with a Base58Check code, the decoding software will calculate the checksum of the data and compare it to the checksum included in the code - If the 2 do not match, an error has been introduced and the Base58Check data is invalid - This prevents a mistyped bitcoin address from being accepted by the wallet software as a valid destination - To convert data (a number) into a Base58Check format, we first add a prefix to the data called the "version byte" which serves to easily identify the type of data that is encoded - e.g. bitcoin addresses have prefix zero (0x00 in hex) - e.g. prefix for encoding a private key is 128 (0x80 in hex) - Next, we compute the "double-SHA" checksum i.e. SHA256 twice - From the resulting $32$ byte hash (hash of a hash), we take only the first $4$ bytes - These will serve as a error checking code i.e. checksum ![[Pasted image 20241205185217.png]] - In bitcoin, most of the data presented to the user is Base58Check encoded to make it compact, easy to read, and easy to detect errors - The version prefix in Base58Check encoding is used to create easily distinguishable formats, which when encoded in Base58 contain specific characters at the beginning of the Base58Check encoded payload - These characters make it easy for humans to identify the type of data that is encoded - This is what differentiates e.g. a Base58Check encoded bitcoin address that starts with a $1$ from a Base58Check encoded private key WIF that starts with a $5$ - Bitcoin Address $\rightarrow$ Base58 prefix $1$ - Pay-to-Script hash address $\rightarrow$ Base58 prefix $3$ - Bitcoin Testnet address $\rightarrow$ Base58 prefix $m$ or $n$ - BIP-38 Encrypted Private key $\rightarrow$ Base58 prefix 6P Example - We can look at the complete process of creating a bitcoin address, from a private key, to a public key (a point on the elliptic curve), to a double-hashed address, and finally the Base58Check encoding - Example Code in C++ - c.f. page 69 ### Key Formats - Keys can be represented in a number of different formats which all encode the same number, even though they look different - These formats are primarily used to make it easy for people to read and transcribe keys without introducing errors **Private Key Formats** - The private key can be represented in a number of different formats all of which correspond to the same 256-bit number - Raw data is 32 bytes - Hex data is 64 hexadecimal digits - WIF data is Base58Check encoded (Base58 with version prefix of 128- and 32-bit checksum) - WIF-compressed data as above with added suffix 0x01 before encoding - Hexadecimal and raw binary formats are used internally in software and rarely shown to users - WIF is used for import/export of keys between wallets and often used in QR code representations of private keys - Encoding from Hex to Base58Check - If I take my hexadecimal payload and append a 01 suffix, then the command in Bitcoin Explorer knows to compress - The resulting WIF-compressed format will then start with a "K" - This denotes that the private key within has a suffix of "01" and will be used to produce compressed public keys only **Public Key Formats** - A public key is a point on the elliptic curve consisting of a pair of coordinates $(x,y)$ - It is usually presented with the prefix $04$ followed by two 256-bit numbers - One for the x coordinate, one for the y coordinate - Prefix $04$ is used to distinguish uncompressed public keys from compressed public keys which begin with a $02$ or $03$ - e.g. coordinates - $x=\text{F02889}\dots \text{341A}$ - $y=\text{07CF33}\dots \text{5BDB}$ - e.g. $520$-bit number ($130$ hex digits) with prefix $04$ followed by $x$ and then $y$ - $K=\text{04F02889}\dots \text{5BDB}$ **Compressed Public Keys** - These were introduced to bitcoin to reduce the size of transactions and conserve disk space on nodes that store the bitcoin blockchain database - Most transactions include the public key, which is required to validate the owner's credentials and spend the bitcoin - Each public key requires 520 bits (prefix + $x$ + $y$) which when multiplied by several hundred transactions per block (or tens of thousands of transactions per day) adds a significant amount of data to the blockchain - Since the public key is a point on the elliptic curve, if we know the $x$ coordinate, then we can calculate the $y$ coordinate by solving the elliptic equation and store only the $x$ coordinate of the public key - Almost 50% reduction - *Uncompressed* public keys have a prefix of $04$ - *Compressed* public keys start with $02$ or $03$ prefix - There are 2 possible prefixes because the elliptic equation for $y^{2}$ involves a square root to solve it, and this can have positive or negative values - Visually this means that the resulting $y$ coordinate can be above or below the $x$ axis - Thus, while we can omit the $y$ coordinate, we have to store the *sign* of $y$ - When calculating the elliptic curve in binary arithmetic on the finite field of prime order $p$ the $y$ coordinate is either even or odd (which corresponds to positive or negative sign) - Thus we store $02$ if $y$ is even, and $03$ if $y$ is ![[Pasted image 20241205221605.png]] Example - e.g. Uncompressed public key - $K=$ 4F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A 07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB - e.g. Compressed public key - $K=$ F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A - If we convert a compressed public key to a bitcoin address using the double-hash function $\text{RIPEMD160}(\text{SHA256}(K))$, it will produce a *different* bitcoin address - This can be confusing because a single private key can produce a public key expressed in 2 different formats, compressed and uncompressed, which produce 2 different bitcoin addresses - Yet the private key is identical for both addresses - Compressed public keys are gradually becoming the default across bitcoin clients which is having a significant impact on reducing the size of transactions and therefore the blockchain - However, not all clients support compressed public keys yet - Newer clients that support compressed public keys must account for older clients which do not - This is especially important when a wallet application is importing private keys from another bitcoin wallet application because the new wallet needs to scan the blockchain to find transactions corresponding to these imported keys - Which bitcoin addresses should the bitcoin wallet scan for? - The bitcoin addresses produced by uncompressed or compressed public keys? - Both are valid and can be signed for by the private key but are different addresses - To resolve this issue, when private keys are exported from a wallet, the WIF that is used to represent them is implemented differently in newer bitcoin wallets, to indicate that these private keys have been used to produce *compressed* public keys and therefore *compressed* bitcoin addresses - This allows the importing wallet to distinguish between private keys originating from older or newer wallets and search the blockchain for transactions with bitcoin addresses corresponding to the uncompressed or compressed public keys rsp. **Compressed Private Keys** - Ironically a misnomer, because when a private key is exported as WIF-compressed, it is actually 1 byte longer because of an added suffix $01$ which signifies that the private key is from a *newer* wallet and should only be used to produce *compressed* public keys - Private keys themselves are not and cannot be compressed - "Compressed" private key means "private key from which only compressed public keys should be derived" - The correct nomenclature is "WIF-compressed" or "WIF" - Formats - Remember that these formats are not used interchangeably - In a *newer* wallet that implements compressed public keys, the private keys will *only* ever be exported as WIF-compressed (with $\text{K}$ or $\text{L}$ prefix) - In an *older* wallet the private keys will *only* ever be exported as WIF (with $5$ prefix) - The goal here is to signal to the wallet importing these private keys whether it must search the blockchain for compressed or uncompressed public keys and addresses **Summary** - If a bitcoin wallet is able to implement compressed public keys, it will use those in all transactions - The private keys in the wallet will be used to derive the public key points on the curve, which will be compressed - The compressed public keys will be used to produce bitcoin addresses and those will be used in transactions - When exporting private keys from a new wallet that implements compressed public keys, the WIF is modified with the addition of a 1-byte suffix $01$ to the private key - The resulting Base58Check-encoded private key is called "compressed WIF" and starts wit the letter $\text{K}$ or $\text{L}$ instead of starting with $5$ as is the case with WIF-encoded (non-compressed) keys from older wallets - Misnomer - Private keys are not compressed, rather, WIF-compressed signifies that the keys should only be used to derive compressed public keys and their corresponding bitcoin addresses - Ironically, a "WIF-compressed" encoded private key is 1-byte longer because of the added $01$ suffix to distinguish it from an "uncompressed" one ### Advanced Keys and Addresses - We will look at encrypted private keys, script and multisignature addresses, vanity addresses, and paper wallets **Encrypted Private Keys - BIP-38** - The need for confidentiality of private keys is a truism that is difficult to achieve in practice because it conflicts with the equally important security objective of availability - Keeping the private key private is harder when you need to store backups to avoid losing it - These conflicting security goals led to the introduction of a portable and convenient standard for encrypting private keys in a way that can be understood by many different wallets and bitcoin clients - standardized by BIP-38 - BIP-38 proposes a common standard for encrypting private keys with a passphrase and encoding them with Base58Check so that they can: - Be stored securely on backup media - Transported securely between wallets - Kept in any other conditions where the key might be exposed - The standard for encryption uses AES - BIP-38 encryption takes as input a bitcoin private key (usually encoded in WIF) as a Base58Check string with the prefix of "$5quot; - Additionally, it takes a *passphrase* composed of several words or complex string - The result is a Base58Check encoded encrypted private key that begins with the prefix "$6\text{P}quot; - Many wallet applications now recognize BIP-38-encrypted private keys and will prompt the user for a passphrase to decrypt and import the key - The most common use-case for BIP-38 encrypted keys is for paper wallets that can be used to back up private keys on a piece of paper - Incredibly secure **Pay-to-Script Hash (P2SH) and Multisignature Addresses** - We know traditional bitcoin addresses begin with the number "$1quot; and are derived from the public key which is derived from the private key - Although anyone can send a bitcoin to a "$1quot; address, the bitcoin can only be spent by presenting the corresponding private key signature and public key hash - Bitcoin addresses beginning with "$3quot; are pay-to-script hash (P2SH) addresses, sometimes *erroneously* called multisignature or multisig addresses - They designate the beneficiary of a bitcoin transaction as the hash of the script (instead of the owner of the public key) - The feature was introduced in January 2012 with BIP-16 and is being widely adopted because it provides the opportunity to *add functionality to the address itself* - Unlike transactions that "send" funds to traditional "$1quot; bitcoin addresses, also known as a pay-to-public-key-hash (P2PKH), funds sent to a "$3quot; address require something more than the presentation of one public key hash and one private key signature as proof of ownership - The requirements are designated *at the time* the address is created, within the script - *All* inputs to this address will be encumbered with the *same* requirements - A P2SH address is created from a transaction script, which defines who can spend a transaction output - Encoding of a P2SH address involves using the same double hash function as used during the creation of a bitcoin address, only applied on the script *instead of the public key* - $\text{script hash}=\text{RIPEMD160}(\text{SHA256}(\text{script}))$ - The resulting "script hash" is encoded with Base58Check with a version prefix of $5$, which results in an encoded address starting with a $3$ - e.g. $\text{3F6i6k}\dots \text{m1HM}$ - A P2SH is not necessarily the same as a multisignature standard transaction - A P2SH address *most often* represents a multisignature script - But, it might also represent a script encoding other types of transactions **Multisignature Addresses and P2SH** - The most common implementation of the P2SH function is the multisignature address script - Designed to require $M$ signatures (i.e. the "threshold") from a total of $N$ keys (i.e. the $M$-of-$N$multisig where $M\le N$) - e.g. Bob could use the multisignature address requiring 1-of-2 signatures from a key belonging to him and a key belonging to his spouse - Ensuring either of them could sign to spend a transaction output locked to this address - Similar to a "joint account" - e.g. Gopesh the web designer could have a 2-of-3 multisignature addresses for his business that ensures that no funds can be spent unless at least 2 of the business partners sign a transaction **Vanity Addresses** - Bitcoin addresses that contain human readable messages - e.g. $\text{1LoveBPzzD}\dots \text{NR33}$ - These require generating and testing billions of candidate private keys until a bitcoin address with the desired pattern is found (though there are some optimizations which are possible) - ![[Pasted image 20241210174425.png]] - Eugenia can outsource to a vanity pool the search for a seven-character pattern for $5 (at the time of writing) and get the results in a few hours **Vanity Address Secuirty** - Vanity addresses can be used to enhance *and* to defeat security measures - A distinctive address makes it harder for adversaries to substitute their own address and fool your customers into paying them instead of you - Unfortunately, vanity addresses also make it possible for anyone to create an address that resembles any random address (or even another vanity address) thereby fooling your customers - e.g. copying the first few characters - Though if you make the first part of your vanity address long enough, then it could be infeasible to do this **Paper Wallets** - Can be generated easily using a tool such as the client side JavaScript generator at bitaddress.org - To use it, save the HTML page on your local drive or external USB - Disconnect from internet and open the file in a browser - Boot your computer using a pristine OS such as CD-ROM bootable Linux OS - Any keys generated with this tool offline can be printed on a local printer over a USB cable thereby forgoing storage in any online system - Put this paper wallet in a fireproof safe and "send" bitcoin to their bitcoin address - Disadvantage are that printed keys are vulnerable to theft - You can use BIP-38 encrypted private keys - Although you can deposit funds into a paper wallet several times, you should withdraw all funds only once, spending everything - This is because in the process of unlocking and spending funds, some wallets might generate a change address if you spend less than the whole amount - Additionally if the computer to sign the transaction is compromised, you risk exposing the private key - Spending the entire paper wallet only once reduces the risk of key compromise - If you only need a small amount, send any remaining funds to a new paper wallet in the same transaction ------------------------------------------------------- # 3rd Edition **Bech32 Addresses** - In 2017, the bitcoin protocol was upgraded preventing transaction identifiers (txids) from being changed without the consent of a spending user (or a quorum of signers when multiple signatures are required) - Segwit addresses this by separating the digital signatures (witness) from the transaction data - by moving the witness data outside the main block, segwit effectively increases the block size limit allowing more transactions to be included in each block without a significant increase in size - The upgrade called *segregated witness* also provided additional capacity for transaction data in blocks and several other benefits - User's wanting direct access to segwit's benefits had to accept payments to new output scripts - One of the advantages of the P2SH output type was the at spender (Alice) did not need to know the details of the script the receiver (Bob) used - The segwit upgrade was designed to use this mechanism, allowing users to immediately begin accessing many of the new benefits by using a P2SH address - But for Bob to gain access to all of the benefits he would need Alice's wallet to pay him using a different type of script - At first, bitcoin developers proposed BIP142 which would continue using base58check with a new version byte (similar to the P2SH upgrade) but getting all wallets to upgrade to new scripts with a new base58check version was as much work as getting them to upgrade to an entirely new address format, so they identified several problems with base58check - Mixed case presentation made it inconvenient to transcribe (upper case and lower case) - It can detect errors, but cannot help use correct those errors - Mixed case alphabet requires extra space to encode in QR codes - Requires every spender wallet to support new protocol features like P2SH and segwit - Although the upgrades do not require much code, experience shows that many wallet authors are busy with other work and can delay upgrading for years - Developers working on an address format for segwit found solutions for each of these problems in a new address format called bech32 - Bech32 only uses number and a single case of letters - Despite the alphabet being almost half in size of base58check, a bech32 address for pay to witness public key hash (P2WPKH) script is only slightly longer than a legacy address for an equivalent P2PKH script - Bech32 can both detect and help correct errors - For an address of an expected length, it is mathematically guaranteed to detect any error affecting $4$ characters or less - For longer errors, it will fail to detect them less than one in a billion times (roughly the same reliability as base58check) - Bech32 is preferably written in lowercase letters, but changed to uppercase before QR encoding (for more efficient representation) - Bech32 takes advantage of an upgrade mechanism designed as part of segwit to make it possible for spender wallets to be able to pay output types that are not in use yet - The goal was to allow devs to build a wallet today that allows spending to a bech32 address and have that wallet remain able to spend to bech32 addresses for users of new features added in future protocol upgrades - It was hoped that we never again need to go through the system-wide upgrade cycles necessary to allow people to fully use P2SH and segwit **Problems with Bech32 Addresses** - Bech32 addresses would have been a success in every area except for one problem - The mathematical guarantees about their ability to detect errors only apply if the length of the address you enter into a wallet is the same length of the original address - If the length of the address is altered by e.g. adding or omitting characters, the checksum may not effectively detect errors - Though even without the guarantee, it was thought that it would be very unlikely that a user adding or removing characters would produce a string with a valid checksum **Bech32m** - Although bech32 worked well for segwit v0, devs did not want to unnecessarily constrain output sizes in later versions of segwit - Without constraints, adding or removing a single "q" in bech32 addresses could result in a user accidentally sending money to an output that was unspendable or spendable by anyone - Devs analyzed the bech32 problem and found that changing a single constant in their algorithm would eliminate the problem, ensuring that any insertion or deletion of up to 5 characters will only fail to be detected less often than once in a billion - All characters in bech32 and bech32m addresses for the same underlying data will be identical except for the last 6 (the checksum) - Bech32m addresses start with a human readable part (HRP) followed by a separator (number $1$ which is unused to prevent confusion with letter l) - The other part of a bech32m address is called the data part, of which there are 3 elements 1. Witness version - A single byte that encodes as a single character in a bech32m bitcoin address immediately following the separator - This letter represents the segwit version 2. Witness program - From 2 to 40 bytes, but for segwit v0 the witness program must either be 20 or 32 bytes and for segwit v1 the only defined length is 32 (though this may change) 3. Checksum - Exactly 6 characters using a BCH code Example ![[Pasted image 20241211181931.png]] - For the P2WPKH output, the witness program contains a commitment constructed in exactly the same way as the commitment for a P2PKH output - A public key is passed into a SHA256 hash function and the resultant 32-byte digest is then passed into a RIPEMD-160 hash function, and the digest of that function (the commitment) is placed in the witness program - For the P2WSH output, we do not use the P2SH algorithm - Instead, we take the script and pass it into a SHA256 hash function and use the 32 byte digest of that function in the witness program - For P2SH the SHA256 digest was hashed again with the RIPEMD-160, but that may not be secure in some cases c.f. P2SH Collision Attacks page 73 - As a result of using SHA256 without RIPEMD-160 is that P2WSH commitments are 32 bytes instead of 20 bytes - For the P2TR output, the witness program is a point on the secp256k1 curve - It may be a simple public key, but in most cases it should be a public key that commits to some additional data - Recall: Witness Program refers to the part of the transaction that contains the digital signature(s) and other data needed to validate the transaction i.e. the witness