Skip to content
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

Jump to bottom

Add a PaymentId for inbound payments #3303

Merged
merged 3 commits into from
Sep 24, 2024
Merged

Add a PaymentId for inbound payments #3303

merged 3 commits into from
Sep 24, 2024

Commits on Sep 23, 2024

  1. Do not check the ordering of HTLCs in PaymentClaim[able,ed] 

    In the next commit we'll change the order of HTLCs in
`PaymentClaim[able,ed]` events. This shouldn't break anything, but
our current functional tests check that the HTLCs are provided in
the order they expect (the order they were received). Instead, here
we only validate that each claimed HTLC matches one expected path.
    @TheBlueMatt
    TheBlueMatt committed Sep 23, 2024
    Configuration menu
    Copy the full SHA
    803366a View commit details
    Browse the repository at this point in the history

  2. Add an inbound_payment_id_secret to ChannelManager 

    In the next commit we'll start generating `PaymentId`s for inbound
payments randomly by HMAC'ing the HTLC set of the payment. Here we
start by defining the HMAC secret for these HMACs.

This requires one small test adaptation and a full_stack_target
fuzz change because it changes the RNG consumption.
    @TheBlueMatt
    TheBlueMatt committed Sep 23, 2024
    Configuration menu
    Copy the full SHA
    aa09c33 View commit details
    Browse the repository at this point in the history

  3. Add a PaymentId for inbound payments 

    We expect our users to have fully idempotent `Event` handling as we
may replay events on restart for one of a number of reasons. This
isn't a big deal as long as all our events have some kind of
identifier users can use to check if the `Event` has already been
handled.

For outbound payments, this is the `PaymentId` they provide in the
send methods, however for inbound payments we don't have a great
option.

`PaymentHash` largely suffices - users can simply always claim in
response to a `PaymentClaimable` of sufficient value and treat a
`PaymentClaimed` event as duplicate any time they see a second one
for the same `PaymentHash`. This mostly works, but may result in
accepting duplicative payments if someone (incorrectly) pays twice
for the same `PaymentHash`.

Users could also fail for duplicative `PaymentClaimable` events of
the same `PaymentHash`, but doing so may result in spuriously
failing a payment if the `PaymentClaimable` event is a replay and
they never saw a corresponding `PaymentClaimed` event.

While none of this will result in spuriously thinking they've been
paid when they have not, it does result in some pretty awkward
semantics which we'd rather avoid our users having to deal with.

Instead, here, we add a new `PaymentId` which is simply an HMAC of
the HTLCs (as Channel ID, HTLC ID pairs) which were included in the
payment.
    @TheBlueMatt
    TheBlueMatt committed Sep 23, 2024
    Configuration menu
    Copy the full SHA
    aaf529d View commit details
    Browse the repository at this point in the history