Latest Strikes 33 - Apr. 17th-23rd 2023

Latest Strikes 33 - Apr. 17th-23rd 2023
"In The Forest Of Notes". Generated with Stable Diffusion.

Helloooo Ja! Welcome to the 33rd issue of Latest Strikes! In case you didn't know, 33 degrees is the temperature at which water starts to boil in the Newton temperature scale. Do with that piece of information what you wish, but what I can tell you in that the Lightning ecosystem was boiling hot last week. Let's find out what happened, shall we?


Turn You Sats Into Replit Cycles

Thanks to kodylow you can now buy Replit cycles (Replit internal "token") with Lightning. This was developed during the recent Replit Developer Day Hack Night, and the way it basically works is kodylow has a Lightning node running in the Replit environment, alongside a web server which generates a dedicated Lightning Address for any Replit user. When sats are sent to this Lightning Address, the program will automatically send the corresponding amount of cycles to the user. In other words, you swap sats for cycles with kodylow.

I was met with an internal error when I tried it myself, but I found this pretty cool!

Open Source Sats To Watt Interface For EV Charging Stations

Satimoto published the outline of an open source application meant to enable electric vehicles charging point owners to accept Lightning payments for charging sessions. It would leverage LNURL and Nostr to enable OCPP compatible chargers to automatically accept Lightning payments, advertise their status (available, charging a vehicle, in maintenance, etc.) as well as send charging session information (such as current power input or time until full charge) to the user's phone.

For example, you could have a nostr-enabled app that shows a map of available chargers around you. Once at the charging station and the charger plugged into the car, you could start the charging sessions as simply as sending a Zap to the charger's Nostr profile. Your app sends a new payment for every kWh, paying upfront, and when the charging sessions ends it automatically claims any amount paid in excess (because the last paid-for kWh wasn't fully consumed) using LNURL-Withdraw.

OCPP (Open Charge Point Protocol) is an open source protocol for charging endpoints, with the goal to ensure interoperability between various charging station vendors and automakers. Although prominent charging networks such as Tesla or Ionity don't use this protocol (yet?) it is quite widely deployed among many other charging networks. An open source bridge between OCPP chargers and Lightning would hence allow a lot of charging endpoints to potentially accept Lightning payments. If that rings a bell, you can donate to support the development.


The Wavlake team published Wavman, an open source web music player that plays tracks fetched from Nostr. The app connects to one or many relay(s) and fetches notes that correspond to a song, identified by a custom event kind (32123), and containing a document describing the song and where to actually find it (e.g. where to download the .mp3 file from).

The app features an iconic design which will bring a smile to the face of anybody over 20. You can play songs, but also comment on them (comments are sent on Nostr) and even send sats to the artist with a zap. That's one of the things I found particularly interesting with this Nostr integration: the aforementioned document containing all the details about the song (artist, duration, file location, etc.) doesn't contain any payment-related field. Instead, a zap tag with the artist's LNURL-Pay link is added to the Nostr event itself, as for any regular zap-enabled note. In other words, the Wavlake team didn't have to bother with adding a payment field in the document they specified because it is already being taken care of by Nostr itself at the protocol level. When given a thought, this feels quite powerful!


SPeaking of zaps, pablof7z created another great thing called Zapworthy. This one particularly hits home because it's an iteration of an idea I had in mind for a few weeks now, and that I didn't even know Gigi had also formalized.

The idea is simple: highlight/bookmark a part of a text by creating a new Nostr event that contains the highlighted portion while referencing the original post. This way, you can reference the highlighted text in another piece you're writing, and clients can display this quote while allowing the reader to jump to the original post it was extracted from. I had this is mind for the specific use case of technology-oriented pieces, where you often find yourself referencing other pieces (either yours or other's). For example if I'm writing a piece explaining what Route Blinding is I might want to quote short explainers around HTLCs and Onion Routing. I don't want to rewrite them every time, so I'll always link to the same resource, either by adding a reference link in the footnotes or quoting the text itself. I refer to this concept as "content composability", and it feels a bit hacky in the current web as soon as you're trying to compose texts hosted on two different platforms.

On Nostr, everything is a note, from the long-form article to the smallest comment. Clients can compose them at will to offer a feature-rich reading experience. The use cases are far wider than the one I mentioned above. Zapworthy is one of them. Take Gigi's article I mentioned earlier: you can see all the highlights made by others. You can zap any of those highlights, and the sats will be split between the "highlighter" and the original author. Going back to my example of writing a technical piece, this means that anytime someone tips me for the article, the funds are automatically split between me and all the authors from which I borrowed by quoting their work with an "highlight event". Everyone gets their fair share, ideas and data are easier to source, and homo digitalus creativity expands to unknown realms. Per nostr ad astra!

Bitcoin Gaming

Last week Zebedee, in partnership with Guilds, hosted the Bitcoin Games Day (also sponsored by other gaming studios such as THNDR, as well as Lightning-native crowdfunding platform Geyser). The idea behind the event was to "to bring Bitcoin prizes in games closer to masses all over the world" by showcasing how Bitcoin in-game rewards work in various games.

Zebedee and Guilds are also sponsoring a Bitcoin Gaming Grant on Geyser! Video game developers who want to integrate Lightning payments into their game (or already have) can apply until the end of the campaign on Friday May 19th (see this FAQ for more details). Interestingly, the grant goes live tomorrow and will be based on community-voting: the 10 million sats grant (plus any other contributions) will be awarded to projects in proportion of the votes they received. Users can vote with their sats (1 sat = 1 vote), and the sats used to vote will themselves be distributed alongside the grant. I'll be watching this for sure!

