“What’s happening, hot stuff?”. Well, Jake, hot stuff surely happened last week in the Lightning world! We got a complete wallet working in the browser (well, on signet, but still!), a new advertising model, more adoption, and a lot of updates. Let’s dig in, shall we?

Ecosystem

Power Of Lightning Summit

Nashville will be lit in July! The Power of Lightning Summit will take place at the Bitcoin Park on July 13th and 14th, with an already impressive list of speakers!

Satimoto Demo

The Satimoto team shared a very cool video demo of what it looks like to open their app for the first time. Users can get all set with their own self-custodial Lightning-powered electric vehicle charging wallet in a matter of minutes, thanks to the power of Blockstream’s Greenlight and the Breez SDK. What’s even better is ultimately different apps will be able to connect to the same node, to provide the same self-custodial frictionless experience for different use cases, from EV charging to food delivery, without necessarily having to bootstrap a whole new node every time. Inspiring!

Lightning Login In Bitrefill & Lightning Withdrawals In Swan

It is now possible to login into Bitrefill using one’s Lightning wallet (via LNURL-Auth) ; and it will soon be possible to withdraw from Swan directly to a Lightning wallet!

Neutronpay Launches API Products, Partners With Pouch And Bitnob

Canada-based Lightning infrastructure company Neutronpay launched its API product for customers in Asia and North America. This notably enables North American companies that often need to pay providers in the Asia-Pacific region to do it in a more cost-effective way by using the Lightning rails.

On top of that, Neutronpay also secured partnerships with Pouch and Bitnob to provide easier, faster and cheaper remittance between Canada, Vietnam, and many African countries. Once again, Lightning’s superpower – easy interoperability – strikes!

Zapvertising

There’s a new ad model on Nostr called Zapvertising, where the idea is for brands to use zaps directly to promote their brand or products. On Nostr, a zap is when someone sends a tip to another Nostr user, and this tip is displayed for everyone to see. For example, if I zap a post I find interesting, a lot of Nostr client will show my tip below the post, and everyone passing by will see it. Although it can raise some privacy concerns (which we discussed here, alongside how zaps work on the technical side1) the public nature of zaps can be used creatively in a variety of situations, from content curation to advertisement, as showcased by zapvertising.

You can indeed send a comment alongside your tip when zapping someone, and everyone will see that comment too. Given than on most clients zaps are ordered by amount, the bigger ones being on top, there’s an opportunity for companies to zap great posts in order to get exposure, as they will ride the post’s popularity alongside it. Of course, it’s a double-edged sword. For instance, if users feel that your advertising is spammy, this will hurt your brand’s perception rather than improve it. The tip attached to the ad helps make things fairer, since the original producer of the content gets compensated: it’s not a free ride, the brand pays for being “attached” to the post. Ultimately, what happens is that instead of platforms and advertising networks getting the lion’s share of ad revenue while content creators get close to nothing AND can’t decide what ads are displayed alongside their content, now content creators get all the ad revenue, and the situation is not worse when deciding which brand gets to promote itself alongside your content2.

I have a bit of a mixed feeling regarding zapvertising, but Blockstream gave it a try, and the positive results tend to overcome my skepticism a bit. However, it remains to be seen whether it really works at scale, since there is no limit to the number of “ad slots”/zaps attached to a post, and we could quite quickly find ourselves submerged with dozens of low amount zaps from inauthentic “brands” that don’t really get the implicit rules of the zapvertising game below every Nostr note.

Operating a Lightning Node

RecklessApothesis published this nice Lightning Network Security Overview detailing many of the security implications of running a Lightning node. Voltage also shared their advice on running a node in a high on-chain fees environment, while Toni Giorgio explored whether a bug in mempool.space3 could mislead some Lightning nodes as to what the current fee rate is, leading to channel closures when said nodes fail to properly negotiate fee rate with their channel counterparts. This could explain a recent surge in Lightning channels force closes.

Wallets & Tools

Mutiny Web On Signet

Had fun playing around with the Fedi Alpha on signet last week? You can now double the fun by sending from Fedi to Mutiny (and vice-versa)! The Mutiny team released a signet version of their browser-based wallet, with non-custodial on-chain and Lightning support, just-in-time channel opening via Voltage’s Lightning Service Provider (both for receiving funds on Lightning for the first time, or deploying some of your on-chain balance into a Lightning channel via the “swap” feature), experimental Nostr Wallet Connect support and LNURL Auth and Pay!

I must say I really like how Mutiny feels, and having a fully-fleshed Bitcoin and Lightning wallet in the browser feels incredibly powerful. And there’s more to come!

Raspiblitz Update

Raspiblitz got a big update, with a lot of new features! Recent additions include:

  • a Core Lightning watchtower plugin (The Eye of Satoshi),
  • automation tool LNDg,
  • lnproxy server,
  • accounting tools,
  • and more!

On top of that, this new release also updates a lot of the existing apps and Lightning implementations themselves.

Other Releases

Other notable releases last week include:

  • Torq v0.22.1 with experimental support for Core Lightning (!) and some improvements (notably for setups with multiple nodes) ;
  • Polar v2.0.0 which adds support for Taproot Assets (formerly Taro) nodes, latest versions of LND, as well as a nice user interface for automatically mining new regtest blocks every set period of time ;
  • BitBanana (formerly Zap Android) v0.6.2 brings reproducible builds, more details to channels view, and improved Lightning fee limit settings ;
  • LNBits v0.10.8 ships a lot of fixes and enhancements.

