From c0acd23a111b96b73f9210b2597e64baf146f2ea Mon Sep 17 00:00:00 2001 From: Evan Kaloudis Date: Fri, 3 Mar 2023 22:51:58 -0500 Subject: [PATCH 1/2] Public key verification of hosted LN addresses --- xx.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 xx.md diff --git a/xx.md b/xx.md new file mode 100644 index 0000000..59c8e64 --- /dev/null +++ b/xx.md @@ -0,0 +1,31 @@ +LUD-XX: Public key verification of hosted LN addresses +===================================================== + +`author: kaloudis` + +--- + +## Introduction + +With the rise of Nostr and zaps there's been an increase in the use of lightning addresses. Some people host their own addresses, many people are using fully custodial services, somewhere in the middle are services that run the web server for people who run their nodes at home behind their routers, like [satdress](https://github.com/nbd-wtf/satdress) or [Alby](https://guides.getalby.com/overall-guide/alby-lightning-wallet/features/connect-your-own-node-to-your-alby-account). + +The biggest problem with these services is that they can trivially steal funds by presenting senders with invoices to their own nodes. They can even do this very gradually over time, siphoning away a small percentage of funds so people don't realize that the theft is happening. + +## Optional public key verification + +This solution is a simple one: append the pubkey of the node that should be signing the invoices in the lightning address. Instead of providing the 33-byte pubkey we can provide a 20-byte SHA1 hash of it to save space. + +eg. `evan@pay.zeusln.app#f1b5bbfa4072836ecb7f139d0d692c4491f1162b` + +Payers' clients would check the verification hash against the SHA1 hash of the destination pubkey in the invoice they were delivered. + +## Caveats + +In a way this ruins the human readability of LN addresses, but it will be optional, even for users who want to use these types of services. For fully custodial services, this is redundant. For self-hosted users, this is largely unnecessary. Furthermore in the context of something like Nostr zaps, the UX is hardly degraded, if at all. + +This solution does not explicitly work with blinded paths as the final destination is not embedded in the invoice, but perhaps the introduction point can be used for a similar effect. + +## Acknowledgements + +Bos for [inspiring the idea](https://twitter.com/alexbosworth/status/1630309388446748672). Although the solution proposed above also works for custodial accounts using the same node, whereas the solution proposed in the tweet does not. + From 66001fd9e3c949481de92cee92d88719b1d28250 Mon Sep 17 00:00:00 2001 From: Evan Kaloudis Date: Sat, 4 Mar 2023 10:08:59 -0500 Subject: [PATCH 2/2] remove comment about blinded path intro point --- xx.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xx.md b/xx.md index 59c8e64..9d54672 100644 --- a/xx.md +++ b/xx.md @@ -23,7 +23,7 @@ Payers' clients would check the verification hash against the SHA1 hash of the d In a way this ruins the human readability of LN addresses, but it will be optional, even for users who want to use these types of services. For fully custodial services, this is redundant. For self-hosted users, this is largely unnecessary. Furthermore in the context of something like Nostr zaps, the UX is hardly degraded, if at all. -This solution does not explicitly work with blinded paths as the final destination is not embedded in the invoice, but perhaps the introduction point can be used for a similar effect. +This solution does not explicitly work with blinded paths as the final destination is not embedded in the invoice. ## Acknowledgements