A focused Socratic Seminar on lightning protocol development. Topics will be selected from mailing lists, prominent github repos, network graphs, research papers, vulnerability reports and other sources.
This event will take place at TABConf in Atlanta.
As a reminder, the ground rules of BitDevs are as follow:
These rules exist so that BitDevs participants can speak freely within the event.
Dusty Daemon’s year long PR to enable channel splicing in CLN has finally been merged into master! Hopefully this means users will soon be able to resize lightning channels with no channel downtime or disruption in payment flows. Holla! 🙌
A new company called 10101 (pronounced ten-ten-one) is building DLC capability into lightning. In this three part blog series they explain what DLCs are, how they are enabled on lightning, and how they use virtual channels to accomplish this in practice.
Greenlight, a new non-custodial lightning hosting infrastructure project, has entered closed beta! Greenlight is differentiated from other cloud lightning solutions thanks to the very low resource footprint of CLN, enabling multiple front ends to share access to a node, simplified recovery, an an off-boarding flow to export your node to a different hosting provider.
In this blog post Tony Giorgio explains how Mutiny Wallet leverages the Voltage LSP to enhance the privacy of their wallet users using just-in-time lightning channels to enable a VPN-like architecture for lightning payments.
Greg Sanders, aka @theinstagibbs wrote a mailing list post with an initial proposal for a PTLC implementation. In the gist he considers many potential use cases: single-sig adaptors vs MuSig2, async updates vs sync aka “simplified updates”, amount of message re-ordering, and futuristic updates to mempool/consensus (including APO).
LND v0.17.0-beta.rc2 is a release candidate for the next major version of this popular LN node implementation. A major new experimental feature planned for this release, which could likely benefit from testing, is support for “simple taproot channels”.
LDK #2468 allows users to provide a payment_id which is encrypted in an invoice request’s metadata field. LDK checks the metadata in received invoices and will only pay if it recognizes the id and hasn’t already paid another invoice for it. This PR is part of LDK’s work toward implementing BOLT12.
The good folks at Voltage have published this well written and accessible blog post discussing Taproot Assets–how they work, how they leverage lightning’s network effects, and introduce new liquidity management requirements and business use cases for node runners.