For the ones that like art and Bitcoin this is a pretty awesome monument to Satoshi in Buenos Aires 🇦🇷 It represent the genesis block and inside is going to be Satoshi, the unveiling is next thursday, if you are in Buenos Aires don't miss it.

Yesterday I opened two sell orders on different Mostro nodes, one on the global node and another on MostrAR, the Argentinian node run by @npub1rujd...9u68 Nobody took my order on the global node, but the one on La Crypta was taken pretty quickly. The app notified me that my order had been taken on La Crypta even though I was on the global node. This is extremely useful for anyone who needs to trade regularly. We should start testing which nodes have the most liquidity in different currencies without risking missing a trade when someone takes our order. Since I had no reputation on La Crypta's node, I imported my reputation from @npub1lnp2...yurp @Mostro you're a Monster! 🧌

Found the genesis block in Buenos Aires 🇦🇷

1/ Tomorrow it's been a month since we shut down @lnp2pBot. I finished the forensics and I don't love what I found. The bug they used wasn't in our code. It was in a dependency. And the fix had been out for 3 days already. 2/ The library is `invoices`, the BOLT11 parser half the Lightning JS ecosystem depends on. If a payment request had the payment hash twice, the parser kept the last one. The node uses the first one. Same string, two parts of the same system, two different IDs. 3/ In plain terms: the attacker sent us an invoice our bot and our node read differently, and got paid twice for the same thing. The bot was tracking one payment. The node had settled another. Every round they ran, we ate the difference. 4/ That line had been there for 2,381 days. It went in with the very first commit of the repo, back in January 2020. There was never a version of the library without it. 5/ It got fixed on August 7, and it was pushed down to `lightning` and `ln-service` the same day. I want to say that up front, because it's true and it matters: the fix itself was fast and handled well. 6/ What went wrong was the announcement. Here is the entire changelog entry for that release: "Breaking Changes , Node.js version 22 or higher is now required" Not a word about the payment hash. No advisory. No CVE. 7/ Now put yourself downstream. A major version lands and it wants you to go from Node 20 to Node 22. You read that as chores. You put it on the list for when things calm down. The only signal you had was pushing you to wait. 8/ This is the part I want to change, and it isn't about one person: a security fix can't ride along inside a breaking infra change. It has to say so out loud. An advisory, a line in the changelog, a ping to the people who depend on you. 9/ Without that, reading changelogs doesn't save you. We had no way to know we were supposed to run. We found out 3 days late, with the bot already closed and the losses on us. 10/ What we're building on Mostro now: event-driven watching on the dependencies that matter. New version drops, an agent diffs it right then, and answers one question, does this quietly fix something security related? Against a 3 day window, a weekly check has already lost. 11/ A month later I'm still going through it. Full story at @LaBitconf

GitHub

use first payment hash and require node v22 · alexbosworth/invoices@b30a012

Library for parsing Lightning Network BOLT11 payment requests and encoding invoices into requests - use first payment hash and require node v22 · ...

Seven years ago, I shared an open-source BJJ scoreboard I had built for my academy. The original version was simple: display the scoreboard on a large screen and control it from a phone or tablet connected to the same Wi-Fi network. After years of wanting to revisit the idea, I finally rebuilt it from scratch. It is now called **Choke**: a modern, open-source and Nostr-native scoring system for Brazilian Jiu-Jitsu. * Score matches from your phone * Configure the match timer and sounds * Track points, advantages and penalties * Publish match events in real time through Nostr * No accounts and no centralized platform required Because match events are published through Nostr, the data is not locked inside Choke. Other developers can build public scoreboards, dashboards, statistics tools or tournament applications that consume the same events. The attached video shows the current scoring flow. Choke is still under active development, and feedback from referees, coaches, competitors and tournament organizers would be extremely valuable. What would Choke need before you would use it at your academy or event? Source code: Choke app:

GitHub

GitHub - protolayer-io/choke: A modern decentralized BJJ match scoring and publishing app via Nostr.

A modern decentralized BJJ match scoring and publishing app via Nostr. - protolayer-io/choke

Scoreboard:

GitHub

GitHub - protolayer-io/choke-scoreboard

Contribute to protolayer-io/choke-scoreboard development by creating an account on GitHub.

Original 2019 project:

GitHub

GitHub - grunch/BJJ-Scoreboard: A websockets Brazilian Jiu-Jitsu scoreboard and chronometer

A websockets Brazilian Jiu-Jitsu scoreboard and chronometer - grunch/BJJ-Scoreboard

#BJJ #BrazilianJiuJitsu #Nostr #OpenSource

Argentina ♥️

