Latest Strikes 42 - June 19th-25th 2023

Hello, and welcome to... Wait! Hold on. Which Latest Strikes issue are we at? That's right: 42. So get your galactic Michelin Guide ready, because we're going on a space journey! But as you may know, the outer space is vast and space travel takes a long time, even when using an hyperspace highway. You know what, let's chat about what happened in the Lightning ecosystem last week. That'll kill the time for sure. Should I drive?

Ecosystem

Spiral Grants

Spiral announced a new grantee and the renewal of an already active one! The new grantee is Matthew Ramsden, known for his work on the Bitcoin Dev Kit (BDK) and the Bitcoin Design Community. Matthew is also planning to work on Swift bindings for the Lightning Dev Kit (LDK), and continuing his work with the LDK Node, which would make it easier to develop Lightning apps with LDK for iOS. More on that later!

Spiral also renewed Pavlenex's grant. Pavlenex is well-known for his work as product manager at BTCPay Server and on Stratum V2.

Stats

As Amboss pointed out last week, we're slowly but surely heading towards a new All Time High in terms of capacity on the network.

Kevin Rooke also reported that weekly sales on Amboss' Lightning liquidity marketplace Magma reached a new ATH for 2023, just a few weeks after the company unveiled its new Lightning rate and yield index called LINER.

Time-based Rewards In Zebedee

Zebedee just launched a new way to earn Bitcoin while playing games: time-based rewards. Players receive a few satoshis for each minute they play any of the 100+ partnering games. The only condition is to access said games from Zebedee's app ZBD.

Contrary to previous Zebedee-related mobile games, these new games were not particularly designed with Bitcoin rewards in mind. Rather, they're part of a catalogue of games participating in Adjoe's Playtime network, enabling time-based rewards. This technology is already used by other apps such as Mistplay, where players earn "points" as they play, which they can later redeem for gift cards or PayPal transfers. Zebedee plugged into this network as well, and now earns a fee from the game companies for every user they bring, based on the time they play. This commission is usually a portion of the ad revenue the game company earns by showing ads to players. Hence the time-based revenue model: the more they play, the more ads users see.

Where Zebedee fits perfectly is that "play-to-earn" mobile apps usually require users to reach a certain threshold (the equivalent of a few dollars) before they can convert their points into anything useful (say, an Amazon gift card). On the other hand, players going through the ZBD app get fractions of pennies (as sats), in real-time, every minute they play. They can then withdraw those sats from the ZBD app instantly, whenever they want.

A lot can be said about the Attention Economy and its impacts. However, for the millions of mobile players-earners globally, having a company such as Zebedee step into the industry is a game-changer. They'll go from having to play dozens of hours to accumulate enough points to reach withdrawal thresholds, to being able to withdraw as soon as they play a few minutes and earn their first satoshis. Instant rewards, paid in the best money that ever existed. What else?

Voltage Surge Available To All Users

Voltage's Surge observability tool is now available to all Voltage users. Surge allows node operators to quickly and easily access and visualize insightful data about their node: health status, past payments (along with their success rate), channels (to see which need rebalancing, are inactive, etc., as well as each channel's historical activity), peers, etc.