Spec & Implems

Going Deeper On Ark

As promised in last week’s issue, let’s dive a bit deeper on Ark, the new Layer 2 protocol proposed by Burak. The idea behind Ark, which originally started as a new Lightning wallet before becoming a completely different scaling approach, is to overcome some of Lightning limitations. Namely: the inbound liquidity problem and interactivity requirements4.

Bitcoin Optech already made a fantastic job summing up and explaining the technical discussions that took place around Ark last week, so I encourage you to give it a read if you want to get a better understanding of how Ark would work. As Burak himself put it in his Bitcoin Miami 2023 presentation, Ark is “chaumian e-cash meet[ing] trustless hub-and-spoke model”. Let’s see what that means.

Central to Ark is the notion of Ark Service Provider (ASP). Multiple users are engaged in a relationship with the same ASP, a bit like many users interact with the same coordinator when coinjoining, or many users are part of the same e-cash mint. To deposit bitcoin with an ASP, a user simply needs to send funds on-chain to a special 2-of-2 multisig address from which the ASP can claim the funds with the collaboration of the user, or the user get their funds back after a 4 weeks timelock (in case the ASP becomes unresponsive). The ASP claims the funds on-chain and issues funds off-chain to the user, in the form of one or many “virtual UTXOs” (vTXOS), atomically.

It took two on-chain transactions to trustlessly “lift” funds to the ARK L2, but the user can now dispose from their vTXOs to either send them to another user of the same ASP, retrieve them on-chain, or send them to someone else on Lightning though their ASP.

Off-chain transfers in the same ASP take place every few seconds in an off-chain coinjoin between many vTXOs. Some of the transfers taking place in the coinjoin are self-transfers, while others involve change of ownership, but nobody (even the ASP) is able to tell. This off-chain coinjoin of vTXOs is represented on-chain in a single output from which spending is constrained using covenants such as Anyprevout (APO) or CheckTemplateVerify (CTV)5. In other words, many simultaneous off-chain transfers are bundled into only one small on-chain transaction which typically only contains a few inputs and outputs, and this every five seconds or so.

When it comes to sending funds to Lightning, this can be achieved by “transforming” a vTXO into an HTLC (or a PTLC) inside an Ark coinjoin. The ASP, which is running a Lightning node, will take care of forwarding the HTLC/PTLC to the next hop. In-flight HTLCs are represented in the on-chain transaction like vTXOs are (e.g. they’re all “summarized” in only one covenant-constrained output), but in a separate output.

There are still many points to clarify around how Ark works, but there are already very well identified tradeoffs. For instance:

  • while the on-chain transaction that “carries” an off-chain transfer doesn’t have enough confirmations to be considered safe (e.g., somewhere between 1 and 6 confirmations, depending on the amount), the receiver is not accepting the funds in a fully trustless manner. Or, as Burak puts it: “Ark has immediate availability with delayed finality”. That could be addressed with Fidelity Bonds, as Optech explains ;
  • the on-chain footprint seems to be quite important with 1 transaction per ASP every 5 seconds, even compared with Lightning, although it ultimately depends on how many off-chain transfers are abstracted into each on-chain transaction.

So while Ark is definitely interesting and does solve the inbound liquidity problem (since it works with a UTXO model, just like Bitcoin, and users can hence receive funds without any prior liquidity requirement), it remains to be demonstrated whether it actually allows for the same transaction throughput as Lightning, and whether its on-chain usage is actually more effective.

Closing Bit

L’oiseau s’est posé dans un fracas sourd:
Le monde entier a tremblé.
Je n’avais pas réalisé que nous étions si près du nid.

Want to receive Latest Strikes straight to your inbox every week? Couldn’t be easier: subscribe to LN Markets Ghost blog and you’re all set (remember to confirm your subscription by clicking the link sent via email).

If you enjoyed this recap, you can show your appreciation by throwing a few coins to fanis @ lnmarkets.com, by scanning or clicking the QR code.

Thank you!

  1. Also bear in mind that it is now easier to zap anonymously than it was at the time of writing this previous issue. ↩︎

  2. We could even arguably consider that zapvertising gives content creators more control over the ads displayed below their posts. Indeed, as the zaps specification details, while the comment (and hence the ad itself) lives in the zap request which is a note generated by the tipper (here, the brand), clients could check for the corresponding zap receipt of every request (which is issued by the content creator on receiving the payment), and only display a zap if both notes are present. Content creators could then set up filters than automatically disregard zap requests from certain npubs or where the comment contains a certain set of words (for example, a brand’s name or product): their node would then refuse the payment and not send any zap receipt. It could even accept the payment and still not send the zap receipt, which would deter the brand from trying again since it cost them money without any added brand exposure. ↩︎

  3. More precisely, the bug seems related to the way Bitcoin Core itself counts the weight of a transaction differently depending on how it is evaluated. See this thread for more details. ↩︎

  4. Although, as Burak recognizes, asynchronous payments (with proof-of-payments) can be achieved with PTLCs (and the use of LSPs). The main issue that remains is hence the requirement to already have inbound liquidity in order to receive payments on Lightning. ↩︎

  5. The same could be achieved without any covenants, and hence without any soft fork, by using n-of-n multisigs, where n is the number of vTXOs inputs. But this is a (very) strong interactivity requirement, especially as n tends to be big, which undermines the sole purpose of Ark as a non-interactive alternative to Lightning. ↩︎