Welcome to Latest Strikes, your optimistic-weekly report of the latest Lightning-related news. In this issue, we'll cover Ark updates, Liquid <> Lightning swaps, improvements in rust-lightning, the release of a SuperScalar (aka "laddered timeout-tree structure") implementation, and more!
ArksArks
ArkadeArkade
Ark Labs announced a $5.2M raise, led by Tether, with participation from Ego Death Capital, Anchorage and others. This gives a new impulse to Arkade Assets, Ark Labs' tokens solutions, with an evident focus on stablecoins. Of course, Tether leading the round is a strong indicator, but it's not the first Bitcoin "L2" project to receive support from the stablecoin issuer[1]. Up until now, the latest "USDT on Bitcoin" launches usually involved synthetic tokens wrapping actual USDT (as in "USDT emitted by Tether") from other chains, with the promise of a 1:1 convertibility. Whether this will be the same here is an open question, to which we'll probably very soon have an answer[2].
Rebounding on the announcement, Lendasat teased that something is coming soon™ on their end, that leverages Arkade and Arkade Assets. A few days later, Lendasat also announced a raise, which involved Fulgur Ventures, Initial Capital, but also Ark Labs. Trickle down economics, if you will.
Note: I'm always a bit hesitant to cover stablecoin-related news. Stablecoins have their use and their users, not only in the insular world of DeFi, but also for actual payments. They make sense for users, both merchants and customers, who wish to transact without having to handle the short-term volatility og Bitcoin ; and hence I'm interested to see their usage in payment pools. That being said, they mechanically introduce trust assumptions, which must be clearly laid out. I'm also worried that they could facilitate the enactment of a pseudo-CBDC system.
SecondSecond
The Second team shipped a lot of quality of life improvements in v0.1.0-beta.8 of Bark, their implementation of the Ark protocol. Notably:
- the Bark server now applies a fee schedule for all sends, including Lightning payments, which varies depending on the age of the VTXO sent, reflecting the increase in liquidity cost to the ASP as a VTXO grows older ;
- Lightning overpayments are now allowed (and, of course, credited to the user) instead of failing[3] ;
- a payment's metadata now includes the preimage (if known), useful for users needing a proof of payment.
LN <> Liquid SwapsLN <> Liquid Swaps
JadeJade
Blockstream launched "Jade Lightning Payments", enabling users of the Jade hardware wallet to protect their balance accrued from Lightning payments received and swapped to Liquid with their signing device. The public key is saved on the Blockstream app, so the hardware signer is not required for receiving. Sending however, including on Lightning through another Boltz swap, requires signing the transaction with the Jade device.
Strictly speaking, this is more of a Liquid feature than a Lightning one, but if you're going to use LN <> Liquid swaps (with Blockstream App or Aqua for example), you might as well protect your funds with a hardware wallet at rest.
IbisIbis
aeon shared a sneak peek of their integration of "Lightning payments" inside Ibis wallet, using Liquid swaps. You can think of Ibis as the "Sparrow for mobile", so I find it interesting that it's dipping its toe in Lightning, since it makes more sense for a mobile wallet than for a desktop one (which Sparrow is).
LNURL-Verify in BreezLNURL-Verify in Breez
The Breez SDK now supports LNURL-Verify, which lets the consumer of a LNURL Pay link to also check with the LNURL server whether the invoice has been successfully paid or not. This is commonly used to build point of sale, such as elsirion's LNURL PoS: without the "verify" part, the merchant would have to check their wallet for every transaction. LNURL-Verify lets the PoS check for the merchant, and also provides a useful feedback to the customer.
To showcase the LNURL-Verify support, Roy from Breez built glow-pay, a standalone web-based PoS.
NWC in MostroNWC in Mostro
Version v1.2.1 of Mostro (a decentralized peer-to-peer Bitcoin trading platform) brings Nostr Wallet Connect (NWC) support, making trades even more seamless. From my experience, Mostro is sadly lacking liquidity, but it's also the hardest part to crack. With the Mostro team relentlessly improving the user experience, hopefully this mobile-first complement to Robosats catches on.
Improvements in rust-lightningImprovements in rust-lightning
TrampolineTrampoline
The rust-lightning team laid the ground for Trampoline routing last week. The Bitcoin Optech did a great job covering it. Basically, last week's commits implement the required logic for a trampoline routing node to properly claim or fail HTLCs, as well as handle trampoline claims on restart.
Dust LimitDust Limit
When using anchor outputs, the HTLC transactions (i.e. HTLC-success or HTLC-timeout) are presigned without fees, and rely on being spent with additional inputs in order to pay a reasonable fee[4]. This means that the trimming logic prevailing in legacy (i.e. non-anchor) channels, where an HTLC would be removed from the commitment transaction if it couldn't pay its fees, must be replaced. This is achieved via the dust_limit_satoshis variable negotiated when opening a channel, which indicates the minimum value that an output must carry in order to be considered economically viable and be included in the commitment transaction.
Since HTLC outputs require an additional transaction to be spent (the HTLC-success/timeout transaction), the Lightning specification was recently updated to explicitly state that the dust limit used by Lightning implementations should be higher than that of the underlying Bitcoin node (e.g. Bitcoin Core) in order to account for this extra weight. This means that Lightning implementation must be permissive enough when it comes to dust limit negotiation when opening an anchor channel, while still being restrictive enough to prevent a class of griefing attacks.
Until last week, rust-lightning lacked some permissiveness, which could lead to nodes refusing to establish channels if the counterparty requested a "big" dust limit. This was fixed by allowing a higher dust limit (up to 10,000 sats) for anchor channels, while the dust limit for legacy channels is still capped at 546 sats[5].
SuperScalarSuperScalar
This is probably the thing that caught my attention the most last week: a SuperScalar implementation!
SuperScalar is a channel factory design proposed by ZmnSCPxj, and it seems another hashling[6] going by the name 8144225309 has stepped in to release an implementation, as well as very nice website explaining the technical details around this scalability solution.
To put it in a nutshell, the goal of SuperScalar is to help scale Lightning by going from a world where every channel is a UTXO (and hence, only 2 users share one UTXO) to one where one UTXO can be the backbone of many channels (and hence, say 8 users share one UTXO). SuperScalar is designed to work with today's Bitcoin rules, leveraging N-of-N multisignature (using Musig2) and timelocks, and coordinated by a Lightning Service Provider (LSP), but could scale even better with covenants like OP_CHECKTEMPLATEVERIFY (CTV) or SIGHASH_ANYPREVOUT (APO).
SuperScalar is structured like a tree. Let's take the example of factory with 8 users:
┌──────────────────┐
│ Root │
│ 9-of-9 │
│ │
└─────────┬────────┘
│
┌─────────────────────────────────────────┴────────────────────────────────────────┐
│ │
│ │
│ │
┌────────┴─────────┐ ┌────────┴─────────┐
│ Left │ │ Right │
│ A...D + LSP │ │ E...H + LSP │
│ │ │ │
└────────┬─────────┘ └────────┬─────────┘
┌───────────────────┴─────────────────────┐ ┌────────────────────┴─────────────────────┐
┌─────────┴────────┐ ┌─────────┴────────┐ ┌────────┴─────────┐ ┌─────────┴────────┐
│ Left-Left │ │ Left-Right │ │ Right-Left │ │ Right-Right │
│ A + B + LSP │ │ C + D + LSP │ │ E + F + LSP │ │ G + H + LSP │
│ │ │ │ │ │ │ │
└────────┬─────────┘ └─────────┬────────┘ └────────┬─────────┘ └────────┬─────────┘
┌─────────┴──────────┐ ┌───────────┴─────────┐ ┌──────────┴───────────┐ ┌──────────┴──────────┐
╔═════════╧════════╗ ╔═════════╧════════╗ ╔════════╧═════════╗ ╔═════════╧════════╗ ╔═══════╧══════════╗ ╔═════════╧════════╗ ╔═══════╧══════════╗ ╔════════╧═════════╗
║ Channel A ║ ║ Channel B ║ ║ Channel C ║ ║ Channel D ║ ║ Channel E ║ ║ Channel F ║ ║ Channel G ║ ║ Channel H ║
║ A + LSP ║ ║ B + LSP ║ ║ C + LSP ║ ║ D + LSP ║ ║ E + LSP ║ ║ F + LSP ║ ║ G + LSP ║ ║ H + LSP ║
║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║ ║
╚══════════════════╝ ╚══════════════════╝ ╚══════════════════╝ ╚══════════════════╝ ╚══════════════════╝ ╚══════════════════╝ ╚══════════════════╝ ╚══════════════════╝Each node in the tree is a N-of-N multisignature output, but crucially N decreases as we go down the tree (from the root to the leaves[7]), which means that local changes do not need the signatures of all 9 members of the tree. The leaves (represented with double stroke) are actual Lightning channels (Poon-Dryja), just not backed by an on-chain UTXO, but by a Decker-Wattenhofer channel (such as "Left-Left" for example). Unlike Poon-Dryja (PD), which relies on a penalty-based mechanism to prevent misconduct, Decker-Wattenhofer (DW) uses decreasing relative timelocks on every state update to ensure that the most recent states always becomes valid first. A major limitation of DW is that it hence reduces the number of state updates: if you want one day (144 blocks) between two timelocks to ensure other parties have sufficient time to react, but don't want to block the first state update for more than 3 days (432 blocks), then you can only have 4 states and 3 state updates (s0(432) --> s1(288) --> s2(144) --> s3(0)). This is impractical for actual payment channels, but still manageable for channel factories (mother channels, if you will), where every updates opens, closes or resizes a (daughter) channel.
SuperScalar expands this number of channel updates by leveraging its tree structure to form an "odometer": every DW channel is only allowed 4 states (3 updates), but a parent DW channel only needs to transition from one state to another when one of its two child DW channels has exhausted it's 3 state updates. When this happens, the parent channel consumes one state update, but the child's counter resets. With 3 layers, the number of channel updates jumps to 64. The only downside is that updating a parent channel requires cooperation from the other child's users, and if a child DW channel updates far more frequently that its sibling, it imposes its cadence to its sibling.
This is a very nice setup: end-user channels are regular Lightning channels with an LSP, enabling them to transact easily with the rest of the network while retaining full self-custody. Channel operations (including resizing) are performed off-chain, except for the initial transaction funding the factory. Factories are short-lived (~30 days), but users have a 3-days window during which they can migrate to the next factory. A LSP can have 33 factories at the same time, with staggered lifetimes (1 factory dies and 1 factory is born each day), each serving 8 users, for a total amount of 264 users, at the cost of 1 on-chain transaction per day. This cost is diluted across the multiple off-chain channel operations that this setup enables, making it especially cost-efficient for high-usage LSPs.
There are of course many more details(Zero-UTXO onboarding, migrations(including across different LSPs), etc.), which are extensively and very clearly covered on the SuperScalar website. All things considered, this is a very interesting scheme, with very high self-custody guarantees and a nice scaling improvement factor. As far as I understand, the main drawbacks are:
- worst worst case scenario when it comes to settling on-chain, compared with classic Lightning ;
- the LSP must commit funds that will be used in the factory beforehand (including funds for splicing-in into channels).
It's very nice to have a reference implementation, and I'll certainly play around with it!
That's it for today! Thanks a lot for reading this far, and see you next week!
TaprootAssets, RGB, etc. ↩
Arkade Assets basically commit assets metadata and transactions into in Ark VTXOs (that can be committed on-chain eventually), using
OP_RETURNs. Asset balances are tracked by indexers, using the data in said VTXOs. My understanding is that users are expected to run their own private, small indexer in order to track their own balances ; while the general balance is handled by a public Arkade Indexer (especially to track balances across Ark and on-chain). To dig deeper, check the specification. ↩The Lightning specification allows a payment to send up to twice the amount requested in the invoice. The primary use case for this is to increase privacy, reducing "information leakage by altering the amount" in a "limited" amplitude. Another use case is tipping. ↩
See Bolt05. This is enabled by HTLC transactions using the
SIGHASH_SINGLE|SIGHASH_ANYONECANPAYflags, allowing them to be combined with other transactions. ↩It matches Bitcoin Core's default dust limit for P2PKH outputs. ↩
That's what I decided to call these enigmatic pseudonymous developers with barely pronounceable names. ↩
Should we say "up the tree"? ↩
https://twiiit.com/lendasat/status/2032100052227813477