Latest Strikes 54 - September 11th-17th 2023

Hi Lightninger! Fancy a little recap of last week's Lightning news? You're in the right place! Last week we got to know more about the vulnerabilities that affected Electrum in versions before 4.4.6, enjoyed a whole bunch of new product launches, and fancy discussions. Let's dive in!

Ecosystem

Tournament & Grants

Bolt.Fun announced the second edition of their Legends of Lightning tournament! The contest will take place from October 5th to December 17th, both online and in meat space with 5 in-person hackathons worldwide. Participants are free to jump in with their project anytime during the tournament, and will compete for a share of the 2.5 BTC prize pool. Note that, while participation to the in-person hackathons is totally optional, there will be 2 prizes available for those who decide to take part to both the global (remote) contest and a local (in-person) hackathon.

On a different note, the winners of the 5th round of Geyser grants were announced last week, rewarding community projects that expand Bitcoin education and adoption worldwide.

Gputopia

Got a nice GPU in your computer but it's essentially staying idle? Maybe you can try to put it to work on Gputopia. This new platform seamlessly connects buyers and sellers of GPU computation, through the power of Lightning. If you want to provide some power, all you have to do is open the website on your browser (only Chrome and derivatives, since it requires WebGPU), connect with your Alby account, and you're good to go! You'll start receiving sats once the AI language model you'll work on is loaded. For now, it seems your GPU will only work on demo jobs, since there might not be enough buyers yet, but the sats are very real, and you can withdraw same instantly whenever you want, straight to your Alby account, with only one click.

Of course, Gputopia is still very much early. It remains to be seen whether the service will attract enough buyers, and whether rewards will remain attractive. There might also be concerns around data privacy, since a buyer might not want unknown sellers to be able to see what inference jobs they're asking them to do^[1]. However it's a very interesting project, which showcases how Lightning can be leveraged to easily develop markets for all kinds of stranded resources in cyberspace, and how Alby's developer tools can help builders focus on their core application in the early phase, instead of having to develop a full Lightning and authentication toolset from scratch.

Note: Gputopia fell victim to its own success and is paused until the v3 is rolled out in the coming days. Incidentally, the v3 will also bring real jobs, bought by real buyers. So we'll get to see how it plays out in the coming days.

Lightning In Your Pocket

European Lightningers, rejoice! Pocket officially launched their "Lightning top-up" service which lets you send dirty fiat via a bank transfer and receive precious sats directly to your Lightning wallet (as of now, only Phoenix and Breez are supported, but more to come in Q3, including custom node support).

The way it works is quite similar to Pocket's existing on-chain product, but with a Lighting twist in the end. You'll need to provide Pocket with an email address and an IBAN, and initiate a top-up by indicating how many sats you're willing to buy. The website will then give all the details you need to wire them your euros. Once it reaches Pocket's bank account, they'll send you a link from which you can withdraw the funds, on Lightning, straight to your wallet, using LNURL-Withdraw.

That's pretty sweet, and reinforces what I call the "paycheck-to-paycheck" case for Lightning: top-up your wallet once you receive your salary, and gradually spend it over the course of the month. This way, liquidity is always on the side of your channels where you need it to be, and Pocket's new feature just makes it even easier, especially if you still receive your salary in euros. After all, Lightning is for spending!^[2]

Wallets & Tools

Electrum Lightning Vulnerabilities Disclosed

We know more about the 2 Lightning-related vulnerabilities that were recently patched in the version 4.4.6 of Electrum, as we reported a few weeks ago. One vulnerability concerns receiving with Lightning, while the other deals with sending.

• When receiving money, Electrum could get confused if two payments were going on at the same time and were resolved using multi-path payments, where a payment is fragmented into smaller bits that are forwarded across the network along different routes (which is pretty much standard procedure now). Basically, an attacker could trick Electrum into believing a payment was fully-paid while it was not, thus revealing the preimage while parts of the payment were still due.
• On Android, when sending a payment, the Electrum app didn't properly checked that the preimage returned actually matched the payment hash before settling the transaction. In other words, the peer through which you routed your payment could have stolen the money by claiming it for themselves and providing you with a random preimage.

