<p>The preimage <code>R</code> is the same throughout the entire route, so Bob/Dave would know what <code>R</code> is (from <a href="http://dev.lightning.community/overview/#multihop-payments" rel="nofollow noreferrer"><code>lnd</code> Overview</a>).</p>

<p>However if Bob were to broadcast his commitment transaction for the <code>Bob -&gt; Carol</code> channel, it would have to either be an old commitment without the HTLC-offered output or be the current commitment transaction with the HTLC-offered output. In the case of an old commitment transaction, Carol would be able to claim all of the funds in the channel with the revocation key for the old commitment transaction.</p>

<p>In the case of the second transaction with the offered HTLC output, the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#offered-htlc-outputs" rel="nofollow noreferrer">offered HTLC output has a timeout on it</a> which prevents Bob from spending the funds for some amount of time, say two days. In that time, Carol could redeem those funds with the preimage <code>R</code>.</p>

<p>In order for Bob/Dave to pull funds from Carol in the <code>Carol -&gt; Dave</code> channel, he would need to give Carol <code>R</code> before the HTLC between Carol and Dave times out. The timeout of this HTLC will be shorter than the HTLC between Bob and Carol (e.g. only 1 day) so when Dave gives Carol <code>R</code> to pull his funds (or <code>R</code> is published in Dave's broadcast commitment transaction if he does that), Carol can then use that <code>R</code> to claim her funds from Bob's offered HTLC output.</p>

<p>In the event that Dave decides to not pull funds from Carol, Carol retracts her HTLC output after it times out and does not lose any money to Dave. She does not then gain any money from Bob and thus has not lost any money at all. </p>

<p>If Dave refused to sign the new commitment transaction, Carol broadcasts her commitment with the <code>Carol -&gt; Dave</code> offered HTLC after the timeout passes and publishes a transaction which spends the offered HTLC output using the HTLC-timeout transaction. If Dave tries to spend the HTLC using <code>R</code>, Carol then learns of <code>R</code> and can then spend Bob's offered HTLC output using said <code>R</code>. In that case, Bob/Dave can actually lose money because Carol's HTLC-timeout transaction could confirm before Dave's HTLC-Sucess transaction (which contains <code>R</code>) and her HTLC-Success transaction for Bob's HTLC could confirm before Bob's HTLC-Timeout and thus gain money from Bob/Dave.</p>

<p>Thus such a scheme would result in Carol effectively being cut out of the route and not losing any money. If Bob/Dave were stupid, they could actually lose money to Carol.</p>

CC BY-SA 3.0
2017-10-26T10:04:00.780Z
If I understand it correctly, there is never (for any length of a payment channel) any harm associated with letting everyone or any select group know about R as soon as the recipient pulled their money (in the last payment channel of the chain). But if R got revealed prior to that, the intermediate nodes (neither sender nor receiver) could pull their money with the last intermediate node walking away with the sent money as no one pulled from them iff the receiver decides not to. But the receiver can still pull their money even after everyone else already pulled theirs. Is this correct?
UTF-8
CC BY-SA 3.0
2017-10-26T14:33:52.190Z
I think that is correct.
Ava Chow
CC BY-SA 3.0
2017-10-26T16:41:07.140Z
Thank you! I'll keep the bounty open a bit longer, though, to keep visibility high for someone who can come up with a counter example.
UTF-8
CC BY-SA 3.0
2017-10-26T02:25:45.600Z
2017-10-26T02:25:45.600Z
Ava Chow
<p>Given the lightning path <code>Alice → Bob → Carol → Dave → Emilee</code> (with Alice being the sender and Emilee being the receiver), assume Dave and Bob to be the same entity.</p>

<p>By pulling funds from Dave to herself, Emilee discloses the secret R to Dave. Bob then knows R, too, because Bob and Dave are the same entity, and pulls funds from Alice.</p>

<p>Bob then broadcasts the channels state between him and Carol to the blockchain. Dave subsequently pulls funds from Carol.</p>

<p>In this procedure, Carol did not get paid. How is this prevented?</p>

CC BY-SA 3.0
2017-10-23T19:19:12.783Z
@MeshCollider The lightning paper always talks about R as though it's a single piece of data. It never has an index and the authors always use the singular form. E.g.: "[...] at any point in time a single participant is responsible for disclosing to the next participant whether they have knowledge of the preimage R." Furthermore, I don't see how the participants could make sure to get R if R is different for each channel, and I don't see how they could use R to pull money from closer to the sender to them if R is different for each channel.
UTF-8
<lightning-network><micropayments><micropaymentchannels><lightning-routing>
Same entity controlling separated parts of a a lightning path
UTF-8
# Same entity controlling separated parts of a a lightning path

(Asked by: username_0 on 2017-10-22)

Given the lightning path `Alice → Bob → Carol → Dave → Emilee` (with Alice being the sender and Emilee being the receiver), assume Dave and Bob to be the same entity.

By pulling funds from Dave to herself, Emilee discloses the secret R to Dave. Bob then knows R, too, because Bob and Dave are the same entity, and pulls funds from Alice.

Bob then broadcasts the channels state between him and Carol to the blockchain. Dave subsequently pulls funds from Carol.

In this procedure, Carol did not get paid. How is this prevented?

**Tags:** lightning-network, micropayments, micropaymentchannels, lightning-routing

> **Comments:**
> **username_0**: @MeshCollider The lightning paper always talks about R as though it's a single piece of data. It never has an index and the authors always use the singular form. E.g.: "[...] at any point in time a single participant is responsible for disclosing to the next participant whether they have knowledge of the preimage R." Furthermore, I don't see how the participants could make sure to get R if R is different for each channel, and I don't see how they could use R to pull money from closer to the sender to them if R is different for each channel.  

---

## 1 answers

### Answer by username_1 on 2017-10-26. Score: 3 | Accepted answer

The preimage `R` is the same throughout the entire route, so Bob/Dave would know what `R` is (from [`lnd` Overview](http://dev.lightning.community/overview/#multihop-payments)).

However if Bob were to broadcast his commitment transaction for the `Bob -> Carol` channel, it would have to either be an old commitment without the HTLC-offered output or be the current commitment transaction with the HTLC-offered output. In the case of an old commitment transaction, Carol would be able to claim all of the funds in the channel with the revocation key for the old commitment transaction.

In the case of the second transaction with the offered HTLC output, the [offered HTLC output has a timeout on it](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#offered-htlc-outputs) which prevents Bob from spending the funds for some amount of time, say two days. In that time, Carol could redeem those funds with the preimage `R`.

In order for Bob/Dave to pull funds from Carol in the `Carol -> Dave` channel, he would need to give Carol `R` before the HTLC between Carol and Dave times out. The timeout of this HTLC will be shorter than the HTLC between Bob and Carol (e.g. only 1 day) so when Dave gives Carol `R` to pull his funds (or `R` is published in Dave's broadcast commitment transaction if he does that), Carol can then use that `R` to claim her funds from Bob's offered HTLC output.

In the event that Dave decides to not pull funds from Carol, Carol retracts her HTLC output after it times out and does not lose any money to Dave. She does not then gain any money from Bob and thus has not lost any money at all.

If Dave refused to sign the new commitment transaction, Carol broadcasts her commitment with the `Carol -> Dave` offered HTLC after the timeout passes and publishes a transaction which spends the offered HTLC output using the HTLC-timeout transaction. If Dave tries to spend the HTLC using `R`, Carol then learns of `R` and can then spend Bob's offered HTLC output using said `R`. In that case, Bob/Dave can actually lose money because Carol's HTLC-timeout transaction could confirm before Dave's HTLC-Sucess transaction (which contains `R`) and her HTLC-Success transaction for Bob's HTLC could confirm before Bob's HTLC-Timeout and thus gain money from Bob/Dave.

Thus such a scheme would result in Carol effectively being cut out of the route and not losing any money. If Bob/Dave were stupid, they could actually lose money to Carol.

> **Comments:**
> **username_0**: If I understand it correctly, there is never (for any length of a payment channel) any harm associated with letting everyone or any select group know about R as soon as the recipient pulled their money (in the last payment channel of the chain). But if R got revealed prior to that, the intermediate nodes (neither sender nor receiver) could pull their money with the last intermediate node walking away with the sent money as no one pulled from them iff the receiver decides not to. But the receiver can still pull their money even after everyone else already pulled theirs. Is this correct?  
> **username_1**: I think that is correct.  
> **username_0**: Thank you! I'll keep the bounty open a bit longer, though, to keep visibility high for someone who can come up with a counter example.  

---

