Ecosystem

Lightning For Enterprises

MicroStrategy World is an annual conference held by the business intelligence software company MicroStrategy to showcase its latest products and technologies and gather developers, architects, business users, decision makers and data enthusiasts from all around the world. During the 2023 edition that took place last week, a large part of the program was dedicated to Bitcoin and Lightning, and how they can be leveraged in the corporate world.

Notably, MicroStrategy unveiled its new Lightning platform, tailored to “address enterprise-specific use cases with the Lightning Network”. This is currently a twofold product designed to help nurture a company’s bond with its employees and its customers.

The idea behind the “employees” side is to incentivize good behavior through rewards in sats. Examples given at the conference are showing on time to meeting, attending corporate events, or hitting fitness goals. The purpose of the customers-facing side of the product is to increase engagement, for example with rewards for shopping or answering surveys. In other worlds: replace loyalty points with sats.

I truly believe a model where companies and brands reward customers with sats make sense, especially to thank them for their feedback or their loyalty, as in both cases it triggers a positive feedback loop that benefits the enterprise and the customer. On top of that, companies often already have a budget for things such as surveys and loyalty programs, which gets eaten mostly by third parties such as advertising or polling companies. Why not cut out the middle men and still spend the same budget, but to reward customers directly?1

On the other hand, I’m much more skeptical when it comes to incentivizing behavior in the workplace with sats. Maybe it’s a cultural thing, but in my opinion if a job requires nudging the employee with sats, it means the employee and the job don’t fit, and no amount of sats can really fix that. There are only a few reasons why an employee would be late to meetings for example: either they’re not paid enough, and rewarding them sats for showing on time is almost insulting ; or it’s not about money and sats rewards are useless. Moreover, I’m quite confused about the idea of incentivizing fitness or attendance to some events with sats. It’s simply not the place of a company to dictate what employees do in their free time.

What Is Going On At Tippin?

There were reports last week of popular custodial Lightning platform Tippin being unavailable without notice for several days. Tippin is quite popular because it provides an easy way to receive tips in sats, and was historically one of the first services to facilitate tips between Twitter users through the Lightning Network. I can confirm that I was unable to access my account, and that Tippin’s Lightning node appears to have been offline for an extender period, while nobody answered users’ legitimate worries on the usual communication channels such as Telegram.

However, the service seems to have come back up recently. We’re still waiting for an official communication from the Tippin team through, so in the meantime I’d advise anyone having funds on the platform to withdraw to a non-custodial Lightning wallet. As always: not your keys, not your coins.

Fedi Raises $17M

Fedi raised an additional 17 million dollars in a Series A round led by Ego Death Capital, bringing the total amount raised by the company so far to a symbolically-charged total of 21.21 million dollars.

Fedi is a company building on the open source Fedimint protocol, with the intent to create “Federated Operating Systems” where users can collaborate through federations to exchange money, data, and live their digital lives among a community. Currently, the cornerstone of the project are federated eCash mints2, built using the aforementioned Fedimint protocol. They work quite like other privacy-preserving eCash protocols (such as Cashu, which actually came later) with one very important differentiating feature: in a federated mint, the money is not held by a single centralized entity, but rather collectively managed by a set of “guardians”. This federated model brings more reliability (since as long as a majority of guardians are online transactions can occur inside the mint) while reducing the chances that the users’ money gets stolen by the mint operators, since it also requires a majority of them to collude to be able to exit the mint with the funds.

Much like Cashu, there can be several different Federated mints that can interact with each other using the Lightning Network. Inside each mint, Lightning Gateways are responsible for converting eCash tokens (which only exist/hold value inside a given mint) into actual sats on the Lightning Network, as well as sending said sats to the final recipient (who can very well be a user of a different mint, in which case a Lightning gateway in the receiver’s mint will convert the sats back to eCash tokens and credit them to the receiver’s account).

