Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM
On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER wrote: Hey Zman, I saw the announcement about the commando plugin, and it was actually one of the reasons I wanted to write up what I had in mind, because while commando also uses a lightning connection to send commands to a lightning node, it was missing what in my opinion is the most important part: having all of Bolt 8 handled by the HSM and validating commands using a trusted display. What is wrong with runes/macaroons for validating and authenticating commands? I can't imagine validating every RPC request with a hardware device and trusted display, unless you have some specific use case in mind. Will ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning RPC
On Mon, Jan 24, 2022 at 01:54:49PM +1030, Rusty Russell wrote: Christian Decker writes: William Casarin writes: I think the end goal of an RPC bolt [blip] would be super powerful, so that lnsocket could talk to any lightning node, but that could be further down the line. Choosing the right data format seemed like an important step in that direction. Would love to hear your thoughts on this! I agree. Exchanging the transport layer underneath grpc doesn't change semantics, but does unlock a number of potential use-cases. I think either the JSON-RPC or grpc can serve as a basis for a common RPC definition that can have any number of bindings, since we generate conversion code to/from JSON-RPC and grpc we can transparently map them back and forth. Yeah, I don't think we'll end up with a control standard. But I've been pleasantly surprised before: certainly a common subset would be nice! I ended up just using json+commando for my prototype[1]. I'm not going to overengineer anything yet. If there's a way write plugins for the other implementations I could start hacking away at a common control subset, since I do eventually want an iOS app that controls all node implementations. I will try to get something working across multiple implementations before writing up a spec. Cheers, Will [1] http://git.jb55.com/lnsocket/file/rpc.c.html ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Lightning RPC
Hey Christian, I noticed you are doing RPC stuff... I'm looking to do RPC over lightning itself. I started a C library called lnsocket[1], scrounged from clightning parts, so that I can send messages from iOS to control my lightning node. I've got to the point with lnsocket where I can send TLVs to my node, and now I'm starting to think about what format the RPC commands should be. I noticed the commando c-lightning plugin just uses the JSON-RPC payload, but perhaps something more compact and rpc-friendly like grpc would be better... which is why this cln-grpc PR peaked my curiosity. I think the end goal of an RPC bolt would be super powerful, so that lnsocket could talk to any lightning node, but that could be further down the line. Choosing the right data format seemed like an important step in that direction. Would love to hear your thoughts on this! I've cc'd clightning/lightning-dev as well to see if anyone else is working on this or thinking about this stuff right now. Cheers, Will [1] http://git.jb55.com/lnsocket On Tue, Jan 18, 2022 at 06:01:46AM -0800, Christian Decker wrote: This is the final PR in the cln-* series. It uses all the primitives we built in the previous 3 PRs and uses them to expose the JSON-RPC over grpc, with mTLS authentication builtin. You can view, comment on, or merge this pull request online at: https://github.com/ElementsProject/lightning/pull/5013 -- Commit Summary -- * cln-grpc-plugin: Add scaffolding for the cln-grpc-plugin * make: Add a hook for us to depend on generated files for tests * make: Generate grpc bindings if we want to test with rust enabled ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
Hey Christian, On Thu, Dec 16, 2021 at 11:27:33AM +0100, Christian Decker wrote: This is quite a common request, and we've used a solution I like to call the "Poor man's rendez-vous". It basically routes a payment through all the parties that are to be paid, with the last one accepting the payment for all participants. The payment is atomic, once the circuit is set up no participant can cheat the others and it's seamless from the payer's perspective. Let's say user `A` wants to pay `B` and `C` atomically. `B` gets 10ksat and `C` gets 90ksat out of a total of 100ksat: 1) `C` creates an invoice with payment hash `H` for 90ksat and sends it to `B` 2) `B` creates an invoice with payment hash `H` (same as the first invoice, but `B` doesn't know the preimage) for 100ksat (maybe plus a tiny bit for routing fees between `B` and `C`). 3) `A` receives an invoice which appears to be from `B` for the expected total of 100ksat. 4) `A` proceeds to pay the invoice to `B` like normal 5) `B` receives the incoming payment, but doesn't have the preimage for `H`, so they must forward to `C` if they want to receive their share. `B` then proceeds to pay the 90ksat invoice from `C`, which reveals the preimage to them, and they can turn around and claim the incoming `100ksat` (covering both `B` and `C` share) It's a poor man's version because it requires creating two invoices and `B` sees two payments (100ksat incoming, 90ksat outgoing), but the overall outcome is the desired one: either both parties get paid or noone gets paid. This can trivially be extended to any number of parties (with reduced success probability), and will remain atomic. It also doesn't require any changes on the sender side, and only minimal setup between the payees. The crux here is that we somehow need to ensure `H` is always the same along the entire chain of payments, but with a good coordination protocol that should be feasible. This is very cool, at least for a small number of parties. When I was working at a record label it was very common to split between 1-5 people on a given track, being able to atomically payout to individual artist's lightning nodes would have been super useful at the time (assuming a world where our artists ran lightning nodes). At some point I was testing 600-output bitcoin transactions as a payout method, but that looked like it was going to be economically infeasible sometime in the future. Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would it be, could it be done with a clightning plugin perhaps? Cheers, Will ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
On Wed, Dec 15, 2021 at 01:59:49PM -0800, William Casarin wrote: Hey Ronan, On Wed, Dec 15, 2021 at 05:33:51PM +, Ronan McGovern wrote: If not, what would be required to develop this? * A protocol change? * Could it be built with the current protocol (I see an app on LN Bits to split but it doesn't seem to work). This is typically done at the application level. The fountain podcasting app works this way and it seems to work okish. The tricky part is what to do when the payment partially fails. Perhaps you keep trying with exponential backoff until the payment completes for all parties. If this was handled at the protocol level, would you fail the entire transaction if one of the channels failed? This is the kind of business logic that would be tricky when designing a protocol-level solution to this. I think it's reasonable to handle this at the application level for now, but perhaps some standard protocols might be useful in the future. Cheers, Will ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
Hey Ronan, On Wed, Dec 15, 2021 at 05:33:51PM +, Ronan McGovern wrote: Hi folks, I'm Ronan - based in Dublin and building Trelis.com (simple payment links to accept Lightning). I'm wondering if there is a way to create an invoice that splits the payment to two lightning addresses? If not, what would be required to develop this? * A protocol change? * Could it be built with the current protocol (I see an app on LN Bits to split but it doesn't seem to work). This is typically done at the application level. The fountain podcasting app works this way and it seems to work okish. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Machine-to-machine LN payments
Eugene via Lightning-dev writes: > Hello, list, > > I haven't closely following the Lightning Network's state of affairs since > late 2018 and I wondering, is it possible to support the following use-case > with LN: > > 1. A user subscribes to the service by opening a channel with it > 2. User sets his LN node to "trust" invoices that come from said service > 3. On subscription renewal, service sends an invoice to the client's LN node > 4. Since the client's node is "trusting" service's node, it pays invoice > straight away > > User, of course, may cancel the subscription at any time by removing > service's LN node public key from the list of "trusted". Or the user can set > a limit on the amount and the frequency of payments that would be accepted > from the trusted node. > > For that matter, the questions are: > > 1. Is it possible to send invoices just by LN means? (Should we use TLVs?) > 2. Is it possible to enable automatic machine-to-machine payments? As in the > example above, by accepting invoices from "trusted" nodes. Offers[0] should support these use cases Cheers, Will [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002276.html ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients
Orfeas Stefanos Thyfronitis Litos writes: > ZmnSCPxj via Lightning-dev writes: >> If everyone runs such a privately-owned server, on the other hand, this >> is not so different from having a Lightning node you run at your home >> that has a fullnode as well and which you access via a remote control >> mobile device, and it is the inconvenience of having such a server at >> your home that prevents this in the first place. > > Private full nodes serving headers to a handful of weak devices have > been mentioned many times as a good solution against all sorts of > problems in a future full of LN + SPV nodes. I agree. It should be > therefore a top priority to make the UX of connecting my mobile LN > client to my home full node extremely easy, so that centralised > services can't improve much on that step. Especially if I already run > a full node. > > Could someone briefly describe how this UX looks currently? And if > it's not as seamless as it could, what blockers are there? The UX for this doesn't have to be complicated. All you need is a node provider like FullyNoded, Casa, etc. My setup at home is a desktop with: - bitcoind - clightning - zerotier (or tailscale) (private vpn for connecting to your node from anywhere) - sparkwallet (clightning webui) bound to a zerotier interface So as long as you have a node that runs these bits of software, perhaps assumeutxo to speed up IBD, and a QR-code automagic setup, then UX should be pretty smooth. You would still need to deal with lightning backups and liquidity issues, but we just need to do more work on the software side to make that experience nicer. Cheers, Will -- https://jb55.com ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] visual identification of payee node id
Pavol Rusnak via Lightning-dev writes: > Hi all! > > Currently, when I perform a payment via QR code, I usually check the > payee node id (public key) in the send dialog. However, this is a rather > long hex value, so for example Eclair app shows just the beginning and > the end of the value. > > Idea: Can we show an identicon (for example https://jdenticon.com/) of > payee node id (= public key) next to the QR code, so user can visually > quickly check whether the recipient is correct? I think it would be interesting if someone came up with a visual hashing algorithm, where small changes in the inputs had uniformly random visual outputs. I was testing jdenticon with my node id: 03f3c108ccd536b8526841f0a5c58212bb9e6584a1eb493080e7c1cc34f82dad71 I was surprised to see that small changes to the first digit didn't change the visual output at all. Whether or not this is a useful property in this use case, it's something to keep in mind. Cheers, Will -- https://jb55.com ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] [announce] LNvis alpha - A Lightning Network Visualizer
Hello lightning/bitcoin devs, I've been working on an OpenGL Lighting Network visualizer written in C + nanovg with no dependencies except for glfw. I thought I would release the alpha here first for testing. Right now it only parses c-lightning channels and node json, but I'm currently adding support for LND. I've only tested on linux, so it would be great if we could get this working on macos/windows as well. Picture: https://jb55.com/s/abe49a248360d41c.png Code: https://github.com/jb55/lnvis How it works LNvis renders the Lightning Network channel gossip, which include nodes and the edges (channels) between those nodes. - Channels are colored by the node that opened the channel - Channel widths are rendered proportional to the capacity - Right clicking a node filters the view to that node and its neighbors - Dragging a node in any view will focus that node and its neihbors That's about it for now. Next things that I think would be fun to have: - Filter by alias/id in the UI - "Google Maps" mode for highlighting potential routes between nodes - Realtime channel updates from network gossip Any other ideas and suggesstions would be great. Contributors welcome! Cheers, Will ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput
A convention in Haskell libraries is to use an "unsafe" prefix to any function that may have side effects (here be dragons, etc) I'm happy with a _VULNERABLE or _UNSAFE postfix as a standard way to signal this. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] negative fees for HTLC relay
Benjamin Mordwrites: > [..] > why not allow negative fees to incent unwinding, in scenarios where nodes > consider that cheaper than on-chain rebalancing? This was brought up before here [1]: Rusty Russell writes: >> Edward Marynarz writes: >> Another trivial question: can the fee be negative? It might help with some >> channel rebalancing. >In my original implementation, they could be. However, that turns out >to be a very strange idea, and complicates routing. [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-December/000827.html Cheers, -- https://jb55.com ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Peer selection
ZmnSCPxj via Lightning-devwrites: > Good morning Stan, > >>How to I discover nodes - is there any UI to see nodes currently >>running on the network ? > > There are no UIs to my knowledge. Current LN programs keep track of this in > their databases, although each one varies in detail. Presumably their > individual main developers know how to extract this information. I found this one today [1]. I used it to connect to a couple nodes. [1] https://explorer.acinq.co -- https://jb55.com ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev