Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM
Hey Christian, You're right, if we create runes inside the HSM then we end up with the same security model. It then boils down to whether we'd rather implement Bolt 8 or rune management inside an HSM! I'd prefer Bolt 8, as I think it has more universality (and is simpler), but it could be worth experimenting with both approaches. It will also be interesting to see how we actually configure rights (access control) on the lightning node side. That really deserves some implementation work to flesh out that kind of details. Cheers, Bastien Le ven. 8 sept. 2023 à 16:51, Christian Decker a écrit : > Very interesting proposal, though as Will points out we could implement > the same using runes: have the rune be managed by the hardware wallet, and > commit the rune used to authenticate the RPC call commit to the call's > payload. That way a potentially compromised client cannot authenticate > arbitrary calls, since the hardware wallet is required to associate a rune > with it, giving it a chance for review. > > This is similar to how authentication of RPC calls works in greenlight, > where the node host is not trusted, and we need to pass the authenticated > commands forward to the signer for verification before processing any > signature request from the node. We chose to authenticate the payload > rather than the transport (which is what partonnere does) because it > removes the need for a direct connection, and adds flexibility to how we > can deliver the commands. Functionally they are very similar however. > > Cheers, > Christian > > On Thu, Sep 7, 2023, 15:06 Bastien TEINTURIER wrote: > >> Hi William, >> >> > What is wrong with runes/macaroons for validating and authenticating >> > commands? >> >> Runes/macaroons don't provide any protection if the machine you are >> issuing the RPCs from is compromised. The attacker can change the >> parameters of your RPC call and your lightning node will still gladly >> execute it. >> >> > I can't imagine validating every RPC request with a hardware >> > device and trusted display, unless you have some specific use case in >> > mind. >> >> I think that this is because you have the wrong idea of which RPCs >> this is supposed to protect. This is useful for the RPCs that actually >> involve paying something (channel open, channel close, pay invoice). >> This isn't useful for "read" RPCs (listing channels). >> >> Making an on-chain operation or paying an invoice is something that is >> infrequent enough for the vast majority of nodes that it makes sense >> to validate it manually. Also, this is fully configurable: you can >> choose which RPCs you want to protect that way and which RPCs you want >> to keep open. >> >> Thanks, >> Bastien >> >> Le mer. 6 sept. 2023 à 17:42, William Casarin a écrit : >> > >> > On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER wrote: >> > >Hey Zman, >> > > >> > >I saw the announcement about the commando plugin, and it was actually >> > >one of the reasons I wanted to write up what I had in mind, because >> > >while commando also uses a lightning connection to send commands to a >> > >lightning node, it was missing what in my opinion is the most important >> > >part: having all of Bolt 8 handled by the HSM and validating commands >> > >using a trusted display. >> > >> > What is wrong with runes/macaroons for validating and authenticating >> > commands? I can't imagine validating every RPC request with a hardware >> > device and trusted display, unless you have some specific use case in >> > mind. >> > >> > Will >> ___ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Scaling Lightning With Simple Covenants
TL;DR = * The key challenge in scaling Lightning in a trust-free manner is the creation of Lightning channels for casual users. - It appears that signature-based factories are inherently limited to creating at most tens or hundreds of Lightning channels per UTXO. - In contrast, simple covenants (including those enabled by CTV [1] or APO [2]) would allow a single UTXO to create Lightning channels for millions of casual users. * The resulting covenant-based protocols also: - support resizing channels off-chain, - use the same capital to simultaneously provide in-bound liquidity to casual users and route unrelated payments for other users, - charge casual users tunable penalties for attempting to put an old state on-chain, and - allow casual users to monitor the blockchain for just a few minutes every few months without employing a watchtower service. * As a result, adding CTV and/or APO to Bitcoin's consensus rules would go a long way toward making Lightning a widely-used means of payment. Overview Many proposed changes to the Bitcoin consensus rules, including CheckTemplateVerify (CTV) [1] and AnyPrevOut (APO) [2], would support covenants. While covenants have been shown to improve Bitcoin in a number of ways, scalability of Lightning is not typically listed as one of them. This post argues that any change (including CTV and/or APO) that enables even simple covenants greatly improves Lightning's scalability, while meeting the usability requirements of casual users. A more complete description, including figures, is given in a paper [3]. The Scalability Problem === If Bitcoin and Lightning are to become widely-used, they will have to be adopted by casual users who want to send and receive bitcoin, but who do not want to go to any effort in order to provide the infrastructure for making payments. Instead, it's reasonable to expect that the Lightning infrastructure will be provided by dedicated users who are far less numerous than the casual users. In fact, there are likely to be tens-of-thousands to millions of casual users per dedicated user. This difference in numbers implies that the key challenge in scaling Bitcoin and Lightning is providing bitcoin and Lightning to casual users. As a result, the rest of this post will focus on this challenge. Known Lightning protocols allow casual users to perform Lightning payments without: * maintaining high-availability, * performing actions at specific times in the future, or * having to trust a third-party (such as a watchtower service) [5][6]. In addition, they support tunable penalties for casual users who attempt to put an old channel state on-chain (for example, due to a crash that causes a loss of state). As a result, these protocols meet casual users' needs and could become widely-used for payments if they were sufficiently scalable. The Lightning Network lets users send and receive bitcoin off-chain in a trust-free manner [4]. Furthermore, there are Lightning protocols that allow Lightning channels to be resized off-chain [7]. Therefore, making Lightning payments and resizing Lightning channels are highly scalable operations. However, providing Lightning channels to casual users is not scalable. In particular, no known protocol that uses the current Bitcoin consensus rules allows a large number (e.g., tens-of-thousands to millions) of Lightning channels, each co-owned by a casual user, to be created from a single on-chain unspent transaction output (UTXO). As a result, being able to create (and close) casual users' Lightning channels remains the key bottleneck in scaling Lightning. Casual Users And Signatures === Unfortunately, there are good reasons to believe this bottleneck is unavoidable given the current Bitcoin consensus rules. The problem is that in order for a casual user to co-own a Lightning channel, they must co-own an on-chain UTXO [8]. Therefore, if a large number of casual users are to each co-own a Lightning channel, all of which are funded by a single UTXO, that UTXO must require signatures from all of those casual users. In practice, the problem is much harder than just getting signatures from a large number of casual users, as the signatures themselves depend on the exact set of casual users whose signatures are required. For example, if a UTXO requires signatures from a set of 1,000 casual users and if 999 of them sign but one does not, the 999 signatures that were obtained can't be used. Instead, one has to start all over again, say with a new UTXO that requires signatures from the 999 users that signed the previous time. However, if not all of those 999 sign, the signatures that were obtained in the second try are also unusable. The requirement for casual users to sign transactions that specify the exact set of casual users whose signatures are required creates a very difficult group coordination problem that's not
Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM
Very interesting proposal, though as Will points out we could implement the same using runes: have the rune be managed by the hardware wallet, and commit the rune used to authenticate the RPC call commit to the call's payload. That way a potentially compromised client cannot authenticate arbitrary calls, since the hardware wallet is required to associate a rune with it, giving it a chance for review. This is similar to how authentication of RPC calls works in greenlight, where the node host is not trusted, and we need to pass the authenticated commands forward to the signer for verification before processing any signature request from the node. We chose to authenticate the payload rather than the transport (which is what partonnere does) because it removes the need for a direct connection, and adds flexibility to how we can deliver the commands. Functionally they are very similar however. Cheers, Christian On Thu, Sep 7, 2023, 15:06 Bastien TEINTURIER wrote: > Hi William, > > > What is wrong with runes/macaroons for validating and authenticating > > commands? > > Runes/macaroons don't provide any protection if the machine you are > issuing the RPCs from is compromised. The attacker can change the > parameters of your RPC call and your lightning node will still gladly > execute it. > > > I can't imagine validating every RPC request with a hardware > > device and trusted display, unless you have some specific use case in > > mind. > > I think that this is because you have the wrong idea of which RPCs > this is supposed to protect. This is useful for the RPCs that actually > involve paying something (channel open, channel close, pay invoice). > This isn't useful for "read" RPCs (listing channels). > > Making an on-chain operation or paying an invoice is something that is > infrequent enough for the vast majority of nodes that it makes sense > to validate it manually. Also, this is fully configurable: you can > choose which RPCs you want to protect that way and which RPCs you want > to keep open. > > Thanks, > Bastien > > Le mer. 6 sept. 2023 à 17:42, William Casarin a écrit : > > > > On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER wrote: > > >Hey Zman, > > > > > >I saw the announcement about the commando plugin, and it was actually > > >one of the reasons I wanted to write up what I had in mind, because > > >while commando also uses a lightning connection to send commands to a > > >lightning node, it was missing what in my opinion is the most important > > >part: having all of Bolt 8 handled by the HSM and validating commands > > >using a trusted display. > > > > What is wrong with runes/macaroons for validating and authenticating > > commands? I can't imagine validating every RPC request with a hardware > > device and trusted display, unless you have some specific use case in > > mind. > > > > Will > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
