Skip to content

Make node pubkey/node-secret-ECDH signing methods infallible #2751

Description

@TheBlueMatt

In #2653 (and elsewhere) we're moving towards signing methods being explicitly fallible as a way to process things asynchronously. That's great for channel operations we can easily retry later, but ECDH and especially fetching our node id are generally not supper retryable operations. Instead, we should definitely make fetching our node id infallible, and maybe consider doing the same with ECDH. There's some concept of wanting to have the private key signing BOLT11 (and BOLT12) invoices be offline/async to ensure a compromised service doesn't sign an invoice which would let a user deposit to a third party, but given the overloading of the node secret key generally, I feel like that really should be accomplished with a phantom node id or BOLT12's use of separate key material for invoice/offer signing. Thoughts?

Activity

  1. devrandom commented on Nov 28, 2023

    @devrandom
    Member

    I agree:

    • phantom nodes are a better way to issue invoices
    • ECDH for p2p protocol purposes is related to being an active (non-phantom) node on the network. I agree that this use cannot lose funds, so could be done outside of the signer abstraction.

    but, I also think that wrapping/unwrapping the inner most onion layer should be something that should be done on the signer:

    • unwrapping the inner most layer of an onion destined for a phantom node uses a signer controlled key
    • wrapping the inner most layer and protecting payment preimages in the signer prevents diversion of HTLCs to an attacker
  2. TheBlueMatt commented on Nov 28, 2023

    @TheBlueMatt
    CollaboratorAuthor

    Right that makes sense, I guess we'd have to move to a separate call for ECDH on the phantom secret, so we could probably find a way to make that async, letting us have a sync/infallible ECDH for the non-phantom secret.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions