Lightning This Week #659,409
Lightning This Week #659,409
Looping automation, new C-Lightning v0.9.2 release and a proposal for Bitcoin vaults
Hello and welcome to LTW! I don’t like intros — next!
Automating The Loops
Maintaining healthy balances across the many channels in a Lightning node is one of the most important tasks as an operator. Poorly-managed channels will lead to routing and payment failures, which are likely to impact how peer nodes’ routing algorithms see your node — less favorable to forward HTLCs through. While there are a handful of ways to balance one’s own Lightning channels, Submarine Swaps have quickly become an industry standard.
Submarine Swaps are atomic on-chain (Bitcoin blockchain) to off-chain (Bitcoin Lightning Network) swaps. Or vice versa, often called Reverse Submarine Swaps.
Initial implementations were made by Alex Bosworth, and the name was originally coined by Olaoluwa Osuntokun — one half is above water (on-chain), one half is below water (off-chain).
Loop is Lightning Labs’ product for providing Submarine Swaps for any node operator. Loop In and Loop Out provide both the chain-to-offchain and offchain-to-chain interfaces necessary. This means a node operator can rely on Lightning Loop to easily move funds from onchain to a ‘depleted’ Lightning channel, or from a ‘full’ Lightning channel to an onchain address.
While Loop/Submarine Swaps provided much needed functionality to operators, much of the process was still done manually. And if not, scripts to automate these procedures (if-this-then-that scenarios) would be built internally to the companies/teams. This week Lightning Labs announced Autoloop, which automates the entire process of making Loop Ins and Loop Outs.
“[Autoloop is] a new feature in Lightning Loop that allows Loop users to automatically balance liquidity, saving time and making using bitcoin on Lightning more efficient.”
With Autoloop, an operator simply has to set the % of inbound and outbound capacity they want in a specific channel (aka how they’d like to balance liquidity in the channel), and specify fee limitations — the rest is taken care by Autoloop. Every so often, Autoloop will check each channel in your node against the criteria set for it and if there are incorrect balancing scores, it will automatically initiate Loop Outs.
Yet another strong release from the Lightning Labs team!
NOTE: Autoloop only has Loop Out support right now. Loop In coming soon.
For those interested in learning more about upcoming features of Autoloop, please refer to issue #319. For full press release post can be found here.
C-Lightning v0.9.2 - Now with 0-of-N Multisig
This week we saw the C-Lightning team post a new release of their node implementation. This is a significant release with new CLI-level notifications, better channel state reporting, and stable plugin-hook call ordering. In lieu of re-writing what the team has already put on their CHANGELOG, I’ve simply decided to highlight a few points I found interesting.
Why did my channel close?
C-Lightning now keeps track of channel closure rationales. Wonder "why did my channel close" no more. All channel state changes are now listed in listpeers's state_changes.
Can I change the fee-rate for each commitment transaction?
New optional argument commitment_feerate on the multifundchannel command — useful for setting one feerate for the funding transaction and another for the channel commitment transactions.
Can I order the sequence of my plugins?
Plugin hook call-ordering is now real. Hooks can now specify that they must be called 'before' or 'after' other plugins.
Tired of not getting any updates?
With notifications, the close command will publish notifications (think CLI status updates) for slow closes. Must have allow-deprecated-apis set to false for these to work.
Read more on CHANGELOG and RELEASE.
NOTE: This release c-lightning-generated PSBTs are only considered valid by bitcoind v0.20.1 and above.
New Bitcoin Vaults
This week we also saw the announcement of Revault, a project by Kevin Loaec and Antoine Poinsot that aims to implement a new mechanism for creating Bitcoin vaults. The general idea is to build a multi-layered process using time-locks and different spending policies to dramatically reduce the possibility for complete steal of funds.
The secure storage and transaction of funds is a big challenge to Bitcoin users and especially to companies managing a substantial amount of bitcoins. The censorship resistance and lack of identity features of Bitcoin make it hard to setup a traditional control of expenses.
We propose a self-managed custody architecture for multi-party holders (such as a company or their third party custodian) aiming to dis-incentivize theft while limiting the impact on the practical movements of funds. A multi-layer access process is enforced wherein parameters (e.g. the length of time-locks value or the spending policy) of the system can be customized depending on the use-case and the needs of each user.
It’s always exciting to see releases like this that continue to innovate and improve on a user’s experience while self-custodying Bitcoin. Important to note that in the release a few technologies are highlighted as the reason why the project is feasible right now, specifically Miniscript, Bitcoin Core’s native descriptor wallet, and of course PSBTs.
Things I Would Share This Week
Bitcoin just reached a new price All Time High — Or did it?
A Better Kubernetes from the Ground Up — If you’re a engineer/user of K8s, this was a really interesting read.
DeepMind’s AI makes gigantic leap in solving protein structures — Fascinating work from Google’s deep-learning program for determining the 3D shapes of proteins.
That's all for Lightning This Week. See you all in ~1,000 blocks.