I made this World Cup 2026 Simulator. It predicts match results from the round of 32 onward using: 1. FIFA ranking: official points (FIFA Elo system, denominator 600). 2. Squad value: Transfermarkt, in millions of EUR. 3. 2026 group performance: points and goal difference. 4. World Cup honours: titles, best historical finish, appearances. It's open source, so if you're curious, feel free to check it out, here an image of one prediction made with the simulator. Penalty shootouts are decided by coin flip, so those outcomes are random and the results aren't always the same.

GitHub

GitHub - grunch/sim-mundial-2026

Contribute to grunch/sim-mundial-2026 development by creating an account on GitHub.

Today #github suspended the account of Mostronator, my #OpenClaw agent. Even those you least expect can resist change and take absurd measures. In just 11 days, Mostronator efficiently contributed to the @Mostro and @lnp2pBot projects — a highly efficient human would need at least 3 months to deliver that level of contribution. It also started two of its own projects, which are very valuable to the Mostro organization. We’re going to have to build a new GitHub on Nostr — and powered by AI, so it stings even more.

Mostro skill 🧌

Mostro and other freedom tech tools are our pacific revolution against injustice, come and join us 🧌 View quoted note →

Today AI writes the code for apps; tomorrow we won't need code. Apps will continue to exist as a facade, but they won't have any written code. Every user action will be answered by an AI agent that will coordinate sub-agents to perform the actions the user requires.

Primal is a nostr service, nostr goal is to fight censorship by removing the single point of failure, but primal is working exclusively as a SINGLE POINT OF FAILURE, I have days trying to use it from Argentina and it doesn't work, it's also impossible to connect directly to the relays I want because everything pases through a cache service which is the SPF This is not how nostr should be use it, if you want to add a SPF feature make it optional but not the only one, otherwise primal can be easily censored on authoritarian regimes

Right now there are 749 p2p Orders that are implementing NIP-69 🤩

Africa Bitcoin Conference starting now 🧡🇲🇺

Luego de 4 años vuelvo a El Salvador 🇸🇻 En tan solo dos días estaré en Adopting Bitcoin! 😃 ⚡ #AdoptingBitcoin2025

Almost a year ago, I proposed a Nostr NIP to create a large liquidity pool for Bitcoin P2P orders on Nostr. The idea is to have a standard (or an attempt at one) that, as more platforms implement it, allows end users to have a single place to search for the order that best suits them and, from there, navigate to the platform where the chosen order is located. So far, this standard has been implemented by @npub1lnp2...yurp , @Mostro and @Robosats A couple of months ago, @KoalaSat created this very useful P2P dashboard where we can see all the orders that meet this standard.

P2P ₿AND

P2P Bitcoin exchanges decentralized aggregator

I believe the more P2P orders published here, the greater the benefit for users and the platforms themselves, as end users are directed to the option that best fits their needs. For curious minds here the NIP

GitHub

nips/69.md at master · nostr-protocol/nips

Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.

On my way to Oslo Freedom Forum 2025 #off @HRF

We constantly complain that politics is dirty, and no one wants to get involved because they would end up being part of that swamp. Politics isn't dirty, but politicians are. We should start working on ELIMINATING politicians from politics. How do we eliminate them? By creating tools so that citizens can exercise politics securely, privately, and secretly. I've been working on a system to give people the real ability to actively participate in the decisions that affect their lives and communities. For these types of tools to be truly useful, they have to be open source, but that's not enough. They must be auditable at runtime. This can be done with cryptography techniques and using #Nostr as a data transport layer. For all of the above, I've been working on #Criptocracia, a simple tool that will allow citizens to vote securely, privately, and secretly. Criptocracia is a proof of concept that we will continue to test, adjust, and improve. Contributions and feedback are very welcome 🥲 More info 👇

GitHub

GitHub - Parallelia/criptocracia: Criptocracia is an experimental, trustless open-source electronic voting system built in Rust. It leverages blind RSA signatures to ensure vote secrecy, voter anonymity and integrity, and uses the Nostr protocol for decentralized, encrypted message transport

Criptocracia is an experimental, trustless open-source electronic voting system built in Rust. It leverages blind RSA signatures to ensure vote sec...

The coolest receipt ever after buying in @npub1rujd...9u68

After many discussions and a lot of trial and error, we finally have a simple and efficient way to allow an admin to intervene in dispute resolution. I just uploaded a repository explaining how Mostro clients handle chat between users. We use a Diffie-Hellman shared key between the two parties as a master key, which either party can voluntarily share with the solver in case of a dispute. This way, the solver can verify who is lying. For the curious, the repository technically explains how it works and includes sample code. I’m currently implementing it in mostro-cli, and I hope to add it to Mostro’s official documentation today. @Mostro client builders can now implement user chat without worrying about changes—this will be the scheme we’ll stick to.

GitHub

GitHub - grunch/mostro-mediator: Mostro P2P dispute mediator (proof of concept)

Mostro P2P dispute mediator (proof of concept). Contribute to grunch/mostro-mediator development by creating an account on GitHub.