File Storing On Lightning

Robin Linus shared some interesting considerations on how one could setup a "decentralized" storage service on Lightning using cryptography and PTLCs. This schemes revolve around the question of file transfer and payment atomicity: the storage service wants to be sure to receive a payment in exchange of the file, while the user wants to be sure that upon payment they will have access to the file. To achieve this, the core idea is to have the file broken down into chunks, which the service stores. When the user wants to retrieve their file, the service sends them the chunks of data, but encrypted,along with a cryptographic proof that knowing a secret s corresponding to a point S on an elliptic curve (e.g. S = sG) is enough to decrypt the file. By setting up a PTLC between the user and the service that is conditioned to the revealing of s, atomicity is achieved: the payment is automatically resolved when the storage services reveals s to the user.

I found this schemes quite interesting, although in my opinion they don't cover the full extent of what one may expect from such a storage protocol. For instance, the storage service isn't paid until the user tries to retrieve the file, and until then stores the file for free. Protocols such as Storm, although more complex, address this kinds of considerations.


Our friends from 10101 are looking for some inbound liquidity! They also officially shut down their former product ItchySat as they prepare for 10101's imminent launch.

Wallets & Tools

LNBits SaaS

Last week LNBits unveiled LNBits SaaS. You can pay by the hour for a LNBits instance running on LNBits servers, and use it as you see fit. You could already use the demo to leverage LNBits awesome features without having to set up anything, but you were then using LNBit's (the entity) LNBit (the software) instance, over which you had no control. This SaaS product allows you to spin up your own LNbits instance, with administration rights, on LNBits servers. From the administration panel you can then configure the instance (notably the funding source, e.g. to which Lightning backend the instance is connected), add users and install extensions.

Regarding the funding source, the default is a "fake wallet" loaded with 1 million fake sats, for testing. In order to receive or send funds to the outer Lightning world, you need to connect LNBits to your own node or wallet (here's the list of compatible nodes). This is a bit meta, but you can also use a LNBits demo account as a backend, which means that your LNBits instance will use LNBit's Lightning channels, just as when you use the demo directly (except there's one more API call, and you can to configure your instance as an admin).

Bear in mind that this SaaS solution is still in beta, but I find it quite interesting for a variety of use cases. Currently, the service only costs 21 sats per hour, and you can buy as little as 1 hour of runtime[1]. If you're interested and wondering how to get started, DarthCoin wrote this very detailed guide.

Also noteworthy: LNBits v0.10.4 is out with a lot of improvements and bug fixes.

BitKit Update

The BitKit wallet got an update. While the wallet is still very much in beta (and part of the new features in this update are warning screens triggered when the user has too much funds in the app) this release brings a lot of bug fixes and improvements, especially on the Lightning part, with which some people experienced bugs in the past. There will still be bugs, but smaller!

Polar v1.4.1

A new version of Polar was released! Polar is a very cool tool that helps you create local Lightning networks on your computer, for example for testing, developing or for educational purposes. This update (the first in 7 months) brings the latest versions of the three major Lightning implementations (LND, Core Lightning and Eclair) and Bitcoin Core in Polar, so that you can use them in your local networks. Additionally, it also features support for Compact Filters in bitcoind thanks to Hampus Sjöberg, which will be useful for people testing light clients on Polar.

Electrum Update

Electrum v4.4.0 is out. While most of the changes deal with the on-chain part of the wallet (as well as a new Android app), there were some Lightning enhancements as well. Indeed, Electrum supports Lightning since July 2020, with a custom implementation that notably features Trampoline routing. In this latest version, enhancements are support for channel aliases (you can give a random "name" to an unannounced Lightning channel instead of the classic short channel id that directly points to the channel's funding output, and hence carries a privacy risk[2]) ; as well as regeneration of Lightning invoices when the routing hints they contain changed due to liquidity movements.

Prism Plugin In BTCPay

Seems like a Prisms plugin will be coming to BTCPay server 👀

Spec & Implems

New Bitcoin Backend In Core Lightning

In the past few months there have been some discussions around having alternatives to Bitcoin Core serve as a Bitcoin backend in Core Lightning. This notably echoes with the consensus issues that arose in btcd and affected LND, although the desire for backend optionality if older than those events.

In this context Vincenzo Palazzo published Folgore, a Core Lightning plugin that serves as a Universal Bitcoin backend. In other words, it is a little program that allows your Core Lightning node to get its on-chain and mempool data from another source than Bitcoin Core. It is built on top of nakamoto and hence supports BIP157, a privacy-preserving, efficient light client protocol using block filters, which is also used by Neutrino.

Closing Bit

Le temps d'un soupir tout est suspendu
Le delta s'élargit tandis que le temps coule
Quelques minutes passent, un pont enfin enjambe
L'étendue toute entière de l'incertain cerné.

  1. When your time runs out the LNBits instance is automatically shutdown until you pay for more hours. After 1 month of inactivity the instance is deleted. ↩︎

  2. The short channel id is defined as the concatenation of the height of the block where the funding transaction happened, the funding transaction index in the block, and the index of the funding output in the transaction. In other words, it points directly to the channel's underlying UTXO. Using this as the channel alias (which you use for example in routing hints) hurts your privacy because it gives chain analysts an entry point to your on-chain funds. Note that for announced channels, the use of the short channel id is mandatory, as it serves an anti-DoS purpose toward the gossip layer of Lightning. ↩︎

Privacy Policy