It’s time for another round of “what’s the difference between L402 & x402”? I think of it like this… L402 is a bearer token while x402 is a process. Let’s look at the example of an agent paying for an API endpoint. L402 is an access token that includes proof of payment. An agent shows up to an API endpoint looking for some data. The service returns a bearer token with a Lightning invoice. The agent pays that invoice, receives the preimage as proof of payment and adds that preimage to the token, making an L402. The agent then returns to the server to access the data in that API endpoint presenting the L402 to get instant access. But wait, there’s more. As this is a bearer token, an agent can also attenuate that token and sell it, or pass it along to sub-agents, etc. Lots of options. No identity needed, no need for the server to hold on to user data. x402 is a process that focuses more on the broader crypto ecosystem. An agent shows up to that same API endpoint. The server responds with a 402 Payment Required. No bearer token, just payment requirements: how much, in what currency, on which network. The agent creates a payment payload (say, USDC on Base, or now Bitcoin Lightning too), and retries the exact same request with proof of payment attached. A facilitator verifies the proof and the server delivers the data. But the agent doesn't walk away with anything reusable. No token to pass to a sub-agent, no attenuation, no credential. Next time it needs that data, it pays again via the same process. L402 is a protocol that was created by Lightning Labs in 2020. x402 is a protocol that was created by Coinbase in 2025.

Look, I just really like my outfit in this photo... aren't those shoes great?! But my excuse for this bit of vanity is that I am again reminding you that @SanJuanBitdevs is tonight! And at Ralf's of course!

Tonight at Ralf's game club. As always RSVP or there won't been enough food for you!

Next week Wednesday @SanJuanBitdevs is back at Ralf's and we are discussing breaches, vaults, quantum safe Bitcoin and more. Don't forget to RSVP!

Welcome to our live show! nitter.net/i/broadcasts/1nGeLMEdE…

Welcome to our live show! nitter.net/i/broadcasts/1yKAPwOgD…

Liquid hack explained. Liquid has confidential transactions that hide the amounts for improved privacy. A bug in how these transactions are validated caused inflation of Liquid BTC (L-BTC) and allowed hackers to empty the entire side chain. Liquid nodes don't see the amounts of a confidential transaction, so to make sure that the transaction is still valid and doesn't cause inflation nodes check something called a balance proof and a range proof. The balance proof establish that sum of the input amounts equal the output amounts, i.e., that "x L-BTC going in and x L-BTC going out". But there's a catch. Only relying on a balance proof isn't enough. You also need the range proof. The range proof establishes that a hidden output amount falls within a positive range. That means a valid output must be at least 1 L-sat and at most 2^64 − 1 L-sats. Range proofs make sure that you can't mint "negative L-BTC". Why is this even necessary? Remember, the amounts are hidden and a hidden negative amount would allow extra positive outputs to balance against it. Without a range proof, a transaction could say "I've put 1 L-BTC in, and I'm taking two outputs out: one with 4000 L-BTC and one with -3999 L-BTC)." This is going to cause a disaster in a little bit. Once the balance proof, the range proof, and other validations pass, a transaction is regarded as valid and can pass consensus. However, because especially the range proof is computationally expensive, Liquid nodes cache the result of a successful range proof in memory. Essentially, the node remembers "I saw this range proof before and it was valid, all good!". In order to recognize the same range proof later on, you need to assign a label to it. This is called a cache key. This cache key is the actual cause of the bug. The way this cache key was constructed allowed two different transactions to collide on their cache key. Essentially, one valid transaction (1 L-BTC in, 1 L-BTC out) had the same cache key as an invalid transaction (1 L-BTC in, 4000 L-BTC out). Here's the hack: the attackers submitted the valid transaction (1 L-BTC in, 1 L-BTC out) first. Liquid nodes verified this transaction successfully, created a cache key called REKT and stored it in their cache. Then the attackers carefully crafted a second invalid transaction with (1 L-BTC in, 4000 L-BTC out) that created the same cache key REKT. Instead of validating the second transaction and realizing that it printed money out of thin air, Liquid nodes found it in their cache and said "hey I saw this transaction before, everything is fine" and that caused the inflation. The attackers then took their 4000 L-BTC and withdrew 4000 BTC onto the Bitcoin base chain. Note: I might have gotten some details wrong, and I'm aware that I simplified quite a bit. I wrote this post to help people understand what happened. Please feel free to correct me in the comments or add more details below.

Bitcoin Optech newsletter #421 is here: - describes an idea for pools to pay miners using silent payments in the coinbase transaction - summarizes the responsible disclosure of a denial-of-service vulnerability affecting older versions of Core Lightning - continues discussion of PQC output types - summarizes the DropKick commit/reveal PQC rescue idea - links to the SHRINCS draft BIP - examines several BIP448 and CSFS/CTV demos and applications - Optech Newsletter #421 Podcast

Welcome to our live show! nitter.net/i/broadcasts/1YGNrbBqW…

schedule of events for 26'-27' szn - sanjuanbitdevs.org

🟥 URGENT: Critical vulnerability in Core Lightning Blockstream developers urge users to shut down CLN Lightning nodes right NOW! Please let everyone know!

BTCPay Server v2.4.3 is now available! Following the release candidates published from our temporary private security repository, today we are releasing the final, fully open-source version of v2.4.3. This is another security-focused update, and we strongly recommend upgrading as soon as possible. As with v2.4.2, external access to the LND API remains restricted. This means remote integrations such as Zeus may not work with BTCPay-hosted LND nodes for now. A huge thank you to every contributor, security researcher and community member who helped review, test, and strengthen this release. The past few weeks have been intense, and this release would not have been possible without you. If you are running one of the previous release candidates, updating will automatically switch your installation to the open-source release. To update, go to Server Settings → Maintenance → Update, or run btcpay-update(.)sh from the command line after removing the parentheses.

I’m prepping to go on a bit of a Wavelength tour and planning workshops at various events! And so I’m trying to anticipate what questions builders may have. What would you like to know about how wavelength works? Is there anything that you find confusing? Do you want to know the technical details of swaps etc. or are you more focused on where you can run this & how integration works?

tonight debí tirar más fotos w @SuperTestnet

Welcome to our live show! nitter.net/i/broadcasts/1kKzDPDQp…

As always, we won't have enough beer for you if you don't tell us that you're coming. RSVP! meetup.com/san-juan-bitdevs/…

Tomorrow! @SanJuanBitdevs is back at Base Cowork this month...and there is a lot to discuss!

Running LND in production means knowing when to upgrade. The new published policy gives you that clarity. Lightning Labs maintains the two most recent release lines, and both get security fixes. A line reaches end of life when the second major release after it ships, so support tracks releases, not a calendar date. Once a line reaches end of life, it gets no further fixes. Run the latest minor of a maintained line to keep getting LND security fixes. As of today, the latest minors of maintained lines are v0.21.2 and v0.20.3. For more details: security.lightning.engineeri…

I just submitted a workshop proposal for, the last😩, @tabconf I’m proposing a ~90min Wavelength workshop, but y’all gotta help me out here. We’ll be up and running, sending eachother transactions in no time! So I’m going to have to add in a Wavelength project at the end… what should it be? I’m thinking something with an agentic payments + L402 theme. Ideas?