Skip to content

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

Open
rustyrussell wants to merge 1 commit into
lightning:masterfrom
rustyrussell:fix-desc-of-preimage-attack
Open

BOLT 5: fix up opposing MUST & MUST NOT statements.#848
rustyrussell wants to merge 1 commit into
lightning:masterfrom
rustyrussell:fix-desc-of-preimage-attack

Conversation

@rustyrussell
Copy link
Copy Markdown
Collaborator

We can't say "MUST spend via HTLC-success" and "MUST NOT reveal preimage",
since the HTLC-success does exactly that!

Let's simplify it. If you get the preimage from the outgoing HTLC,
you need to spend the incoming.

Signed-off-by: Rusty Russell rusty@rustcorp.com.au
See: dcf6b0f

We can't say "MUST spend via HTLC-success" and "MUST NOT reveal preimage",
since the HTLC-success does exactly that!

Let's simplify it.  If you get the preimage from the outgoing HTLC,
you need to spend the incoming.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Copy link
Copy Markdown
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

one nit, but looks good.

Comment thread 05-onchain.md
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

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"?

Copy link
Copy Markdown

@ariard ariard left a comment

Choose a reason for hiding this comment

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

Thanks for clarifying this, a small nit

Comment thread 05-onchain.md
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>.
This problem is most easily solved by only accepting preimages from

This comment was marked as abuse.

Comment thread 05-onchain.md
Comment on lines +308 to +311
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>.
Copy link
Copy Markdown
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants