Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Last week brought an Eclair release, a fresh lightweight merchant tool, a new LSP and some interesting developments on the payment coordination front.
Eclair Release#
Version v0.14.0 of Eclair brought the final, spec-compliant version of splicing, as well as Taproot channels and zero-fee commitments.
This release also introduced1 an experimental peer scoring process, which basically monitors revenue and expenses on a node's channels and makes recommendations as to which channels to fund, which channels to close, and what fees to use. It is disabled by default and can be enabled in the eclair.conf file.
A series of breaking changes also joined the party, notably:
- the minimal supported version of Bitcoin Core was bumped to v30.x ;
- legacy channels (i.e. those that don't use anchor outputs or Taproot) have been discontinued. Not only can you no longer open them, but this latest version of Eclair won't even start if there are any left open. Node operators must therefore close said channels first, and only then update ;
- changes to the
auditdatabase table, in order to better serve the new peer scoring algorithm.
Experimental Bolt12 Payer Proofs In Core Lightning#
Core Lightning's second release candidate for v26.06 adds an experimental version of Bolt12 Payer Proofs (the specification itself is still a draft). Such proofs, which are messages prefixed with lnp (just like offers are prefixed with lno) enable a payer to prove they paid a specific invoice by:
- revealing the preimage,
- revealing the
invreq_payer_idfield they used when requesting the invoice (in the Bolt12 "invoice request" message), and providing a matching signature derived from this id.
This lets the payer prove that they paid a specific invoice that they requested earlier.
qpayd#
Erik Aronesty released qpayd, a self-hosted Bitcoin/Lightning payment daemon for merchants. It strikes an interesting balance between autonomy and ease-of-use through separation of concerns: the daemon itself is responsible for payment processing, invoicing, bookkeeping, data storing, etc., and it offloads the Bitcoin stuff to other services:
- a bitcoin price api,
- one or multiple Electrum server(s) for on-chain data,
- phoenixd or bark for Lightning.
Phoenixd and bark can easily be run on the same machine as qpayd, and the documentation provides setup instructions2. This lets merchants accept Bitcoin and Lightning payments in one or many stores, using Stripe-style webhooks, without having to deal with managing a Bitcoin node and an Electrum server from the get-go. They can always improve that part later on, if they see real traction.
CLINK In Zeus#
Evan Kaloudis is working on an integration of CLINK Nostr-native offers into Zeus. Proposed by Justin (shocknet), CLINK is an alternative to LNURL or Bolt12 when it comes to coordinating Lightning payments. Like in those protocols, the payee has a static payment code (noffer1...) that the payer scans or pastes. In CLINK, the communication between the payer and the payee's wallets is handled through encrypted Nostr direct messages. It hence doesn't rely on web servers, DNS entries or onion messages, but leverages the Nostr infrastructure for communication (relays) and identity (npubs). Very interesting to see a wallet with the audience that Zeus has take a leap with CLINK!
Buy HOdl and Deploy on Lightning#
Bitcoin Treasury Company BHODL launched its own spec-compliant LSP, putting some of its capital to good use. As of the writing of these lines, their node nets a total public capacity of ~1.5 BTC, unevenly spread across 10 channels.
I still don't know precisely what a Bitcoin Treasury Company is, but with BHODL joining LQwD into the deployment phase, we might be starting to see the Bitcoin-native yield narrative come closer to maturity.
Quick Strikes#
- after fetching an invoice from an offer, version v2.1.2 of the Boltz Web App now checks that the invoice's signing node matches the offer's ;
- Zeus v13.0.2 brings a new Rapid Gossip Sync (RGS) server, with graph updates every 15 minutes (instead of 3 hours), which should reduce the number of payment errors in embedded nodes due to outdated fee data3.
That's it for last week. Thank you so much for reading this far, and until next week!
https://stacker.news/items/1497442
Astute readers will remember that we covered this addition when it got initially merged to the
masterbranch of Eclair's repository. ↩︎There's also a guide on how to keep the main phoenixd credentials off the publicly exposed server, by using the secondary password (which I didn't know was a thing until now) on the machine, and running phoenixd on a separate machine with appropriate firewall rules. ↩︎
Since the sender builds the route, they're also in charge of computing the fee each hop will receive, based on the base fee and feerate they advertise. Stale gossip data can hence lead to a sender underpaying a routing node, which could then refuse to forward the payment. ↩︎
Comments2
Louferlou
···
Louferlou
···