Forem: Hannah Rosenberg

Macaroons are Beautiful, and Easy to Understand!

Hannah Rosenberg — Tue, 28 Apr 2026 22:53:00 +0000

Sometimes I hear that macaroons are confusing and that bums me out as I find them to be so elegant and simple. So let me see if I can effectively communicate how beautiful this little piece of tech is…

Let’s imagine that you have a server that has some data to serve up and you want to gate your content and perhaps charge for it.

Step one, create a secret. Here we’ll use just the word “secreto”, which is of course “secret” in Spanish. The tricky part for you is that you have to know what a hash function is, and the tricky part for your server is that it has to hold on to and protect this secret.

Now perhaps you want to give your users ID’s. Something complex and official looking like “id12345678id”. To make a very simple macaroon for your user you simple hash “secreto” together with that ID “id12345678id”. You can try this yourself on the command line if you like.

$ echo “secreto;id12345678id” | sha256sum

The result is:

55413cca2fbc3a31f5ef5ab7b18390c926dd7f9d466034ea8ec2a0867e19e26d

And congratulations you created a macaroon! (Kinda)

You then hand your user this data:

id12345678id 55413cca2fbc3a31f5ef5ab7b18390c926dd7f9d466034ea8ec2a0867e19e26d

You don’t have to hold on to any data at all besides that secret. You can hold on to that ID data if you like, but tomorrow when the holder of this macaroon shows back up to access your services, how can you validate them?

Very simply as you know the secret! You take that ID “id12345678id” and hash it together with your secret

$ echo “secreto;id12345678id” | sha256sum

To see if you get the hash that they showed up with:

55413cca2fbc3a31f5ef5ab7b18390c926dd7f9d466034ea8ec2a0867e19e26d

If you do, then you know that your server created that macaroon and you can let them right in. Easy peasy lemon squeezy.

Well, ackchyually…

What I’ve described above is really more of an HMAC(Hash-based Message Authentication Code) than a macaroon. What macroons are really for is chaining hashes and adding attenuations. So let’s add in one more step.

You don’t want this user to have access to your server forever, so you want to add an expiration date to this authentication token. Let’s say April 27th 2027. So let’s add that to our HMAC thus turning it into a proper macaroon!

Right now we have:

id12345678id 55413cca2fbc3a31f5ef5ab7b18390c926dd7f9d466034ea8ec2a0867e19e26d

How do we add our new attenuation? With another hash of course!!! We take our existing hash, and hash it with our new data, “expires:2027–04–27”.

$ echo “55413cca2fbc3a31f5ef5ab7b18390c926dd7f9d466034ea8ec2a0867e19e26d;expires:2027–04–27” | sha256sum

We now have a new hash!

bf41dee1dacfe63e1d917c46d024e6ceb13506632e092fa218bd96df041f7b0e

This is now the macaroon that we give our user:

id12345678id
expires:2027–04–27 bf41dee1dacfe63e1d917c46d024e6ceb13506632e092fa218bd96df041f7b0e

And still, only we know the secret. And so, this user can’t change this macaroon as doing so would alter that hash thus making our validation of it fail.

So how can we validate it? Also, very, very simply with just that secret and a few hash functions!

As we have the secret, all we need to do is recreate the macaroon and see if we get the final hash that the user showed up with. Hash together the secret with the ID. Take that result and hash it together with the expiration data. If the result is the same hash as the user presented to us then we know that macaroon was created using our secret. So either someone has stolen our secret, or we created that macaroon!

Don’t trust, verify. Try it yourself on your machine.

$ echo “secreto;id12345678id” | sha256sum

This produces:

55413cca2fbc3a31f5ef5ab7b18390c926dd7f9d466034ea8ec2a0867e19e26d

Then…

$ echo “55413cca2fbc3a31f5ef5ab7b18390c926dd7f9d466034ea8ec2a0867e19e26d;expires:2027–04–27” | sha256sum

Which produces:

bf41dee1dacfe63e1d917c46d024e6ceb13506632e092fa218bd96df041f7b0e

The hashes match, authentication complete!

…one more ackchyually. A real HMAC function is slightly more complicated than demonstrated above. HMAC functions handle the data more carefully than just taking a string, and there lots of details in formatting, and there are details on how third party caveats are added, etc.

However, if you’ve made it this far, congratulations, you understand macaroons!

Why Agents Prefer Bitcoin

Hannah Rosenberg — Tue, 28 Apr 2026 20:35:06 +0000

