The Lightning Network uses payment pre-images and payment hashes as essential components of its Hash-Time-Locked Contract (HTLC). The HTLC is a smart contract that enforces a fairness protocol and allows for off-chain payment routing. The redemption clause is the “happy path” of the HTLC, executed if the payment succeeds. The clause allows the receiver to spend the coins locked in the contract by providing the secret value.

To spend the funds, the receiver must provide the secret, which is used as input to a mathematical function called SHA256. The output is compared to the fingerprint encoded in the invoice, and if they match, the receiver can spend the coins. The payment pre-image is the secret, while the payment hash is the fingerprint encoded in the invoice. The receiver generates the secret and computes its fingerprint for every payment in the Lightning Network.

Cryptographic hash functions prevent theft attempts through trial and error, even though an average computer can calculate 60 million hashes per second. Without these functions, the Lightning Network and Bitcoin would not exist. Overall, payment pre-images and payment hashes are crucial components that enable the Lightning Network’s off-chain payment routing and incentivize cooperation among participants.

# Cryptographic Hash Functions

Cryptographic hashes are used all over the place both in Bitcoin and in the Lightning Network. From address generation and proof-of-work to Lightning’s onion routing, as seen above, Lightning payments. Just as it makes no sense to learn chemistry without knowing what an atom is, it makes no sense to try to learn how Bitcoin and Lightning work without first understanding cryptographic hashes.

A cryptographic hash is like a unique identifier for some digital information. In the physical world, the closest analogy we have is a fingerprint.

It is extremely unlikely that another human will produce a fingerprint like yours. Therefore, we can say that fingerprints serve as unique identifiers. Furthermore, if we only have access to a person’s fingerprint, we cannot deduce any information about them. We don’t know if she is male, female, tall, or short.

In the digital realm, we use mathematics to create a fingerprint of a piece of information. More specifically, we use cryptographic hash functions. These functions take some digital information as input and produce a cryptographic hash.

`CRYPTOGRAPHIC_HASH_FUNCTION(INFORMATION) = CRYPTOGRAPHIC_HASH`

For example, we can use the SHA256 cryptographic hash function to get the cryptographic hash of the text “HELLO WORLD”

`CRYPTOGRAPHIC_HASH_FUNCTION(HELLO WORLD) = 787ec76dcafd20c1908eb0936a12f91edd105ab5cd7ecc2b1ae2032648345dff`

In the example above, the cryptographic hash is represented as 64 hexadecimal digits, which is equivalent to 32 bytes or 256 bits (hence SHA256).

It is impossible to reconstruct the sentence we used as input to the function using the output. That’s why we call cryptographic hash functions “one-way functions”.

Note that if we change just one letter in the input, the output is completely different:

```
CRYPTOGRAPHIC_HASH_FUNCION(HELO WORLD) =
73171d9427c14af7859b7f8fd3c55e2e758bcd95f2d18b1d75bac24319c83667
```

If Alice sends a piece of information along with its hash to Bob, Bob can use the hash to check if the information provided to him was not tempered by computing the hash of the information and confirming that it produces the same value that was sent to him. Therefore, cryptographic hash functions are extremely useful for checking data integrity.

## Properties of Cryptography Hash Functions

The input of a cryptographic hash function can be any digital data: text, image, video… We call the input a pre-image. The cryptographic hash function’s output is often referred to as a hash or digest. For the same cryptographic hash function, the hash is always the same size, regardless of the size of the pre-image. The SHA256 function, for example, always produces 256-bit output. The RIPEMD160 function, also used in Bitcoin, produces 160-bit hashes.

These functions have particular properties that are very useful for applications like Bitcoin and the Lighting Network:

- The same input will always produce the same output.
- A small difference in the input produces a completely different hash.
- The output will always be the same size for the same cryptographic hash function.
- Trial and error is the only way to find which pre-image produces a certain hash. In the computing world, this approach is called “brute force”.

There are some variations for the fourth property:

- Collision Resistance: finding two different pre-images with the same hashes is difficult.
- Pre-image resistance: it must be difficult to find out which pre-image generates a certain hash.
- Second-pre-image resistance: modifying the pre-image without modifying the hash must be difficult.

## Quantifying “difficult”

We’ve seen that, if we only have access to the hash, the only way to find the pre-image is by brute force (trial and error). But how much “force” are we dealing with?

The answer depends on the type of cryptographic hash function used, and how many guesses we can make within some time interval.

For the SHA256 function, the expected number of attempts to find the correct entry is 2^255. Taking into account that a normal computer can calculate an average of 60 million hashes per second, this computer would take approximately 30,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years to find the pre-image. That’s a three followed by 61 zeros.

To put it in perspective, 2^256 is close to the number of atoms there are in the universe. So finding the pre-image of a SHA256 function hash is like picking an atom in the universe and hoping it’s the right one!

# Back to Lightning Payments

Now that you know a little bit about cryptographic hash functions and their properties, we can go back to payment pre-images and hashes. These names must make more sense by now. The receiver when creating the invoice generates a random number and uses this number as input to a cryptographic hash function. The value yielded by the cryptographic hash function is the payment hash, and the random number in the input is the payment pre-image.

The HTLC contract leverages the properties of the cryptographic hash functions to make the happy path secure. But in order to secure it properly, the pre-image must be generated randomly. It makes no sense to use an English word as a pre-images because a word is not as random as a big number generated by throwing a dice multiple times. Randomness is important because it makes it harder for an attacker to crack the pre-image by brute force. That’s why you might have heard Bitcoiners nerd out about random number generators or entropy, which is a measure of the unpredictability of a random variable.

Lightning implementations such as LND and CLN, for instance, must use what programmers call a cryptographically secure pseudorandom number generator or CSPRNG for short. These are random number generator algorithms with properties that make them suitable for use in cryptography.

After generating the payment pre-image, and computing its hash, the receiver will add the payment hash to the invoice, in order to enable the sender to create the redemption clause of the HTLC contract. We can rewrite the piece of Bitcoin script with this new terminology:

`OP_SHA256 <Payment Hash> OP_EQUAL`

In order to execute this clause with success, the receiver uses the payment pre-image.

Create your own node below, or learn more about our Lightning Enterprise solution today.

Also, enjoy exploring our LSP and receiving inbound liquidity with Flow.