LUD-13: signMessage-based seed generation for auth protocol.

May 20, 2026 ยท View on GitHub

author: akumaigorodski author: fiatjaf author: hampus_s discussion: https://t.me/lnurl/5155

Seed generation method for the auth protocol

This is based on the signmessage API provided by some Lightning node implementations. It signs an HMAC of a message in a standard way using ECDSA with deterministic nonces, so it's always the same signature given the same key and message.

Here we define a canonical phrase to be signed, and from that we will derive the LNURL-auth seed.

linkingKey derivation for wallets which don't have an access to master privKey:

In this case neither hashingKey nor domain-specific linkingKeys can be derived by the path. To overcome this limitation a different scheme is used for this class of wallets:

  1. The following canonical phrase is defined: DO NOT EVER SIGN THIS TEXT WITH YOUR PRIVATE KEYS! IT IS ONLY USED FOR DERIVATION OF LNURL-AUTH HASHING-KEY, DISCLOSING ITS SIGNATURE WILL COMPROMISE YOUR LNURL-AUTH IDENTITY AND MAY LEAD TO LOSS OF FUNDS!.
  2. LN WALLET obtains an RFC6979 deterministic signature of sha256(sha256(utf8ToBytes(canonical phrase))) using secp256k1 with node private key.
  3. LN WALLET defines hashingKey as sha256(obtained signature).
  4. SERVICE domain name is extracted from auth LNURL and then service-specific linkingPrivKey is defined as hmacSha256(hashingKey, utf8ToBytes(service domain name)).

LN WALLET must make sure it is not possible to accidentally or automatically sign and hand out a signature of canonical phrase.

Example

To simplify the implementation, here is an example with all relevant intermediate steps, starting with the signed canonical phrase (Step 3 of this document):

k1:
a7830ce0d70e447ff888a72253cb3b564d52362a0aba25c9bd74c36f54d5431e
domain:
lightninglogin.live
obtained signature (of canonical phrase):
d99tpq15iyafmpsi5s4a43dmbwknprjb9i378xj4acki7akefzwk6ygoefjqqy7xck6njam5shcrgzh697wjhsaxjko7b9wkto4juezw

hashingKey:
0bdf5689da0db751c3f93366093f55a007c814f352e1f8f2a128c864e6f7fa41
linkingPrivKey:
9628eaef95f5c72fc4bcbfc1d3fe46805484aa1ee0d9cc219d342ef1ee926b47

And further steps described in Lud 4:
linkingKey:
026c29c00976a94dc59f8ee33b12709d549e9d6ddc58744cdfcf7eda5af18da853
signed_K1:
bf7eda76a3d2028a377f9f39197f715052053c17262d8f58cb1617aeacf414e603934d6e89937a82bf93ad20d3d16d94555ff87fae07ef5dbac2da3d6eaf3375
signed_K1_DER_encoded:
3045022100bf7eda76a3d2028a377f9f39197f715052053c17262d8f58cb1617aeacf414e6022003934d6e89937a82bf93ad20d3d16d94555ff87fae07ef5dbac2da3d6eaf3375