It should again be highlighted that those are different eCash tokens: tokens created on mint A have no value on mint B, and vice versa. What connects mints together is the use of a common form of money (bitcoin) and a common set of protocols (LNP/BP) and networks (Lightning & Bitcoin). That’s very powerful. It means many alternative eCash implementations can coexist, each with its set of pros and cons (for example, while Fedimint uses federations to mitigate counterparty risks, Cashu showed how easily and quickly Ligthtning-enabled eCash mints can be deployed).

Speaking of Cashu, a new version of Feni (a Cashu mint and wallet implementation in Go) was released last week, with support for NUT-08, which enables mints to refund users when they overpay on Lightning fees (see Latest Strikes #26 for more context on this specific issue).

Dorsey Donates $10M To OpenSats

Jack Dorsey donated $10M to OpenSats open source fund. Half of this amount will be devoted to Nostr, while some of the rest might trickle down to some cool Lightning projects? Fingers crossed 🤞

Bisq And HodlHodl Set To Integrate Lightning

A full mempool means slower, more expensive transactions. HodlHodl and Bisq, two P2P Bitcoin trading platforms, have reiterated that they’re working on integrating Lightning into their products to better serve their users in times of high on-chain usage.

Side node: the centralized exchanges that took the bear market as an opportunity to build Lightning support into their platform are unaffected by the current surge in on-chain transaction fees. Some of those that didn’t had to momentarily halt withdrawals (in spite of contributing a significant part of Bitcoin’s hashrate with their own mining pool, and hence being able to prioritize their own transactions).

Something To Keep In Mind With Those High Fees

While Lightning is definitely very useful in times of high on-chain activity and skyrocketing fees, we must also keep in mind that said on-chain activity limits our ability to trustlessly transact on Lightning.

Indeed, when a payment goes through the Lightning Network, in each channel along the payment’s route the nodes sharing the channel must update the channel’s state to account for the on-going inflight payment. This is done by creating a new commitment transaction, which is an unpublished Bitcoin transaction that spends the funds on-chain from the channel to the addresses of the channel’s parties. When a payment is in progress and part of the channel’s funds are hence in a state where they can be claimed by both ends of the channel under different conditions, this is represented by adding an output to the commitment transaction, which can be spent by both parties under the aforementioned conditions. This is how we achieve trustlessness in Lightning payments: it is always possible to go on-chain and resolve any “dispute” (such as a node not responding) there.

However, each node of the Bitcoin protocol has a policy called the dust limit, which dictates the minimum amount an UTXO should have. If, for a given transaction, any UTXO’s amount is below this limit, the node will not relay the transaction. This is per-node policy only affecting transaction relay (and not block relay). The definition of dust is concisely expressed as follow in Bitcoin Core:

If you’d pay more in fees than the value of the output to spend something, then we consider it dust.

In other words, if the cost of spending an output is greater than the output’s value, then it is considered dust. As we can see, this means that the threshold below which an output is considered dust depends on the current minimal fee rate. The default, minimal fee rate used by most Bitcoin nodes for the dust limit computation is 3 sats/vB. At this rate, you’d need to pay at least 330 satoshis to spend a P2WSH or a P2TR output (because it requires a 110 vB transaction), so any such output amounting for less than 330 satoshis will be considered dust and not be relayed. Corollary: any Lightning payment below this amount will not be represented with its own output in a channel’s commitment transaction. Such a payment hence cannot be considered fully trustless.

And yet, we use Lightning for micro-transactions all the time. Payments way below 330 sats fly across the network 24/7. While those payments are not fully trustless, they can still be safely carried away because of two factors:

  • they’re quite small,
  • should our channel partner force close the channel, we would admittedly not receive the sats of this specific payment on-chain, but neither would our channel partner. The sats would just go into the transaction fees and, ultimately, in a miner’s pocket.

However, when mempools with the default 300MB size begin to get full, they flush transactions, starting with the ones paying the less fees (which is approximately equivalent to removing transactions by ascending order of their fee rate in sats/vB). When this process kicks in, nodes also stop relaying transactions that are below the new minimal fee rate. In other world, the minimal fee rate gets higher, and so does the dust limit.

So while Lightning definitely works better than on-chain when on-chain fees are high, it is still impacted by said fees. Any Lightning payment below the “dust limit” is not fully trustless. But saying that "Lightning completely ceases to work" under high fees sounds quite like an overstatement to me. Indeed, considering the current minimal fee rate of around 20 sats/vB, and the fact that the size of a transaction spending a P2WSH/P2TR output is 110 vB, it leaves us with a 2200 sats dust limit for Lightning HTLC outputs. In other words, under current conditions, you can’t buy your $0.50 beverage at the coffee machine in a completely trustless manner ; but anything above that remains trustless.

However, it is still a pretty bad time to have to close channels, since it would incur a pretty high fee and could offset any financial gains made by a routing node. Furthermore, very small channels (a few thousand sats) could end being having their whole balance consumed in fees to pay for the channel closing.

TL;DR: Lightning is an amazing tool to have when fees are this high on-chain, but it doesn’t absolve us from thinking about its limitations.

Wallets & Tools

LNBits Security Release

LNBits published a new release squashing a critical bug. Users are strongly advised to update promptly.

Blixt Update

Blixt wallet got a small new release, updating the underlying LND node to the latest version of LND and improving ease of use with things such as:

  • displaying expected Lightning fees for a payment,
  • adding the ability to use all available on-chain funds to open a channel,
  • enabling users to use a passphrase (25th seed word) when creating the wallet.

Parmanode

Parmanode is an interesting new project by Parman which aims at making it easy to run a Bitcoin and Lightning node on your everyday machine. It is designed primarily for non-technical users, who can configure the software by answering questions, and get answers to theirs through valuable resources linked into the program.

The latest version of Parmanode now includes LND on top of a Bitcoin node, an Electrum server, a BTCPay and a Mempool instances. If you’re already using Parmanode, note that this new version is not fully backward compatible with earlier versions, and that LND is only supported on Linux for now.

Nostr Wallet Connect Merged And Coming To Umbrel And Core Lightning

Remember Nostr Wallet Connect? This phenomenal protocol acts as a bridge between Nostr clients and Lightning wallets: set it up one time, and you’ll then be able to send payments (for example, Zaps) using your Lightning wallet/node, without leaving your Nostr client.

The protocol specification has been merged to the Nostr protocol standards, and the Alby team unveiled an Umbrel app to seamlessly connect one’s Umbrel node to a Nostr client through Nostr Wallet Connect (NWC). To install the app you’ll need to add Alby’s app repository to your Umbrel (see the Twitter thread for detailed instructions). Non-custodial zaps, in any Nostr client that supports NWC (such as Amethyst)!

Also, as for all the cool things, there is a Core Lightning plugin in alpha. Cool!

Spec & Implems

LSP Spec

The Lightning Service Provider (LSP) Specification working group shared their work on documents describing how channel requests and Just-in-time channel creation should be handled by LSPs and wallets, with the idea that common practices will enable interoperability between different LSPs and wallets.

The first specification document (LSPS1) details the interaction between a wallet and a LSP’s API when a user tries to buy a channel from an LSP. The LSP provides an endpoint which the wallet can query to learn what options the LSP supports (for example, if the LSP allows the client to keep no reserve on their side of the channel, or what the minimal/maximal balances can be) and then, if the available options match with what the user desires, order a channel. The LSP will respond with a quote for the requested channel, as well as an invoice (and possibly a fallback on-chain address), which the wallet can then pay.

The second document (LSPS2) explicits how “just-in-time” (JIT) channels can be opened in response to an incoming payment, when the receiver doesn’t have enough liquidity to receive the payment with their current set of channels. When the user clicks “receive” on the wallet and inputs the amount, if the wallet detects that there is not enough inbound liquidity to receive the funds, it will automatically (with or without user confirmation) query some LSPs’ APIs to get their available options (as in the first document), choose one that fits and send it a channel creation request detailing some channel parameters (such as how much the wallet will pay for the channel) and the amount of the incoming payment. The LSP will respond with a unique identifier, which the wallet will embed into an invoice, along with a routing hint that tells the payer to send its payment through the LSP’s node3. The wallet then returns this invoice to the user, who communicates it to the payer. When the payment reaches the LSP, it recognizes it as a JIT-channel request thanks to the identifier, and proceeds to open a zero-conf channel to the receiver’s wallet and forwards the payment to them.

Interoperability between wallets and LSPs has been recurring theme in Latest Strikes, with the envisioned end goal being wallets where users can seamlessly choose between many LSPs. So I’m pumped to see the specification group making some progress. Feel free to provide them with good feedback!

Liquidity Griefing For 0-conf Dual-Funded Channels

Bastien Teinturier sent an message to the Lightning-Dev mailing list detailing how not locking UTXOs involved in ongoing dual-funding channel openings could result in loss of funds when accidentally double-spending a zero-conf channel.

Indeed, the (still draft) dual-funding specification states that parties involved in the dual-funding of a channel (and thus collaboratively building a Bitcoin transaction with UTXOs from both parties as inputs) should not lock the UTXOs they want to contribute to the channel opening, as it would expose them to a griefing attack where the other participant stops responding and leaves them on hold with their locked, unusable UTXOs. However, not locking UTXOs means that several concurrent ongoing dual-funded channel openings could use the same UTXOs (at least partially), and the first to actually confirm would invalidate the other(s). This is generally an acceptable tradeoff (in contrast to exposing oneself to the aforementioned liquidity griefing attack) as dual-funded channel openings are quite infrequent, usually complete quickly, and can be costlessly retried on failure, meaning the chances of experiencing two concurrent openings competing for the same UTXO(s) are quite low, and wouldn’t be so bad should they happen.

However, bringing zero-conf channels into the equation quite changes the outcome. Indeed, as Teinturier highlights, if nodes consider a still unconfirmed dual-funded channel as usable and start transaction through it, one of the two ends of the channel might lose money should the channel be double-spent by a concurrent channel opening spending one of the same UTXOs that would confirm sooner for some reason. It could even be leveraged at scale to attack nodes that accept a lot of dual-funded zero-conf channels, such as LSPs, which are incentivized to do so to provide their customers with a good user experience.

A solution could be to use completely different funds (for example, different accounts, although it would require proper key management in a lot of places in the software) and lock funds that are intended to be used in zero-conf dual-funding attempts. But that would still expose those UTXOs to griefing attacks.

This is still an open question, and Teinturier’s email at gathering thoughts on the matter.

Closing Bit

Le neuf se nourrit du vieux
Comme un gaz qui, se détendant,
Aspire toute chaleur
Et remplit l’espace entier.

L’entropie est maîtresse de l’univers
Et l’ordre se roule en boule
Dans un coin de la pièce.

– Un géant tire à pile ou face
Le destin de ce monde.

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. By the way, this already exists with solutions such Joltz. ↩︎

  2. “Chaumian Ecash comes from the prehistory of Bitcoin, but can still play a role in a world where Bitcoin is. The idea is quite simple: users can create tokens and ask for a signature from the central server [called the “mint”], which blindly sign them. The server doesn’t know exactly what the token it just signed was, but it can check that some condition (such as a deposit for some amount) have been fulfilled before signing it. Users can then send signed tokens to each other. Upon receiving tokens from someone else, a user must ask the server to burn them and sign new tokens for the same amount. This is how double-spend is prevented.” (from Latest Strikes #2) ↩︎

  3. More precisely, the identifier is part of the routing hint, as the hop’s short_channel_id. The routing hint only tells the payer to send the payment to the LSP (identified with its public key), and that the payment will then be forwarded along a channel which short_channel_id is the aforementioned identifier. The sender doesn’t know whether this channel already exists or not, as it could be an existing unannounced Lightning channel. ↩︎