Skip to content

BOLT 5: fix up opposing MUST & MUST NOT statements. #848

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rustyrussell wants to merge 1 commit into
base: master
Choose a base branch
from
Open

BOLT 5: fix up opposing MUST & MUST NOT statements. #848

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions 05-onchain.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -305,16 +305,19 @@ There are several possible cases for an offered HTLC:
HTLC. In this case, the recipient must use the preimage, once it receives it
from the outgoing HTLC; otherwise, it will lose funds by sending an outgoing
payment without redeeming the incoming payment.
4. The HTLC is forwarded as above, but the recipient also happens to be the
final destination for the payment. In this case, it knows the preimage but
Copy link
Copy Markdown
Collaborator

@TheBlueMatt TheBlueMatt Feb 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels awkward - maybe "final destination for the payment, and it knows the preimage bug it has not received the full payment. In this case, it must not reveal it"?

as it has not received the full payment, it must not reveal
it.<sup>[Preimage-Extraction](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002857.html)</sup>.
Comment on lines +308 to +311
Copy link
Copy Markdown
Collaborator

@t-bast t-bast Mar 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what I offer is better, but the current wording is a bit hard to understand (at least for me).

Suggested change
4. The HTLC is forwarded as above, but the recipient also happens to be the
final destination for the payment. In this case, it knows the preimage but
as it has not received the full payment, it must not reveal
it.<sup>[Preimage-Extraction](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002857.html)</sup>.
4. The HTLC is forwarded as above, but the recipient also happens to be the
final destination for the payment. In this case, it knows the preimage but
until the corresponding outgoing HTLC is settled, it must not reveal
it.<sup>[Preimage-Extraction](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002857.html)</sup>.

This problem is most easily solved by only accepting preimages from

This comment was marked as abuse.

Sign in to view

responses to corresponding outgoing HTLCs.

### Requirements

A local node:
- if it receives (or already possesses) a payment preimage for an unresolved
HTLC output that it has been offered AND for which it has committed to an
outgoing HTLC:
- if it has been offered an unresolved HTLC, AND it has offered a corresponding outgoing HTLC, for which it receives or has already received a payment preimage (by seeing it resolved via an onchain HTLC-success transaction, or via `update_fulfill_htlc`):
- MUST *resolve* the output by spending it, using the HTLC-success
transaction.
- MUST NOT reveal its own preimage when it's not the final recipient.<sup>[Preimage-Extraction](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002857.html)</sup>
- MUST resolve the output of that HTLC-success transaction.
- otherwise:
- if the *remote node* is NOT irrevocably committed to the HTLC:
Expand Down