<p>Lightning forwards payments using a construction called a "hashed timelock contract" (HTLC), which allows the payee to redeem the transaction if they know the preimage to a given hash, or allows the payer to redeem the transaction after a given timeout.</p>

<p>So eg if I'm selling you something for $2 over lightning, I might say "I'll tell you the sha256 preimage of <code>1bc9852364a8aa073daedb3965716ab63d84570c645b091f535a3677010d9984</code> when you pay me $2. You setup an HTLC with Alice giving them $2 when they know the preimage with a timeout of 50 hours, Alice sets up an HTLC with Bob for $2 with a timeout of 28 hours, and Bob sets up an HTLC with me for $2 with a timeout of 4 hours. At this point no money has actually changed hands -- if I don't reveal the preimage, everyone gets their money back. If I do reveal the preimage ("the password is xyzzy"), I get $2 from Bob; but Alice and you still haven't actually paid any money. But Bob knows the preimage, so he can claim $2 from Alice; and then Alice can claim $2 from you.</p>

<p>So the effect is, the middlemen never have the option of running away with the money, they can only run away having paid the money, but not collected it from you: if Bob received the preimage, but didn't collect from Alice before the 28 hour time limit expired, I'd be paid, while Alice and you would get your money back.</p>

<p>This would be pretty stupid of Bob, so we assume that mostly people like Bob will avoid doing things like this, and in effect the whole chain will be cleared at once.</p>

CC BY-SA 3.0
2016-04-12T17:36:08.973Z
The key bit is that each participant *has* to pay if, and only if, they get what *they* need to *get* paid.
David Schwartz
CC BY-SA 3.0
2017-12-27T16:49:48.187Z
Could Bob wait 27 hours and then collect the money? If a large hub wanted to attack the network, could they intentionally delay transactions as long as possible and force everyone else to wait?
Anthony
CC BY-SA 3.0
2016-03-04T20:25:24.040Z
2016-04-11T11:18:17.573Z
2016-04-11T11:18:17.573Z
Anthony Towns
<p>It is my understanding that Lightning is to scale with users having only few payment channels by leveraging the <a href="https://en.wikipedia.org/wiki/Six_degrees_of_separation" rel="noreferrer">six degrees of separation theory</a> to facilitate payment routing. I understand how onion routing is employed to obfuscate origin and target of the payment. </p>

<p>I have read claims that it is also not possible for a node in the middle to receive but not forward the payment. This appears to be implemented by having either all hops of the payment execute at once, or none at all. </p>

<p>How can it be assured that the whole payment chain executes the payment at once?</p>

<lightning-network><lightning-routing><hash-time-locked-contract>
How is a node in the middle prohibited from keeping the money in a routed Payment in Lightning network?
Murch
# How is a node in the middle prohibited from keeping the money in a routed Payment in Lightning network?

(Asked by: username_0 on 2016-03-04)

It is my understanding that Lightning is to scale with users having only few payment channels by leveraging the [six degrees of separation theory](https://en.wikipedia.org/wiki/Six_degrees_of_separation) to facilitate payment routing. I understand how onion routing is employed to obfuscate origin and target of the payment.

I have read claims that it is also not possible for a node in the middle to receive but not forward the payment. This appears to be implemented by having either all hops of the payment execute at once, or none at all.

How can it be assured that the whole payment chain executes the payment at once?

**Tags:** lightning-network, lightning-routing, hash-time-locked-contract


---

## 1 answers

### Answer by username_1 on 2016-03-04. Score: 16 | Accepted answer

Lightning forwards payments using a construction called a "hashed timelock contract" (HTLC), which allows the payee to redeem the transaction if they know the preimage to a given hash, or allows the payer to redeem the transaction after a given timeout.

So eg if I'm selling you something for $2 over lightning, I might say "I'll tell you the sha256 preimage of `1bc9852364a8aa073daedb3965716ab63d84570c645b091f535a3677010d9984` when you pay me $2. You setup an HTLC with Alice giving them $2 when they know the preimage with a timeout of 50 hours, Alice sets up an HTLC with Bob for $2 with a timeout of 28 hours, and Bob sets up an HTLC with me for $2 with a timeout of 4 hours. At this point no money has actually changed hands -- if I don't reveal the preimage, everyone gets their money back. If I do reveal the preimage ("the password is xyzzy"), I get $2 from Bob; but Alice and you still haven't actually paid any money. But Bob knows the preimage, so he can claim $2 from Alice; and then Alice can claim $2 from you.

So the effect is, the middlemen never have the option of running away with the money, they can only run away having paid the money, but not collected it from you: if Bob received the preimage, but didn't collect from Alice before the 28 hour time limit expired, I'd be paid, while Alice and you would get your money back.

This would be pretty stupid of Bob, so we assume that mostly people like Bob will avoid doing things like this, and in effect the whole chain will be cleared at once.

> **Comments:**
> **username_2**: The key bit is that each participant *has* to pay if, and only if, they get what *they* need to *get* paid.  
> **username_3**: Could Bob wait 27 hours and then collect the money? If a large hub wanted to attack the network, could they intentionally delay transactions as long as possible and force everyone else to wait?  

---

