<p>In the image below from Rusty Russell's <a href="https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf" rel="noreferrer">Deployable Lightning paper</a>, you can see a visualization of the commitment transactions and their outputs:</p>

<p><a href="https://i.sstatic.net/1mm67.png" rel="noreferrer"><img src="https://i.sstatic.net/1mm67.png" alt="enter image description here"></a></p>

<p>For each payment in a channel, there are two commitment transactions generated, one for Alice and one for Bob.  Both Alice and Bob sign both commitment transactions, so they're both valid transactions (although only one of them could be included in the blockchain since both transactions spend the same inputs).</p>

<p>Both transactions pay two outputs.  The transaction Alice has (on the left in the diagram, Commit TxA) pays the following two scripts:</p>

<ul>
<li><p>A regular P2PKH (or its segwit equivalent) output that Bob can spend at his leisure.</p></li>
<li><p>An output that Alice can spend after waiting a specified number of blocks (let's say 100), as enforced with <code>OP_CSV</code>, or which Bob can spend if he has a piece of data that hashes to a value in this output.  I call this the pre-image; in other descriptions of Lightning this is a private key used to generate a signature.</p></li>
</ul>

<p>In the transaction that Bob has (on the right, TxB) these are reversed, there's:</p>

<ul>
<li><p>An output that pays Alice using P2PKH.</p></li>
<li><p>An output that Bob can spend after waiting 100 blocks or which Alice can spend at any time using a pre-image.</p></li>
</ul>

<p>In these outputs, Alice selects the pre-image that prevents Bob from spending her output (Revocation-A) and Bob selects the pre-image that prevents Alice from spending his output (Revocation-B).  They could use a random number of large size, although they'll probably both use hashes from a hashchain generated using <a href="https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt" rel="noreferrer">Rusty Russell's 64-dimensional shachain</a> to allow compact storage of any revealed hashes, seeding the chain with some initial random value.</p>

<p>Each time Alice and Bob agree to update the state of the channel, they both reveal to the other person the pre-image for the hashlock they placed on the output for the previous state of the channel, allowing the other person to create a breach remedy transaction.</p>

CC BY-SA 4.0
2020-05-28T08:47:24.807Z
If Alice revealed to Bob the pre-image for the hashlock, allowing Bob to create a breach-remedy transaction, why wouldn't Bob immediately broadcast the breach-remedy transaction with the pre-image, and take all the funds?
Oren
CC BY-SA 4.0
2020-05-28T11:31:50.187Z
I think I solved it: Alice revealed to Bob the pre-image for the hashlock of TxA, but Bob only sent to Alice TxA with Bob's signature. Bob cannot broadcast TxA without Alice's signature. Only if Alice's broadcasts TxA with both Bob's and Alice's signatures, Bob can then immediately broadcast the same transaction with the same signatures but also with the pre-image, and get all the funds. Right?
Oren
CC BY-SA 3.0
2016-08-15T17:25:42.157Z
2016-09-02T12:11:08.943Z
2016-09-02T12:11:08.943Z
David A. Harding
<p>Until this afternoon I thought the anti-cheat transactions or breach remedies built on the exit-transaction of the counterparty.</p>

<p>Apparently, they build on something called a "hash pre-image". What is it the pre-image from? How and why can it be used to create a transaction once the counterparty tries to breach the payment channel?</p>

<lightning-network><hash-time-locked-contract><ln-penalty-transaction>
What is a hash pre-image as it is used for the breach remedy?
Murch
# What is a hash pre-image as it is used for the breach remedy?

(Asked by: username_0 on 2016-08-15)

Until this afternoon I thought the anti-cheat transactions or breach remedies built on the exit-transaction of the counterparty.

Apparently, they build on something called a "hash pre-image". What is it the pre-image from? How and why can it be used to create a transaction once the counterparty tries to breach the payment channel?

**Tags:** lightning-network, hash-time-locked-contract, ln-penalty-transaction


---

## 1 answers

### Answer by username_1 on 2016-08-15. Score: 15 | Accepted answer

In the image below from Rusty Russell's [Deployable Lightning paper](https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf), you can see a visualization of the commitment transactions and their outputs:

[![enter image description here](https://i.sstatic.net/1mm67.png)](https://i.sstatic.net/1mm67.png)

For each payment in a channel, there are two commitment transactions generated, one for Alice and one for Bob. Both Alice and Bob sign both commitment transactions, so they're both valid transactions (although only one of them could be included in the blockchain since both transactions spend the same inputs).

Both transactions pay two outputs. The transaction Alice has (on the left in the diagram, Commit TxA) pays the following two scripts:

* A regular P2PKH (or its segwit equivalent) output that Bob can spend at his leisure.
* An output that Alice can spend after waiting a specified number of blocks (let's say 100), as enforced with `OP_CSV`, or which Bob can spend if he has a piece of data that hashes to a value in this output. I call this the pre-image; in other descriptions of Lightning this is a private key used to generate a signature.

In the transaction that Bob has (on the right, TxB) these are reversed, there's:

* An output that pays Alice using P2PKH.
* An output that Bob can spend after waiting 100 blocks or which Alice can spend at any time using a pre-image.

In these outputs, Alice selects the pre-image that prevents Bob from spending her output (Revocation-A) and Bob selects the pre-image that prevents Alice from spending his output (Revocation-B). They could use a random number of large size, although they'll probably both use hashes from a hashchain generated using [Rusty Russell's 64-dimensional shachain](https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt) to allow compact storage of any revealed hashes, seeding the chain with some initial random value.

Each time Alice and Bob agree to update the state of the channel, they both reveal to the other person the pre-image for the hashlock they placed on the output for the previous state of the channel, allowing the other person to create a breach remedy transaction.

> **Comments:**
> **username_2**: If Alice revealed to Bob the pre-image for the hashlock, allowing Bob to create a breach-remedy transaction, why wouldn't Bob immediately broadcast the breach-remedy transaction with the pre-image, and take all the funds?  
> **username_2**: I think I solved it: Alice revealed to Bob the pre-image for the hashlock of TxA, but Bob only sent to Alice TxA with Bob's signature. Bob cannot broadcast TxA without Alice's signature. Only if Alice's broadcasts TxA with both Bob's and Alice's signatures, Bob can then immediately broadcast the same transaction with the same signatures but also with the pre-image, and get all the funds. Right?  

---

