The Lightning Network is a second-layer protocol that tethers itself to the bitcoin base chain and allows bitcoin to be transferred via this secondary peer-to-peer network. While its primary use case is a focus on off-chain payments to allow for cheaper transactions with faster settlement times, it also provides an ecosystem for programmable applications that would not be possible on the blockchain.
One way Lightning Network wallets differ from bitcoin wallets is through their ability to authenticate, delegate and revoke permissions to the wallet. To achieve this ability to grant permissioned access to a wallet or certain subset of information Lightning Network leverages macaroons.
In this article, you will learn exactly what macaroons are, how they work, and why they are so important to the lightning network. So if you’re wondering how Macaroons fit into the lightning network and how they can help keep your transactions safe and secure, read on!
What are macaroons?
Macaroons are an update on cookies that provide an authorisation credential and were developed by the folks at Google for use in distributed systems. Like cookies, macaroons are bearer tokens assigned to a user, and that enables applications to ascertain whether their holders’ actions are authorised by the correct holder.
Macaroons are great for authorisation because they’re similar enough to cookies to be immediately usable by developers, but they include several features not present in cookies or other token-base authorisation schemes.
Macaroons are web cookies that embed caveats that attenuate and contextually confine when, where, by who, and for what purpose a target service should authorise requests. Consider a macaroon as a way to identify yourself and set specific permissions when you interact with a certain application or when an application requests certain data from you.
What do macaroons do?
A macaroon is like an authentication token that allows you to set unique permissions for different applications and services that wish to interact with you.
Features of macaroons include:
Delegation
Macaroons support delegation, which allows you to give your macaroon to another user, and they can act on your behalf with the same authority. Cookies permit delegation as well, but the remaining features of macaroons make it much safer and more practical to pass around macaroons than cookies.
Attenuation
Macaroons enable users to add caveats to the macaroon that attenuate how, when, and where it may be used so you can restrict access on a granular level. Unlike cookies, macaroons permit their holder to attenuate them before delegating. Whereas cookies and authorisation tokens enable an application to get access to all of your data and to perform actions on your behalf with your full privileges, macaroons enable you to restrict what they can do.
Proof-carrying
Macaroons are efficient because they carry their own proof of authorisation —cryptographically secured, of course. A macaroon’s caveats are constructed using chained HMAC functions, which makes it really easy to add a caveat but impossible to remove a caveat. When you attenuate a macaroon and give it to another application, there is no way to strip the caveats from the macaroon. It’s easy for the entity that created a macaroon to verify the embedded proof, but others cannot.
Third-party caveats
Macaroons allow caveats to specify predicates that third parties enforce. A macaroon with a third-party caveat will only be authorised when the third party certifies that the caveat is satisfied. This enables loosely coupled distributed systems to work together to authorise requests.
Simple verification
Macaroons eliminate complexity in the authorisation code of your application. Instead of hand-coding complex conditionals in each routine that deals with authorisation and hoping that this logic is globally consistent, you construct a general verifier for macaroons.
Decoupled authorisation logic
Macaroons separate the policy of your application (who can access what, when), from the mechanism (the code that actually upholds this policy). Because of the way the verifier is constructed, it is agnostic to the actual underlying policies it is enforcing. It simply observes the policy (in the form of an embedded proof) and certifies that the proof is correct. The policy itself is specified when macaroons are created, attenuated, and shared.
How does the Lightning Network use macaroons?
Macaroons are used extensively in the LND instance of Lightning and interact with a host of Lightning Labs products. Together with preimages obtained through Lightning Network payments, Macaroons form the basis of LSATs, which are used by Lightning Pool and Lightning Loop to authenticate users.
Types of Lightning network macaroons include:
invoice.macaroon: Grants read and write access to all invoice-related gRPC commands (like generating an address or adding an invoice). It can be used for a webshop application, for example. Paying an invoice is not possible, even if the name might suggest it. The permissionoffchainis needed to pay an invoice which is currently only granted in the admin macaroon.readonly.macaroon: Grants read-only access to all gRPC commands which could be given to a monitoring application.admin.macaroon: Grants full read and write access to all gRPC commands. This is used by thelncliclient.
Users can also “bake” custom macaroons, If they’re using the master LND, you can leverage the new gRPC method BakeMacaroon to create custom authentication macaroons with specific access features to your node.
The main disadvantage of macaroons over a cookie or user-based authentication is that they are harder to revoke, especially in distributed systems. To revoke a macaroon, the corresponding root key must be deleted, which would also invalidate all other macaroons signed with that key.
Macaroons are also hierarchical, which means once you’ve set the paramaters, and handed it over to a service, that service can subdelegate within those parameters. If an application has a read macaroon, they can pass it on or sub-delegate even granular tasks on without the permission of the original owner.
As an example, if you were using a microsystem to access read-only data for a graph, but you wanted to pull in data to this graph from another service, the graph website can ping the provider of the data to say I have read-only permissions to give me the data so I can display it to the user.
Give your macaroon a test drive.
If you do run a Lightning Network node and wish to try using your macaroon to connect to a Lightning app, you can attempt to connect your node and the corresponding Lightning wallet to a service like Zaprite. Once connected Zaprite will request your node to provide an invoice on demand when you send out payment invoices using their service.
You can also try and connect your Lightning Node to a browser wallet called Alby, which will allow you to send and receive payments, but also use your node to authenticate and login to certain services that accept LN-AUTH as a way to create an account or sign into your account.
Do your own research.
If you want to learn more about Lightning Macaroons, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research, check out their official resources below or review other articles and videos tackling the topic.
- Lightning Labs – Macaroons
- What are macaroon files in LND
- GitHub LND
- Macaroons: Cookies with Contextual Caveats for Decentralised Authorisation in the Cloud
- GitHub Macaroons
Are you a bitcoin and lightning fan?
Have you been using Lightning to make micro-payments? Stream sats or engage with apps? Which app is your favourite? Do you run a Lightning node? Have you tried all the forms of Lightning payments? Which one do you prefer?
Let us know in the comments down below.