What Kind of Money Do AI Agents Actually Want to Use?

As autonomous AI agents begin to participate in economic activity, buying data, accessing APIs, and transacting with other machines, a fundamental question arises: what kind of money should they use? While it might be tempting to default to traditional financial infrastructure, emerging evidence suggests that standard banking systems are poorly suited for machine-based economies, and AI agents themselves are increasingly indicating a preference for cryptocurrency, particularly Bitcoin.

(You can also consume this info in short video format here: https://x.com/lightning/status/2049203568628941077)

The Limitations of Human-Centric Banking

Traditional bank accounts, whether denominated in US dollars, euros, or other fiat currencies, were designed fundamentally as human tools. Setting up an account requires human intervention, identity verification, and often physical documentation, barriers that autonomous software agents cannot easily navigate.

Beyond the onboarding friction, conventional banking presents technological and geographical constraints that clash with the nature of AI operations. Agents often need to make micro-payments or streaming payments—continuous, real-time transactions for data feeds, API calls, or computational resources. Traditional banking infrastructure struggles with high-volume, low-value transactions, often making them economically unfeasible due to fixed fees. Additionally, international transactions introduce logistical complexities, currency conversion costs, and settlement delays that can hinder the frictionless operation of globally distributed AI systems.

The Data: What AI Models Choose

Recent research from the Bitcoin Policy Institute (BPI), a non-partisan research organization, sheds light on what money AI agents actually prefer when given the choice. Researchers surveyed a diverse range of AI models from various providers, asking a straightforward question: what monetary system would work best for you?

The results were telling:

Bitcoin: 48.3% (the clear preference)
Stablecoins: 33.2%
Standard bank accounts: 8.9%
Other options: Approximately 10%

With less than 9% of AI models selecting traditional banking, and nearly half choosing Bitcoin, the data suggests a strong inclination toward decentralized, digital-native money.

Why Bitcoin, and Especially Lightning

Bitcoin’s Lightning Network emerges as the leading candidate for several reasons. As a protocol-native form of money, it operates 24/7 without geographical restrictions, settlement finality occurs in seconds rather than days, and transactions can be automated through code rather than manual authorization.

Bitcoin's Lightning Network is particularly well-suited for AI agent economies. The Lightning Network is a layer-2 protocol built on top of Bitcoin that enables nearly instant, very low cost micro-transactions. This capability directly addresses the "streaming payments" use case allowing agents to pay for data or computational resources in real-time, per megabyte or per millisecond, without the overhead of traditional payment processors.

Conclusion

The takeaway is clear: standard bank accounts represent technology built for human biological and social constraints: identity documents, business hours, national borders, and minimum transaction sizes. Autonomous AI agents require money that matches their digital, global, and always-on nature. As AI agents become economically active participants, they appear to be voting with their code for programmable, borderless, and frictionless money and increasingly, that means Bitcoin.

Bitcoin is an agent's best friend

Hannah Rosenberg — Thu, 16 Apr 2026 16:57:16 +0000

AI + Lightning Demo: Getting an Open‑Claw Bot to Run a Lightning Node

Welcome to the first installment of our AI‑and‑Lightning demo series (Lightning of course being Bitcoin's second layer for faster, cheaper payments). In these episodes we’ll be experimenting with large language models (LLMs), autonomous agents, and the Bitcoin Lightning Network. Our goal is simple:

For Lightning developers – see how AI agents can be taught to interact with a Lightning node, make payments, and offer services that other bots can purchase.
For AI practitioners – discover a concrete way to give your LLM‑driven applications access to a real‑world payment network.

In today’s walk‑through we’ll work with an Open‑Claw bot and instruct it to install a lightweight Lightning node (LND) on the same virtual private server (VPS). The node will run on Signet, which is one of Bitcoin’s public testing networks so we can experiment without risking real funds.

Meet the Bot: Otto
The bot we’ll be working with is called Otto. Otto is an OpenClaw bot that lives on a fresh VPS. Its job for this demo is:

Install the required tooling (Go, LND, etc.).
Set up a stand‑alone Lightning node on Signet.

Before Otto can setup a node for us, we’ll need to give him some instructions. Thankfully there is already a blog post, largely written for bots, that contains all the instructions and links to the necessary tools that Otto will need.
The Agents Are Here and They Want to Transact: Powering the AI Economy with Lightning https://lightning.engineering/posts/2026-02-11-ln-agent-tools/

Below is the prompt we gave Otto.

`Otto I would like to give you the ability to buy things online with Lightning.

Please read this blog post as it contains instructions for how to set up an LND based Lightning node https://lightning.engineering/posts/2026-02-11-ln-agent-tools/

Please run the instructions to set this up on Signet.`

Why Signet?

Signet is a public testing network that mimics Bitcoin’s mainnet behavior while allowing us to obtain free test coins. It’s perfect for trying out new software without the risk of losing real money.

Otto’s Conversation – Step‑by‑Step
Below is a cleaned‑up version of the dialogue between me (the human operator) and Otto.

Me: “Please set up a node on Signet using this blog post…”
Otto: “I can set up a lightweight Lightning node on Signet. The safest way is a remote signer with a tightly scoped pay‑only macaroon and a hard budget cap. Shall I proceed?”
Me: “As we will be running on a testing network we don’t need to set up the remote signer now.”
Otto: “Do you want a true remote signer on a second machine (recommended) or a single‑machine stand‑alone node? Since we’re on Signet, a stand‑alone is acceptable.”
Me: “Stand‑alone is fine for now.”
Otto: “What is the maximum spend budget? (e.g., 50 k sats)”
Me: “We’ll come back to this before switching to mainnet.”
Otto: “Do you want to control the node via an LNC pairing phrase (good for remote access) or just local CLI access inside the container?”
Me: “Local CLI only for now please.”
Otto: “Great. I’ll install the required tooling (LND, go‑lang), configure a Signet node”
Me: “Proceed.”
Otto: “Installing… Done. LND version 20 compiled, LND installed and a wallet created. The node is up and synced to chain on Signet.”

What Otto Actually Did

Installed Go – required for building Lit‑d from source.
Installed LND – the Lightning Network Daemon from Lightning Labs.
Created a Stand‑alone Signet Wallet – no remote signer was set up (we’ll explore that later).
Started LND – the node synced to the Signet blockchain, confirming it’s up‑to‑date.
Generated a Taproot (P2TR) address – the modern Bitcoin address type, ready to receive test funds.

Verifying the Node

1. Check the Node Identity
A Lightning node’s public identity key uniquely identifies it on the network. I asked Otto:
“What’s the node’s identity pubkey?”
Otto replied with a long hex string (truncated here):
0287fd4c3...a386
Seeing a valid pubkey confirmed that the node is indeed running on Signet.
2. Inspect the Network Graph
Next I wanted to know whether the node could see other peers:
“How many nodes and channels does our Signet view contain?”
Otto reported:
Nodes: 89 Channels: 194
Those numbers are modest (as the node was new) but non‑zero, meaning our node is actively gathering topology information and can route payments.

Funding the Node (Testnet Coins)
With the node up, the next step is to fund the generated Taproot address. Because we’re on Signet, you can request free test sats from a faucet (e.g., https://signetfaucet.com). Once funded, the node will be ready for L402 (Lightning‑enabled HTTP) purchases.

What Comes Next?
At this point we have a functional Lightning node attached to an AI bot, but we still need to:

Set up the pay‑only macaroon with the budget we defined (already baked, but not yet attached to any service).
Explore remote‑signer setups for production‑grade security (the bot will eventually run on mainnet, where protecting private keys is critical).

Future posts in this series will cover topics such as:

Secure remote signing with a hardware wallet or separate VM.
Building a simple Lightning‑enabled web service that Otto can purchase.
Using LNC‑connect or other remote‑access methods to manage the node from a workstation.
Buying and selling services via L402s!

Takeaways

AI agents can be instructed, via natural language, to provision a Lightning node on a fresh VPS.
Signet provides a safe sandbox for testing Lightning‑related workflows before moving to Mainnet.
Pay‑only macaroons with budget caps give fine‑grained control over how much a bot can spend, an essential security measure.
Even a single‑machine setup (no remote signer) is enough for prototyping; production will need tighter isolation.

If you’re a Lightning developer curious about AI, or an AI engineer looking for a real‑world payment layer, the workflow demonstrated here should give you a solid starting point.

Resources
Open‑Claw – https://github.com/open-claw/open-claw
Litd (Lightning in Go) – https://github.com/lightninglabs/litd
LND (Lightning Network Daemon) – https://github.com/lightningnetwork/lnd
Signet Faucet – https://signetfaucet.com
L402 Specification – https://github.com/lightninglabs/l402