For more details about the vulnerabilities, the chronology behind their disclosure and how they were fixed, please visit Electrum's security advisories.

Amboss Launches Hydro For Automated Channel Management

Amboss launched a new tool called Hydro which lets node operators automate their channel management, while the required liquidity is automatically sourced on Amboss' Magma marketplace. Users can define different automation strategies, which address different sets of needs. For example, a business can use Hydro to ensure that their inbound liquidity (i.e. their ability to receive payments) remains above a certain threshold. To do that, Hydro will periodically check the node's inbound liquidity, and buy a new channel on Magma whenever needed. However, this entails privacy considerations, as it means sending Amboss information about the liquidity distribution inside one's channels -- data that is usually kept private. For more privacy-conscious users, the automation rule could only concern itself with the node's public capacity (already known network-wide, by definition), buying new channels anytime it drops below a certain amount.

Hydro's management fee, as well as the cost of buying channels on Magma, are prepaid using Amboss' internal credits called Ambucks.

Testing Tools

Max Edwards showcased how SimLN and Scaling Lightning can work hand in hand, since the latter helps you perform tests on a local Lightning Network, while the former populates said network with realistic payment data.

On a different note, Vincenzo Palazzo shared his Lightning Network Interoperability Initiative, which aims at providing a set of unified testing tools to help Lightning developers assess whether their implementation is in line with the specification AND interoperable with others.

Testing tools and frameworks have been a recurrent theme in the last newsletters, which I think is a very good sign of Lightning maturing.

Some Releases

LNBits v0.10.10 was released, with a lot of enhancement, bug fixes and new features. Notably, this new release brings support for using cln-rest as a node backend, which I believe could not to painfully be adapted to also support Core Lightning's new native REST API CLNRest. This new API, introduced in the latest major release, was designed as a superset of cln-rest and ships natively with new versions of Core Lightning, which is pretty handy!

The version 1.1.1 of Torq was also released last week, enhancing notifications (with a Discord integration and notifications triggered by automated workflows), more detailed payments summary, and a bunch of other improvements.

Spec & Implems

Core Lightning Bug Fixes

The version 23.08.1 of Core Lightning was released last week, bringing mostly minor bug fixes (notably to the renepay plugin which enables Pickhardt Payments on Core Lightning for enhanced payment reliability).

Sidepools For Improving Payment Reliability At Scale

Zman proposed an interesting mechanism on the Lightning-Dev mailing list that would allow routing nodes to more efficiently manage and reallocate their liquidity. Indeed, one of the current hurdles of managing a routing Lightning node is that the operator needs to evaluate (sometimes, guess) who to open channels with, and when. Misallocating funds (e.g. opening a channel that doesn't end up being used) is costly, because it means wasting sats in on-chain transaction fees to open and close the channel to reallocate the funds somewhere more useful.

Zman proposal, called "sidepools", is essentially a big "PeerSwap Party". PeerSwap is a protocol where two Lightning peers sharing a channel can agree to rebalance the channel between themselves by performing an atomic swap: the party that had too much liquidity on their end of the channel moves it to the other end and receives the same amount on-chain (or on Liquid). A sidepool is essentially a big N-of-N channel (à la Eltoo) between a bunch of routing nodes. This routing nodes can then settle PeerSwaps inside this "big channel" instead of going on-chain, during a big "party" where the state of the sidepool evolves to reflect the new distribution of funds.

Trivia Of The Week

How long can a funding transaction stay in the mempool until the channel opening is "cancelled"?

Closing Bit

Dernière lumière
Dans la nuit qui partout
Règne.

A l'heure où dorment les braves gens
S'étire le temps
Et je fais le dos rond.