4

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?

Improve this question
1
  • @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
    Commented Oct 23, 2017 at 19:19

1 Answer 1

Reset to default
3
+50

The preimage R is the same throughout the entire route, so Bob/Dave would know what R is (from lnd Overview).

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 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.

Improve this answer
3
  • 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
    Commented Oct 26, 2017 at 10:04
  • I think that is correct.
    – Ava Chow ♦
    Commented Oct 26, 2017 at 14:33
  • 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
    Commented Oct 26, 2017 at 16:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.