The data is fed to the Surge Dashboard by a read-only agent that periodically fetches data from the node, without having access to any funds. Surge is hence a read-only observation tool, from which no action can be taken, which can be seen both as a strength or a weakness. On the plus side, the read-onlyness means that is it fairly easy to hand a Surge access to an employee that needs to monitor some aspects of the node. However, this also means that performing actions to address issues arising from observation still requires additional software (such as Thunderhub or Terminal Web, which are conveniently accessible from Voltage's dashboard).

Surge will probably keep evolving. The agent is still closed-source, but Voltage pledged to open source it in the near future. New functionalities might involve refined permissions and a "write" mode enabling specifically authorized personnel to undertake actions. This would fit coherently with Voltage's core target -- businesses -- and their vision that "every company will be a Lightning company".

Qala Fellows Show Some PoW

Qala fellows shared their proof of work with the world last week. Qala is an education program for experienced developers, helping them transition to a Bitcoin/Lightning career through fully-funded fellowships. During last week's session, eight fellows showcased what they've been working on in the last 5 months, from writing technical articles to contributing to Bitcoin/Lightning open source projects, to building their own things.

Quite impressive if you ask me. If you're a company looking to hire some talents, reach out to Qala or to the fellows themselves: their contact are on the slide deck!

Santander Talks Lightning

Santander, Spain largest bank, published a blog post about Lightning, describing how it helps enhance Bitcoin scalability by enabling users to perform cheap transactions with instant settlement. Funnily enough, while the beginning of the piece deals with "the Lightning Network", the tone switches in the end and addresses liquidity issues in Lightning Networks. I don't know if it's just regular vagueness, accounting for 💩coins Lightning networks (such as Litecoin or Decred), or testimony that whoever wrote this piece understands that there is no such thing as the Lightning Network.

Indeed, as John Carvalho highlighted back in 2019, there is no global consensus on Lightning, but merely a common protocol which implementations are convergent enough to enable interoperability. But various implementations are free to prioritize some features over others, even developing things they are the only one to support. That's completely allowed and expected by the Lightning protocol, which is why nodes are able to set and advertize per-channel and or per-node features. For now the set of features is quite convergent, but we're already seeing differences in feature prioritization across implementations, and I expect this to be even more the case in the future. And that's ok: there can totally be different subsets of "the" Lightning Network, tailored for different use cases or to maximize different outcomes. Two subsets may or may not be able to communicate through nodes that are compatible with both flavors of the protocol -- but I expect they will.

A bit more concerning is the perspective described by Odell back in March that the real split between Lightning subnetworks might be the one separating KYC-abiding nodes and channels from the rest. That's a daunting vision, presumably the one that banks such as Santander will need to embrace if they're to jump on the Lightning bandwagon. So having a bank write about the greatness of the Lightning Network(s) is cool, but cheer with caution my friends.

Wallets & Tools

CivKit Node

Remember CivKit, the proposed censorship-resistant peer-to-peer market system built on top of Nostr and the Lightning Network? The idea came a bit closer to reality last week with the release of the very first (and early) version of the CivKit Node.

A CivKit node is basically a Nostr relay which also connects directly to Lightning nodes. CivKit nodes receive trade offers via Lightning Onion Messages, and then broadcast them on Nostr to all listening clients. They form the backbone of the CivKit system, and this first alpha release will allow developers to begin testing and playing around with CivKit.

LDK Node

The Lightning Dev Kit (LDK) is a versatile and powerful library implementing the full Lightning Network protocol. One of the key aspects of the LDK is its modularity, which allows developers to use it for a variety of use cases, from big Lightning nodes at CashApp to lightweight, mobile Lightning nodes (for example, the LDK powers mobile self-custodial wallets such as BitKit or Lipa). However, this modularity also means that a lot is left to the app developer: the LDK doesn't even come with an on-chain wallet, so it's up to the developer to choose which on-chain backend to use and plug the LDK on top of it.

That was until last week, when the LDK team released the LDK node, a ready-to-go Lightning node library. The LDK uses the Bitcoin Dev Kit (BDK) as its on-chain wallet out of the box, and the software comes with a sensible default configuration, while remaining customizable enough to serve a variety of use cases. It comes with around 30 built-in methods, which allow users to send and receive both on-chain and on Lightning (including with keysend), open and close channels, manage peers, etc. Enough to cover most of the operations a typical Lightning node performs.

Remember Matthew, our Spiral grantee from the beginning of this newsletter? He already developed an example iOS app using the LDK Node. It's still experimental, not even on mainnet yet, but is a great example of what the LDK Node allows developers to build!

UmbrelOS Update

UmbrelOS got an update which ships some fixes, a revamped UI for the Umbrel App Store, as well as a migration assistant enabling users to seamlessly transfer their node from their current machine (e.g. a Raspberry Pi) to their new Umbrel Home.

Boltz Gets A Makeover

Boltz atomic swap service got a makeover with:

• a new user interface,
• swaps from Lightning to Taproot on-chain addresses,
• the ability to run Boltz on one's phone as a Progressive Web App (PWA), thus circumventing app store censorship that could have arose with a "real" mobile app.

Spec & Implems

Dual-Funding, Splicing & Bolt12 Offers In Eclair

You've read it right: as of version 0.9.0, channels dual-funding, splicing and Offers are fully implemented in Eclair. All these features are still experimental and hence disabled by default, and it is recommended to only enable them if you know what you're doing. The Acinq team is now waiting for the specification work to be finalized and other implementations to be ready to perform cross-implementations compatibility tests.

As a reminder:

• dual-funding enables both parties of a channel to contribute funds to the opening of the channel, whereas currently only one of the two participants does. With dual-funding, channels can begin their life already well-balanced, which means easier access to inbound liquidity and lower capital requirements for individual node operators ;
• splicing allows for the resizing of Lightning channels without having to close them. Currently, a channel's size (or capacity) is set in stone at the opening of the channel. If your need evolves and you'd like to have a bigger or smaller channel with a peer, your only option is to open a new channel (and potentially close the old one). With splicing, you can resize an existing channel with only one Bitcoin transaction, which means better on-chain efficiency and higher uptime for your channels. This is also particularly useful for LSP who constantly need to adapt to their users liquidity requirements ;
• Bolt12 Offers are Lightning-native static payment codes, a bit like LNURL-Pay, but where everything happens on the Lightning Network itself rather than with HTTP requests. When you create and display a Bolt12 Offer, anyone can use it to query an invoice from your node and pay it, without you needing to be around. This is hence a huge UX improvement.

Eclair's Dual-Funding implementation is fully aligned with the existing specification (which the Eclair team contributed to extensively), while their Splicing implementation differs from the current specification proposal, since the Eclair team came up with various improvements which will be merged into the specification.

Regarding Bolt12, Eclair can now natively pay Offers, but receiving using Offers will require running a plugin on top of Eclair, which will create offers and handle invoice requests.

See the full release notes for more details, as well as to see what other things this update brings (notably channel open acceptance and configuration). And kudos to the Acinq team on this milestone!

Payment Hash Does Not Commit To Payment

The Lightning-dev mailing list got a quick heads up from Calle, reminding everyone that the "payment_hash" of a Lightning invoice doesn't actually commit to the payment itself. Rather, it sets the condition under which the payment can be claimed: the revealing of a preimage which hash is equal to the payment_hash (e.g. hash(preimage) = payment_hash).

The LNBits team discovered an exploit in the LNBits codebase that could be used to create sats out of thin air, and stems directly from this misconception. A payment's "payment_hash" is not a unique identifier, and one should always perform additional checks (for example on amounts) when trying to correlate two payments.

Closing Bit

Une brise naît au creux du fort
Elle s'enracine et se projette
Bientôt elle recouvre la plaine entière.

Elle se mue lentement en tempête
Laboure l'aire, emporte le bois mort
Et, s'arc-boutant, étire l'univers.