Home

Rationale

Treasury management is a key component of the operational management of a lightning node. Having a lightning node with a lot of funds can become a cumbersome task when you need to operate at a scale with proper security mechanisms, however, lightning channels need liquidity from a Bitcoin treasury. In this context, a bitcoin treasury is a way of describing the source of funds required to enable the operations of a lightning service provider such as ours. We identified in this process that we would like to reduce the threat surface to the maximum extent possible, remember the mantra, not your keys, not your coins. And this is what we wanted, having a way to open lightning channels without real access to the private keys for node operators. This way, no technical members would have access to the private keys, and the lightning nodes on-chain funds in hot wallets would be the minimum as possible (this is subject to the lightning implementation you might use). In this use case, Node Operators want to sleep at night without having to worry about managing the private keys of a bitcoin treasury with a decent amount of funds. So based on the principle of least privilege (PoLP), we decided to split this responsibility by developing NodeGuard, a treasury management solution for lightning nodes. NodeGuard is a web application written in ASP.NET Core Blazor to provide an easy and intuitive UI for non-technical fellows who manage a Bitcoin treasury in lightning nodes.

Current features of NodeGuard are the following:

• Trustless funding and opening of a lightning channel through read-only(no private key access) multisig wallets
• Asynchronous approval process based on Role-based Access Control (RBAC) and multisig wallets.
• Automatic sweeping of funds in lightning nodes to avoid having funds on the node hot wallets
• Channel creation interception with returning address to multisig wallets to avoid having funds on hot wallets
• In-browser notification systems for channel approvals
• Optional remote signing through AWS Lambda functions for channel funding transactions, separating the NodeGuard keys from the actual software
• Two-factor authentication

In this context, the NodeGuard has three main different roles:

• Finance Manager: This role is for individuals who have access to the private keys of the treasury and are executive-level approvers for the channel opening requests.
• Node Managers: This role is for node operators which maintain the node such as selection of channel opening strategies, fee management, and other node-related operations
• Superadmin: This admin role is for adding new managed roles and nodes, including enforcing some security mechanisms and policies.

At a glimpse, NodeGuard relies on partially-signed bitcoin transactions (PSBTs) that contain funding UTXOs from multisig wallets where private keys are out of the reach of the NodeGuard, to allow asynchronous approvals by the Finance Managers to approve a channel opening request. All of this is accomplished through a simple and reactive UI where Finance Managers can asynchronously approve this liquidity management operation. Once the finance managers get a PSBT through NodeGuard, they would use their software wallet (No cold wallets are supported yet but read to the end!) such as Sparrow wallet and sign the PSBT, then this signed PSBT would be pasted back into NodeGuard which would open a channel as soon as the minimum amount of required signatures would be collected (n-of-m in a multisig wallet).

We are open-sourcing this software in Github so that the community benefits from this security-oriented tool for liquidity operations management. Although this software is experimental (please use it with care!), we thrive on feedback regarding our approach. At this moment, this software is only available for LND implementation, but more work in this regard is expected.

Regarding the future, the next steps are:

• Approval of channel openings with hardware wallets, we are waiting on an experimental release in the Ledger hardware wallet that would allow NodeGuard to open channels directly from a cold wallet. This is a key UX and security improvement
• New coin-selection mechanisms for Lightning channels funding transactions
• Additional support for other lightning implementations (e.g. CLK, Eclair, LDK)
• Software overall quality increase (e.g. More testing)
• UI/UX rework
• Single signature wallets for other use cases.