<p>You will find the answer to your question in <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#removing-an-htlc-update_fulfill_htlc-update_fail_htlc-and-update_fail_malformed_htlc" rel="nofollow noreferrer">BOLT 02 in the section about the <code>update_fulfill_htlc message</code></a></p>

<p>from there I quote: </p>

<blockquote>
  <p>If the <code>payment_preimage</code> value in <code>update_fulfill_htlc</code> doesn't SHA256 hash to the corresponding HTLC <code>payment_hash</code> [the receiving node] MUST fail the channel.</p>
</blockquote>

<p>This goes for every local HTLC so if Charlie sends the wrong <code>payment_preimage</code> Bob will fail the channel with Chralie. If Bob alters the <code>preimage</code> Alice will fail the channel. </p>

<p>Whoever fails the channel should fail the onion as the path does not exist anymore. Reading <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#failure-messages" rel="nofollow noreferrer">BOLT 04</a> I guess it returns </p>

<blockquote>
  <p>type: PERM|8 (<code>permanent_channel_failure</code>) </p>
</blockquote>

<p>But I did not double check in the implementations</p>

CC BY-SA 4.0
2019-07-19T10:54:10.943Z
interestingly enough I just realized that the person trying to release a wrong preimage might get a second chance. Failing the channel should be collaboratively in which case the HTLCs will timeout first before publishing a closing transaction. However if the channel is closed with a force close the HTLC is now onchain and there it could be claimed with the correct preimage (which obviously comes with additional onchain fees for the transaction redeeming the HTLC)
Rene Pickhardt
CC BY-SA 4.0
2019-07-16T13:36:22.650Z
2019-07-16T13:36:22.650Z
Rene Pickhardt
<p>Consider a multi-hop Lightning payment from Alice via Bob to Charlie. Charlie creates an invoice, Alice finds a route and forwards the payment, now Charlie is expected to redeem the payment by revealing the preimage to Bob. If Charlie tries to redeem the payment using an incorrect preimage, does Bob cancel the payment altogether, or does Charlie get "a second chance" to redeem it?</p>

<lightning-network>
Does an incorrect preimage cause intermediary nodes to discard a Lightning payment?
Sergei Tikhomirov
# Does an incorrect preimage cause intermediary nodes to discard a Lightning payment?

(Asked by: username_0 on 2019-07-16)

Consider a multi-hop Lightning payment from Alice via Bob to Charlie. Charlie creates an invoice, Alice finds a route and forwards the payment, now Charlie is expected to redeem the payment by revealing the preimage to Bob. If Charlie tries to redeem the payment using an incorrect preimage, does Bob cancel the payment altogether, or does Charlie get "a second chance" to redeem it?

**Tags:** lightning-network


---

## 1 answers

### Answer by username_1 on 2019-07-16. Score: 2 | Accepted answer

You will find the answer to your question in [BOLT 02 in the section about the `update_fulfill_htlc message`](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#removing-an-htlc-update_fulfill_htlc-update_fail_htlc-and-update_fail_malformed_htlc)

from there I quote:

> If the `payment_preimage` value in `update_fulfill_htlc` doesn't SHA256 hash to the corresponding HTLC `payment_hash` [the receiving node] MUST fail the channel.

This goes for every local HTLC so if Charlie sends the wrong `payment_preimage` Bob will fail the channel with Chralie. If Bob alters the `preimage` Alice will fail the channel.

Whoever fails the channel should fail the onion as the path does not exist anymore. Reading [BOLT 04](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#failure-messages) I guess it returns

> type: PERM|8 (`permanent_channel_failure`)

But I did not double check in the implementations

> **Comments:**
> **username_1**: interestingly enough I just realized that the person trying to release a wrong preimage might get a second chance. Failing the channel should be collaboratively in which case the HTLCs will timeout first before publishing a closing transaction. However if the channel is closed with a force close the HTLC is now onchain and there it could be claimed with the correct preimage (which obviously comes with additional onchain fees for the transaction redeeming the HTLC)  

---

