lightning
lightning copied to clipboard
ElementsProject
[lightning-decode] Exposure via gRPC
Looks like decode is not exposed via gRPC, which forces clients to parse invoices locally. Although it might be good for performance, proper BOLT 11/12 parsing is not trivial and being able to delegate it to a node could be beneficial, at least in the early days, until there is a good parser for every programming language
I'm not sure what your usecase is but why not just access this via jsonrpc over commando + lnsocket? Then you have access to all rpcs and even ones that are added via other plugins. This is the approach used by https://lnlink.app/ which uses the decode rpc.
I'm not sure what your usecase is but why not just access this via jsonrpc over commando + lnsocket? Then you have access to all rpcs and even ones that are added via other plugins. This is the approach used by https://lnlink.app/ which uses the decode rpc.
The use case is being able to make payments via a mobile app. There are tons of intermediary services but I'd prefer to connect directly to CL via gRPC + mTLS + Tor
I'll look into adding it to the cln-grpc crate. It's most likely just because we don't yet have the request schema.
gRPC + mTLS + Tor seems very complicated compared to a direct connection over lightning to make payments via a mobile app. This is what https://lnlink.app does, it doesn't use any intermediary service.
The connection string looks like this: lnlink:09bc42c0bdb42e618e9fbca5e90b5d604eab989c11d0dbc44d4e0c697a9a5453@23.81.152.187:9735?token=2na6kLEIL1BXV1myM7SphXxSU8T17fozmmcsKA9Wcvg%3D
but to each their own! I was hoping to have something similar to lnlink on android so I don't have to build it 😅
but to each their own! I was hoping to have something similar to lnlink on android so I don't have to build it 😅
it is coming, but with the possibility to use all the method that core lightning provide to talk with it. So a little bit of over engigneering, but it is cool have a choice to use whatever you want to use and not be stuck with a single implementation.
I hate the actual fragmentation that we currently have in cln.
@jb55 I'm not sure if I understand what it means to have a direct connection over Lightning and how it affects privacy/security/usability. Tor helps me with NAT-punching and concealing the node location, mTLS allows for effortless auth and gRPC generates all the mappings for me. I hope this plugin will support a QR auth soon, but I'm currently using this script:
#!/bin/bash
source /mnt/hdd/raspiblitz.conf
host=$(sudo cat /mnt/hdd/tor/clnGRPCport/hostname)
port=$clnGRPCport
server_pem=$(sudo awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' /home/bitcoin/.lightning/bitcoin/server.pem)
client_pem=$(sudo awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' /home/bitcoin/.lightning/bitcoin/client.pem)
client_key_pem=$(sudo awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' /home/bitcoin/.lightning/bitcoin/client-key.pem)
json=$(printf '{ "url": "%s:%s", "server_pem": "%s", "client_pem": "%s", "client_key_pem": "%s" }\n' "$host" "$port" "$server_pem" "$client_pem" "$client_key_pem")
qrencode -t utf8 "$json"
That's the only thing which isn't provided out of the box. Not requiring any server-side setup is the best option IMO
@jb55 I'm not sure if I understand what it means to have a direct connection over Lightning and how it affects privacy/security/usability. Tor helps me with NAT-punching and concealing the node location, mTLS allows for effortless auth and gRPC generates all the mappings for me. I hope this plugin will support a QR auth soon, but I'm currently using this script:
yes Tor is nice for concealing node location, although I prefer warren's VPS ip forwarding solution because Tor is unreliable. You could also just not announce your node over ipv4/6 but still use it for direct comms and controlling your node. Keep in mind Tor is blocked and unusable in some countries like China.
commando uses runes for auth which allows you to restrict app access to only the rpc's that you need for a certain duration, so it's more secure.
Tor is great for NAT-punching so I guess gRPC is fine in that situation.
I'm a bit biased against Tor in general because I believe it's making lightning less stable over time and am concerned about the over-reliance on it for something as simple as port forwarding.
That's the only thing which isn't provided out of the box. Not requiring any server-side setup is the best option IMO
yes agreed which is why I'm happy rusty is adding commando as a builtin! less dependencies the better.
Tor is absolutely critical for privacy, I used to worry about slow LN payments but then I saw some national QR payment systems. For instance, it often takes more than a minute to make a QR payment in Thailand and people are fine with that, it's widely adopted and successful. People don't care about latency and I don't think it's a bottleneck for adoption so I don't really care about it. Speeding up payments without compromising on everything else would be cool but I don't see any alternatives at the moment
I hate the actual fragmentation that we currently have in cln.
Definitely trying to reduce that fragmentation by offering officially maintained interfaces and standardizing around our JSON-RPC, which is reflected in the grpc, the websocket API and the commando API.
commando uses runes for auth which allows you to restrict app access to only the rpc's that you need for a certain duration, so it's more secure.
My goal is to eventually also use runes to restrict the access grpc API users have too, again consolidating around the primitives that we have built over time :+1:
Tor is great for NAT-punching so I guess gRPC is fine in that situation.
As part of greenlight we are building a reverse proxy that can forward encrypted mTLS connections without having to decrypt them (SNI) so we will eventually be able to offer a system to connect to firewalled and NATed devices without the added latency of Tor and without exposing your real IP (of course self-hosting should be possible too).
(Off-topic)
Tor is absolutely critical for privacy,
Can you explain where the loss of privacy comes from in connecting directly between your node and your mobile phone? Maybe I'm missing something in terms of attack/privacy vectors. Is hiding the IP address of the node connection important if the connection is originating from another device that you also own?
it often takes more than a minute to make a QR payment in Thailand and people are fine with that
Really great info to have around timing expectations. Thanks for mentioning.
Can you explain where the loss of privacy comes from in connecting directly between your node and your mobile phone? Maybe I'm missing something in terms of attack/privacy vectors. Is hiding the IP address of the node connection important if the connection is originating from another device that you also own?
I'm not deeply familiar with LN beyond some high-level facts which I believe are still true:
- LN is basically a bunch of network-attached hot wallets
- Every node has a persistent id/pubkey
- There are plenty of services which monitor every node and scrap all of the information they can get, including the list of current and previous IPv4/6 and Tor addresses
- Exposing your home IPv4/6 address is pretty much the same as exposing your physical address
- To add insult to injury, there will be a permanent record on where you live and how much money you have, due to some fundamental privacy trade-offs LN had to make
- Tor is pretty good at hiding server location, so it can compensate for some of those trade-offs
All of the above assumes self-hosting LN node at home. Using a data center is also problematic, even if it serves as a proxy to a home-based node (with or without client-to-server VPN). It adds extra setup, monthly costs and it forces you to trust a third party.
I don't think that people should be forced to use Tor, but I believe it should be default or at least highly encouraged option.
PS. All of the above is not related to this issue and even gRPC plugin itself, it happily works without Tor and I think that's perfectly fine =)