Nostr notes by VonNaturAustreVe

The EU's New Censorship Playbook https://youtu.be/aeiwJba_Hw0 ...

2026-05-04T08:46:26+02:00

The EU's New Censorship Playbook https://youtu.be/aeiwJba_Hw0 #censorship

Excelente dica! #nevent1q…pwt0

2026-05-03T06:20:52+02:00

Excelente dica!

quoting
nevent1q…pwt0
Tem gente que faz post e o post acaba se perdendo, sendo excluído no envio ou é divulgado em um só relay. Se estiverem usando o Amethyst, adicionem em "Relays de broadcast" o relay sendit.nosflare.com, que faz a função de expalhar seus posts por vários outros relays e evitando o risco de se perderem, ou serem divulgados em poucos.

Antes

Depois

Só escrever "Sendit.nosflare.com", adicionar e salvar

Outra coisa que ajuda é: sempre que virem algum post pouco divulgado nos relays, cliquem nos 3 pontos no canto superior direito do post, e cliquem em "Transmitir".

E pra conseguir ver os relays em cada post, vá até as configurações, procure as Preferências de Interface, e coloque o Modo de Interface em "Concluído.

#nevent1q…7df8

2026-05-01T16:00:18+02:00

quoting
nevent1q…7df8
Compartilhe e receba ZAP's, mas confira se sua carteira está devidamente configurada para receber.
No vídeo de hoje, comento sobre um react que assisti recentemente envolvendo desenvolvimento de sites com Inteligência Artificial e segurança digital.

Muita gente ainda comete o erro de culpar a IA quando um projeto apresenta falhas, vulnerabilidades ou problemas de segurança. Mas será que a culpa é realmente da ferramenta?
https://youtu.be/IIgRqdcDrxI

#brasil #poiticagem #lusofonos #portugues #brasileiros #ia #libermedia

Great article! #naddr1qv…wxhh

2026-05-01T09:27:39+02:00

Great article!

quoting naddr1qv…wxhh

Private communications over public infrastructure

Today I want to write down some thoughts on what it really means to have private communications over public infrastructure, and whether such a thing is even possible at all.

This article was motivated (or should I say triggered?) by several things. Part of it comes from the current state of DMs in Nostr. Part of it comes from the privacy claims different projects make. And part of it comes from recent conversations I have had, also because I care about privacy. Privacy is crucial. We need to fight for it, and if we get it wrong and just assume things are private when they are not, things are going to get very scary.

I want to set the ground first, then look at the privacy model and tradeoffs of the main DM approaches around Nostr: NIP-04, NIP-17, Marmot, Nostr Double Ratchet, and NIP-4e.

First things first: private communications and encrypted communications are not the same thing.

Private communications usually depend on encryption to protect message content. But encryption alone is not enough to make a communication system private. You may encrypt what you say, yet still expose who you are talking to, when you are talking, how often you are talking, where you are connecting from, and how large your messages are. A third party can still learn a lot. This is metadata leakage, and in many cases, it is enough to build a revealing picture of relationships and behavior between different parties without reading a single message. Metadata is not "just data." It is actionable intelligence.

In other words: Encryption protects what you say; privacy protects that you said it at all.

That distinction matters a lot in Nostr because Nostr was never designed as a private messaging network. It was designed to be an open network built around relays. Those relays are meant to be queryable, subscribable, "dumb", and easy to use as public dissemination infrastructure. That design is powerful for openness and censorship-resistance, but it is hostile to strong privacy by default.

The next thing I want to clarify is the concept of public infrastructure. From the perspective of this article, it refers to shared, openly accessible systems or mediums, sometimes controlled by a third party, that anyone can use but that lack inherent controls to prevent interception, inspection, or eavesdropping by unauthorized parties. In this context, that includes networks, protocols, and services like relays.

Public infrastructure fights privacy at every layer, which is exactly why the distinction between encryption and privacy matters so much here.

One historic precedent makes this easier to understand. During World War II, encrypted radio traffic itself was not always immediately decryptable, but the metadata around that traffic was already useful. Timing, frequency, origin, volume, and communication patterns helped infer enemy movements, unit locations, and operational behavior. In other words, not being able to read the message did not mean the communication was private. The metadata still spoke loudly, and that lesson maps uncomfortably well to modern digital systems.

"We kill people based on metadata," stated by Michael Hayden, former director of the NSA and CIA, during a 2014 debate at Johns Hopkins University.

"Metadata absolutely tells you everything about somebody’s life. If you have enough metadata, you don’t really need content." Stewart Baker, former NSA General Counsel

That is also why I am skeptical every time I hear privacy claims built on top of public, observable infrastructure. If the substrate is public, queryable, persistently collectable, and operated by third parties, then metadata becomes part of the threat model whether we like it or not.

In Nostr, this problem becomes very concrete.

Even if a DM standard encrypts the content, an observer can still learn a lot. If the observer is a relay operator, it can see when a client connects. It can see the IP unless the user adds another protection layer such as Tor or a VPN. It can see when an event arrives. It can store traffic over time and build heuristics. An external observer with access to the relay stream may also infer a lot, depending on how much metadata the event exposes publicly.

I also think it is useful to distinguish two different kinds of observers throughout this article.

The first is an external observer. This is someone who can collect publicly visible events from relays, subscribe to public streams, and analyze what is exposed in the events themselves. An active observer could also infer the arrival time of an event even if its timestamp is randomized. This observer does not necessarily run the relay.

The second is a relay operator observer. This observer has a much stronger vantage point. They can see connection timing, source IPs unless users hide them, exact arrival timing, authentication attempts, and all the relay-local heuristics that never appear in the event itself.

That distinction matters because some protocols hide more from the external observer than from the relay operator. A scheme can look much better at the public event layer while still leaking a lot to the operator actually serving the traffic.

There is an attempt to mitigate part of this for external observers with relay auth, aka NIP-42, which allows clients to authenticate to relays. That can help a relay restrict access to sensitive events. But NIP-42 is not a privacy cure. It is a gatekeeping mechanism. In practice, it requires the client to reveal its identity to the relay in order to gain access. And for a relay to know which private events a user is allowed to fetch, those events usually need enough routing information to tie them to the relevant participants. That is useful operationally, but it comes with a clear tradeoff: access control becomes entangled with metadata exposure.

So the question I want to explore in this article is not whether Nostr can carry encrypted messages. It clearly can. The real question is whether it can support private communications over public infrastructure in a strong sense, or whether what we really get are different degrees of content secrecy with different amounts of metadata leakage.

That is the lens I want to use for the rest of this article.

NIP-04

NIP-04 was the first DM standard Nostr had. Today it is deprecated and explicitly marked as not recommended in favor of NIP-17, but it remains the cleanest example of the distinction I am trying to make.

In NIP-04, the message content is encrypted, but the event metadata is highly revealing. The event is authored by the sender’s real pubkey, although anyone could use an ephemeral pubkey. The receiver is identified in a p tag. The timestamp is visible. The event kind is visible. And the ciphertext size is visible as well.

That means the content may be hidden, but the communication pattern is not.

If you are an external observer collecting these events, you can map who is talking to whom and when. If you are a relay operator, you can usually do even better because you also see connection-level information and exact receipt timing. Even if a client tries to blur some timing details, the relay still sees when the event actually arrived.

So what does NIP-04 really give us? It gives us encrypted content, but it leaks social graph information, timing, sender identity, receiver identity, and payload size. That is already enough for strong traffic analysis. You do not need to decrypt anything to extract valuable intelligence from it.

This is not even a controversial interpretation. The specification itself warns that it leaks metadata and says it should not be used for anything that really needs to be kept secret, except perhaps in combination with authenticated relay restrictions from NIP-42.

That said, there is one thing NIP-04 does have going for it. Since sender and receiver are explicit, it works relatively naturally with relay authorization models. A relay can restrict access to the parties involved because the parties are visible in the event. But that convenience is also part of the privacy failure. The same metadata that helps a relay gate access also helps an observer understand the communication graph.

So NIP-04 is simply encrypted communication, but not private communication in any strong sense. It is the perfect example of why those two ideas must not be conflated.

NIP-17

After NIP-04, Nostr moved toward NIP-17, which uses NIP-44 encryption together with gift wraps. This was a real step forward.

The biggest improvement is that NIP-17 does a better job hiding the sender from the public outer event. The gift wrap is authored by an ephemeral key, and the actual message with the real sender is carried inside nested encrypted layers. On top of that, clients are encouraged to randomize timestamps to make simple timing correlation harder.

All of that is meaningful. I do not want to undersell it.

But I also do not want to pretend it solves the problem.

The receiver still needs a way to receive messages. In practice, that means the outer event still carries routing information for the receiver. An active observer can see that gift wraps are being delivered to some receiver-facing key. It can observe timing, volume, relay overlap, and ciphertext size. If the observer is a relay operator, it can also observe connection behavior. An external observer may not get the full picture that NIP-04 leaks publicly, and that is an important improvement, but important metadata is still available.

There is also another tradeoff that matters for the broader story. Gift wraps help obscure purpose because the same mechanism can be used for more than just DMs in Nostr. More specifically, the kind gift wraps use, 1059, is not exclusive to private chats. That is genuinely good for privacy, since not every gift wrap is obviously a chat message. An external observer seeing a kind 1059 event cannot automatically conclude that it is DM traffic. But the same design also creates a broad spam surface. An attacker can cheaply create many gift-wrap-looking events for a target receiver and force the receiver to spend resources figuring out which ones are real, or bury them under a pile of fake gift wraps. This spammy nature is also why some relays do not accept them.

I do not want to focus too much on UX in this article, but this is one of those places where privacy and usability pull in different directions. NIP-17 also gets awkward with relay authentication because the sender uses an ephemeral key, so it does not have a clean way to prove it should be allowed to fetch these events.

So I would describe NIP-17 as a meaningful improvement over NIP-04, especially in sender concealment, deniability, and reduced public visibility. But I still would not call it fully private communication. It is better encrypted communication with a more cautious metadata posture, but not a complete escape from metadata leakage.

Beyond The NIPs Umbrella

The Nostr repository itself mainly gives us NIP-04 and NIP-17, plus the new NIP-4e, which is still a PR. But there are other serious attempts to push the privacy and security model further. The two most relevant ones for this discussion are Marmot and Nostr Double Ratchet.

These two are interesting because they do not just tweak the outer format of Nostr DMs. They bring in much stronger messaging primitives. Marmot brings MLS. Double Ratchet brings the family of ideas popularized by Signal. In both cases, the cryptography becomes substantially more ambitious, giving us things like forward secrecy and post-compromise recovery, which neither NIP-04 nor NIP-17 gives us.

These terms, forward secrecy and post-compromise recovery basically mean that if a private key is compromised, an attacker should not automatically be able to read historic messages or future messages.

That matters, but it still does not let us skip the transport question.

Marmot

Marmot combines MLS with Nostr. MLS, short for Message Layer Security, is a serious group messaging protocol designed to provide strong content confidentiality, authentication, forward secrecy, and post-compromise security for groups. It also scales much better for larger groups than Double Ratchet. Those are not small properties. They are major upgrades compared with the simpler encrypted-message schemes we find in NIP-04 or NIP-17.

This is something that should be said clearly: MLS gives Marmot genuinely strong secrecy properties at the message layer.

But the problem I am exploring here is not just message secrecy. It is private communications over public infrastructure. That is where the picture becomes more complicated.

Marmot maps MLS artifacts onto Nostr events and uses relays as a dissemination layer. That means things like key packages, welcome flows, group events, and group routing all have to live within a public relay environment. The protocol tries to preserve privacy through encrypted payloads, private MLS group IDs, ephemeral outer pubkeys for group events, and other techniques. Those are meaningful design choices, and they do improve the situation.

But there is an important nuance here. The private MLS group ID and the relay-facing nostr_group_id are not the same thing. In theory that is good because the real internal MLS group identifier stays private. In practice, though, the relay-facing nostr_group_id still behaves like a stable public routing identifier. That means it is observable, it is collectable, and it is spammable in the same way gift wraps are. So even if it is not the real MLS group ID, it still creates a public handle that observers and attackers can use.

This matters even more because Marmot traffic is not especially hard to identify from the outside. If a user publishes key package events on kind 443, or on kind 30443 in the newer transition, that already signals that the user might be using Marmot. And if an observer subscribes to group messages which are kind 445 events, they can infer Marmot group traffic directly. Those event kinds are not generic cover traffic. They are much more revealing than NIP-17 gift wraps, whose kind 1059 can be used for several different purposes in Nostr.

From my perspective, I do not think its current design gets Marmot to strong privacy in the way some descriptions suggest.

The reason is simple. Marmot still operates over public relays. Even if the content is well protected, relays and active collectors can still observe that Marmot is being used. They can see when certain group identifiers become active, when bursts of traffic happen, how much data is flowing, how large the messages are, and which relays appear to be involved. An external observer can infer protocol usage from the specific Marmot kinds used and from the stable routing surface. A relay operator gets all of that plus the usual network-level vantage point, exact arrival times, and IP-level heuristics.

There is another issue: MLS is not just cryptography. It is also coordination. That burden becomes harder in Nostr because relays are a dissemination substrate, not an ordering oracle. Multiple admins can race. Offline members can come back with stale state. Welcome flows and commits need careful discipline to avoid drift.

This is not mainly a privacy problem, but it matters because every time a protocol needs more coordination over weakly ordered public infrastructure, the system inherits more complexity, more observable recovery patterns, and more room for operational fragility. As I already said, I do not want to turn this article into a UX piece. But this is exactly one of those places where the search for stronger privacy and stronger secrecy can make the total system harder to operate.

So my conclusion on Marmot is nuanced.

I think Marmot substantially improves content security and secrecy compared with simpler DM schemes. Thanks to MLS, it brings real forward secrecy and post-compromise security, and that is a serious advancement. But I do not think public Nostr relays let Marmot honestly claim strong private communications in the broader sense. Metadata observability and public collection remain very real constraints.

Nostr Double Ratchet

Nostr Double Ratchet is the closest thing in this space to bringing a Signal-like messaging primitive into Nostr instead of relying on simpler static encryption flows.

Double Ratchet gives us stronger secrecy properties thanks to forward secrecy and post-compromise recovery. Instead of deriving a static conversation secret and reusing that basic relationship forever, the ratchet evolves keys as messages are exchanged. In practical terms, that means a compromise now should not automatically reveal all past messages, and if the compromise ends, future secrecy can recover after fresh ratchet steps.

That is real progress. Just like with MLS, I think this should be acknowledged clearly rather than buried under transport criticism. If the question is message secrecy, Double Ratchet is much closer to the state of the art than NIP-04, and in an important sense it also improves on the baseline security model around ordinary NIP-17-style direct messaging.

At the same time, Nostr Double Ratchet does not get to cheat physics.

The messages still move through Nostr events and relays. And here the event kinds matter more than they may seem at first glance. In this design, the encrypted outer transport for ordinary ratcheted messages uses kind 1060. That is important because kind 1060 is not generic cover traffic. If an external observer sees repeated kind 1060 events, they can reasonably infer that this specific messaging system is in use, just like in the case of Marmot.

Not every part of the protocol is equally revealing. Invite and AppKeys records use kind 30078, which is a general application-data kind in Nostr and does not by itself prove that Double Ratchet is being used. Encrypted invite responses use kind 1059, which blends into the broader gift wrap universe. Shared-channel bootstrap also leans on kind 4. So there is some reuse of more generic Nostr surfaces. But the core ratcheted message transport still stands out.

That means the outer layer is still informative. An external observer can learn that kind 1060 traffic is happening, see the outer event pubkeys, timestamps, traffic bursts, approximate message sizes, and repeated communication rhythms. Even if they cannot read the content, they can still cluster activity, try to infer which identities or devices are active, and distinguish steady chat traffic from bootstrap traffic such as invites or device-management updates. Those flows also use protocol-specific kinds that do not blend into the general Nostr event stream.

The relay operator learns even more. It sees exact arrival times, subscription behavior, source IPs unless users hide them, and the full local timing picture that never appears in the event itself. At the same time, Double Ratchet does seem to avoid one of the more obvious metadata problems we saw in Marmot: ordinary traffic does not depend on a stable public routing identifier in the event itself.

There is also a tradeoff here around scale. Double Ratchet is naturally attractive for 1:1 communication because it gives strong secrecy with relatively clear security intuition. But it is not the most natural fit for large fanout by itself. The moment it tries to scale those guarantees into more complex group and multidevice environments, the protocol surface and complexity grows quickly. The Nostr Double Ratchet project itself includes multidevice identity mapping, session management, and sender-key-style group messaging, and that is powerful, but it also shows the cost of pushing stronger security models over a public relay substrate. The event kinds used reflect that expansion. Once a system needs separate kinds for encrypted transport, invites, device authorization records, shared-channel bootstrap, and group sender-key flows, an observer gets more protocol fingerprints to work with even if the message bodies remain sealed.

So my take is that Double Ratchet is a major upgrade in secure messaging properties, and it may improve privacy in a limited sense by making traffic less trivially interpretable. If I have to choose a protocol for 1:1 communication over Nostr relays, it would be this one. But it still does not solve the central problem of public infrastructure. The relays still know that communication happened. They still see timing. They still see patterns. And if the infrastructure remains public and observable, those patterns remain part of the attack surface.

Just a side note to finish this. Neither Marmot nor Nostr Double Ratched play well with relay auth, NIP-42.

NIP-4e

NIP-4e is a bit different from the other things I have covered so far, because it is not really trying to be a standalone DM protocol. It is better understood as an auxiliary mechanism that can be used together with schemes such as NIP-04 or NIP-17.

Its core idea is to decouple encryption from identity.

That may sound subtle, but it solves a real problem. Many Nostr patterns assume the identity key is also the key used for encryption, including self-encryption flows used for syncing data across devices. That breaks down in setups where the identity key is intentionally not present on the device, like bunkers, threshold signing systems, secure enclaves, or other more sovereign key-management architectures. NIP-4e tries to fix that by letting a user keep a separate encryption key and distribute that capability securely across devices.

From an architectural point of view, I think that is a good idea.

It improves key hygiene. It makes local encryption workflows more practical. It lets someone keep their identity signing setup more isolated while still doing encryption on-device. And it fits better with a world where people want a stronger separation between identity authority and application-level encryption.

But if we bring it back to the main question of this article, the answer stays modest.

NIP-4e does not suddenly make communications private. If you use NIP-4e together with NIP-04, you still inherit the metadata exposure of NIP-04, even if the keys used are not the real keys. If you use it with NIP-17, you inherit the strengths and weaknesses of NIP-17. What changes is not the public nature of the transport, but the keying model.

In fact, the protocol introduces its own observable artifacts through announcements and device key-sharing events. That does not make it bad. It just means it should be evaluated honestly. NIP-4e is useful infrastructure for decoupled encryption and multi-device sovereignty. It can support other DM standards. But by itself it is not a privacy breakthrough.

Conclusions

So, is private communication over public infrastructure even possible?

After going through all of these approaches, my answer is: yes, in some sense, but not really.

Public infrastructure fights privacy at every layer.

Spacially if the infrastructure is publicly reachable, queryable, and persistently collectable, then metadata becomes part of the system whether the protocol authors like it or not. That does not mean encrypted messaging over public infrastructure is useless. Far from it. It can still be extremely valuable. It can still raise the cost of surveillance. It can still make censorship harder. It can still improve user sovereignty. But if we want to be honest, we cannot collapse all of that into the word private and move on.

So I do not think the honest story is that Nostr already has private messaging. I think the honest story is that Nostr has several attempts at encrypted messaging, and those attempts sit at different points in a tradeoff space between secrecy, metadata exposure, complexity, scalability, and usability.

That is not a failure. It is just reality.

If anything, I think the most dangerous thing we can do is use imprecise language and teach users to trust guarantees the system does not actually provide. Honest language is part of security. If a protocol has strong content confidentiality but weak metadata privacy, we should say exactly that. If a system makes observation harder but still possible, we should say that too.

Nostr can absolutely be a powerful substrate for encrypted and censorship-resistant communications. I believe that. But if what we want is truly private communication, then public infrastructure is still an adversarial environment. And the more honestly we admit that, the better chance we have of building and designing systems that improve things for real instead of just sounding private.

I intentionally kept this piece focused on privacy rather than UX, even though the two constantly touch each other. But it is hard to read through these protocols without noticing that better secrecy and a better privacy posture often come with costs in complexity, spam resistance, coordination, recoverability, or general usability.

Encrypted is not the same as private. Public infrastructure is not a neutral carrier. And if we want private communications on top of public systems, we have to be far more demanding about metadata, far more honest about tradeoffs, and far more precise in the claims we make.

Official exploit https://copy.fail/

2026-04-30T00:10:07+02:00

In reply to nevent1q…86au
_________________________

Official exploit https://copy.fail/

#CopyFail (CVE-2026-31431) is a #Linux privilege escalation bug ...

2026-04-30T00:07:59+02:00

#CopyFail (CVE-2026-31431) is a #Linux privilege escalation bug that lets any local user get root using a 732-byte Python script, and it works on basically every major Linux distro shipped since 2017.

https://xint.io/blog/copy-fail-linux-distributions

#security #hacking #exploit #cve #linux

🤣

2026-04-29T12:16:43+02:00

In reply to nevent1q…4dr5
_________________________

🤣

Securing #GitHub: Wiz Research uncovers Remote Code Execution in ...

2026-04-29T10:39:37+02:00

Securing #GitHub: Wiz Research uncovers Remote Code Execution in GitHub.com and GitHub Enterprise Server (CVE-2026-3854) https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854 #github #security #bug #rce #hacking #cve

For manager disks volumes.

2026-04-28T15:34:29+02:00

In reply to nevent1q…j4la
_________________________

For manager disks volumes.

Linux LVM overview ...

2026-04-28T15:30:07+02:00

Linux LVM overview

#linux #lvm #cheatsheet #disk #sysadmin

Nice article!

2026-04-28T12:12:49+02:00

In reply to naddr1qq…re5v
_________________________

Nice article!

Good article!

2026-04-28T12:10:59+02:00

In reply to naddr1qq…d2r6
_________________________

Good article!

A LITTLE REMINDER HOW EARLY WE/YOU ARE… CAN YOU SAY, ...

2026-04-28T01:43:22+02:00

A LITTLE REMINDER HOW EARLY WE/YOU ARE… CAN YOU SAY, “WINNING!”

Nostr event nevent1qqszr2yppk9rdhujw9afzfntu7k0zv7u9eguf0ttxuewhrsy0g9j5zczyq6lsz76uwpp4qeexhay839acswnflu7262ldt3lhv6ap5jqdp2uqvmlvsc

2026-04-27T15:44:51+02:00

#meme #tech #cloud #vps

Muitos projetos open source migraram do github para ele.

2026-04-27T06:40:37+02:00

In reply to nevent1q…4dhv
_________________________

Muitos projetos open source migraram do github para ele.

Dark souls ❤#nevent1q…ykcf

2026-04-27T00:31:33+02:00

Dark souls ❤nostr:nevent1qvzqqqqqqypzpl2e38wl4hv79tmvaw9k89p2nccmxum8azv30yc7mcajafmgy0csqythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qyvhwumn8ghj7mn90p6hxtnvd93x2unwv46zuctswqhsqgy0337ms0m47ea3ltfpmxfrwmfc94xsmdhknhaje9r87a9kmra79sxcykcf

Nice workout!

2026-04-27T00:28:19+02:00

In reply to nevent1q…ttsz
_________________________

Nice workout!

Black-hat LLMs | [un]prompted 2026 ...

2026-04-26T08:17:28+02:00

Black-hat LLMs | [un]prompted 2026 https://m.youtube.com/watch?v=1sd26pWhfmg

#security #ai #hacking #llm

Não falei que era a solução, bloquear o Bitcoin não é ...

2026-04-26T07:35:44+02:00

In reply to nevent1q…5zz8
_________________________

Não falei que era a solução, bloquear o Bitcoin não é solução para nada por que o Bitcoin não é um problema, meu comentário e por que todos os anos vejo essa mesmo noticia de que a China está impedindo, bloqueando ou criminalizando o uso de bitcoin por lá.

O https://habla.news/ morreu?

2026-04-26T07:10:44+02:00

O https://habla.news/ morreu?

Já usei gogs, gitea, codeberg e gitlab. A que mais gostei delas ...

2026-04-26T06:46:28+02:00

In reply to nevent1q…r4x6
_________________________

Já usei gogs, gitea, codeberg e gitlab. A que mais gostei delas foi o codeberg. Amanhã viu testar o radicle que e uma espécie de git descentralizada.

Nostr event nevent1qqs8kepecw3kh7vwfyd355qn2fpffs93kjqye5jc0ped09vxqehyysszyq6lsz76uwpp4qeexhay839acswnflu7262ldt3lhv6ap5jqdp2uqdysx6w

2026-04-26T06:43:51+02:00

#meme #tech

Acho que essa é a vigésima vez que a China proíbe o bitcoin ...

2026-04-26T02:14:00+02:00

In reply to nevent1q…ncqk
_________________________

Acho que essa é a vigésima vez que a China proíbe o bitcoin por lá.

#nevent1q…3e29

2026-04-25T12:39:29+02:00

quoting nevent1q…3e29
Olá amigo da liberdade. Nós aqui trabalhamos no desenvolvimento e manutenção de vários projetos da rede NOSTR, mas o apoio tem sido fraco, e eu tenho mantido a grande parte do projeto. Peço que participe do projeto e seja um financiador dele, afinal de contas, o desenvolvimento depende muito de investimento. Patrocine a causa da liberdade. Na nossa página temos um link para doação e eu conto com seu apoio. Caso não possa, compartilhe com quem possa nos ajudar, os custos de fato estão altos e impedindo o crescimento e desenvolvimento.

#LiberMedia #LiberNet #Nost #Brasil #Portugal #Português

Great post!

2026-04-25T12:28:23+02:00

In reply to naddr1qq…nccx
_________________________

Great post!

Idk, tomorrow I go testing this client.

2026-04-24T21:22:37+02:00

In reply to nevent1q…v4fx
_________________________

Idk, tomorrow I go testing this client.

Welcome!

2026-04-24T21:16:05+02:00

In reply to nevent1q…8rz0
_________________________

Welcome!

I do very happy with desktop version, I missed a good desktop ...

2026-04-24T19:19:54+02:00

In reply to nevent1q…yuy9
_________________________

I do very happy with desktop version, I missed a good desktop client.

Great! Yesterday I make a build and RPM package for testing and ...

2026-04-24T19:18:10+02:00

In reply to nevent1q…yuy9
_________________________

Great! Yesterday I make a build and RPM package for testing and works well.

Como funciona o GPS: ...

2026-04-23T11:50:50+02:00

Como funciona o GPS: https://perthirtysix.com/how-the-heck-does-gps-work

#gps #tech #howto

Hahahaha Great! #nevent1q…fecp

2026-04-23T10:27:33+02:00

Hahahaha Great!

quoting
nevent1q…fecp
achei isso no reddit :)

O único realmente descentralizado de verdade e o nostr.

2026-04-23T10:24:33+02:00

In reply to nevent1q…zp8m
_________________________

O único realmente descentralizado de verdade e o nostr.

Great post! #nevent1q…cl3j

2026-04-23T05:39:04+02:00

Great post!

quoting
nevent1q…cl3j
Citrine permet d'avoir son propre relais Nostr sur son téléphone 😮
Apparemment, il permet de traquer l'activité sur ses posts et articles (engagement, likes, historique des zaps, etc.).

Vu comme je publie, ça peut être un move intéressant (et une nouvelle étape dans le monde de Nostr) pour moi 😉
naddr1qq…nccx

Pois é muito caro!

2026-04-22T16:29:39+02:00

In reply to nevent1q…t2gt
_________________________

Pois é muito caro!

Eu costumava acompanhar os posts, vejo que diminuiu quando o ...

2026-04-22T15:27:11+02:00

In reply to nevent1q…t25u
_________________________

Eu costumava acompanhar os posts, vejo que diminuiu quando o nostrudel parou de suportar comunidades, creio que muita gente usava ele diretamente.

Essa e fácil kkkkkkk #nevent1q…8pnt

2026-04-22T15:21:55+02:00

Essa e fácil kkkkkkk

quoting
nevent1q…8pnt
🤔

Interessante!

2026-04-21T17:39:54+02:00

In reply to nevent1q…5m3x
_________________________

Interessante!

Great episode! https://fountain.fm/episode/56ClmZ9bldtw3I97wPfv

2026-04-17T20:19:15+02:00

Great episode!

https://fountain.fm/episode/56ClmZ9bldtw3I97wPfv

Bitcoin Optech Newsletter #401 ...

2026-04-17T20:10:49+02:00

Bitcoin Optech Newsletter #401 https://bitcoinops.org/en/newsletters/2026/04/17/ #bitcoin #optech #newletter

Great song!

2026-04-17T00:42:57+02:00

In reply to nevent1q…tnum
_________________________

Great song!

Yes

2026-04-17T00:41:48+02:00

In reply to nevent1q…ckws
_________________________

Yes

IPv8 draft publish ...

2026-04-16T17:43:45+02:00

IPv8 draft publish https://www.ietf.org/archive/id/draft-thain-ipv8-00.html

HAHAHAHA #nevent1q…z2yd

2026-04-16T05:21:44+02:00

HAHAHAHA

quoting
nevent1q…z2yd

Six Million (Suspected) Fake Stars in GitHub: A Growing Spiral of ...

2026-04-16T04:32:56+02:00

Six Million (Suspected) Fake Stars in GitHub: A Growing Spiral of Popularity Contests, Spams, and Malware
https://arxiv.org/pdf/2412.13459 #github #spam #fake

Great show!

2026-04-15T23:20:40+02:00

In reply to nevent1q…dtxq
_________________________

Great show!

Make sense

2026-04-12T20:13:18+02:00

In reply to nevent1q…tf73
_________________________

Make sense

Nostr event nevent1qqsw8y584dfjgeudje7297qf36ulwpezv336huqc7hy42nlcmd70mqgzyq6lsz76uwpp4qeexhay839acswnflu7262ldt3lhv6ap5jqdp2uqfpjcql

2026-04-01T00:08:44+02:00

Eita dia chuvoso.

Ķkkkkkkkkkk

2026-03-20T04:47:19+01:00

In reply to nevent1q…0at7
_________________________

Ķkkkkkkkkkk

Great!

2026-03-19T20:55:14+01:00

In reply to nevent1q…qevx
_________________________

Great!

PF queues break the 4 Gbps barrier ...

2026-03-19T20:40:16+01:00

PF queues break the 4 Gbps barrier https://undeadly.org/cgi?action=article;sid=20260319125859 #openbsd #network

Kkkkkkk #nevent1q…p285

2026-02-22T12:20:04+01:00

Kkkkkkk

quoting
nevent1q…p285

Quando a piada vem pronta.

2026-02-22T12:19:35+01:00

In reply to nevent1q…3mj0
_________________________

Quando a piada vem pronta.

Nostr event nevent1qqsyrxwatg9zc9s3lhvngp0lu5epmam7gt3wt3f02dwrk5rmzssnf3qzyq6lsz76uwpp4qeexhay839acswnflu7262ldt3lhv6ap5jqdp2uq3jea2x

2026-01-18T17:26:00+01:00

DNGerousLINK https://media.ccc.de/v/39c3-dngerouslink-a-deep-dive-into-whatsapp-0-click-exploits-on-ios-and-samsung-devices #hacking #exploit #whatsapp

#nevent1q…a73f

2026-01-10T13:47:40+01:00

quoting
nevent1q…a73f
Public WiFi is not a “free” service.

https://untraceabledigitaldissident.com/public-wifi-survival-dns-vpn-containers/

IBM AI ('Bob') Downloads and Executes Malware ...

2026-01-08T20:31:28+01:00

IBM AI ('Bob') Downloads and Executes Malware https://www.promptarmor.com/resources/ibm-ai-(-bob-)-downloads-and-executes-malware

#ai #malware #security

Nostr event nevent1qqswf57de3s4qzss79ur4utyftla6ejt3gc049vtz9428mtpelyzw6qzyq6lsz76uwpp4qeexhay839acswnflu7262ldt3lhv6ap5jqdp2uqqgle9h

2026-01-07T18:54:31+01:00

#bitcoin #price

Bitcoin Core 30.1 ...

2026-01-03T06:24:07+01:00

Bitcoin Core 30.1
https://github.com/bitcoin/bitcoin/releases/tag/v30.1 #bitcoin-core #update

Nostr event nevent1qqsgrp7hajr6qvq576t5y3cj2gk3fy2nxv3dwchc6ksygnwk2vse0mqzyq6lsz76uwpp4qeexhay839acswnflu7262ldt3lhv6ap5jqdp2uqs632yw

2026-01-02T06:46:09+01:00

teste

Nostr event nevent1qqsqs8pux9v0lrtzq4w4kquhwwy2lflkfhpqvp9pyc3m4end679s5zgzyq6lsz76uwpp4qeexhay839acswnflu7262ldt3lhv6ap5jqdp2uqkgg99l

2025-12-30T18:51:59+01:00

#linux #meme

Great posto! #nevent1q…wluw

2025-12-29T04:04:11+01:00

Great posto!

quoting
nevent1q…wluw
Access Is Not Control

https://untraceabledigitaldissident.com/you-dont-own-the-internet-you-use/

Great!

2025-12-28T19:14:21+01:00

In reply to nevent1q…l4fv
_________________________

Great!

State of the post-quantum Internet in 2025 ...

2025-12-27T10:27:17+01:00

State of the post-quantum Internet in 2025 https://blog.cloudflare.com/pq-2025/ #security #postquantum #pq

https://annas-archive.li/blog/backing-up-spotify.html

2025-12-23T05:06:43+01:00

https://annas-archive.li/blog/backing-up-spotify.html

😂😂😂 #nevent1q…4fe7

2025-12-06T14:03:52+01:00

😂😂😂

quoting
nevent1q…4fe7
Looking good guys

Great work! If you not knowledgeable about bitcoin for ...

2025-12-06T13:59:42+01:00

Great work! If you not knowledgeable about bitcoin for development focus I advice this git repo.

quoting
nevent1q…exxn
Would you take a Bitcoin protocol course with the following lecture plan?

What am I missing?

https://github.com/edilmedeiros/bitcoin-course

---
**Part 1: Money, Bitcoin, and the Need for Decentralization**

1. What is Money? Why It Breaks
2. Decentralization and Its Challenges
3. Bitcoin’s High-Level Architecture

**Part 2: Cryptographic Foundations for Bitcoin**

4. Finite Fields and Modular Arithmetic
5. Elliptic Curves and secp256k1
6. Digital Signatures: ECDSA and Schnorr
7. Cryptographic Hashes

**Part 3: Understanding Bitcoin Transactions**

8. Transaction Serialization Basics (Legacy)
9. Bitcoin Script Language: Stack Semantics and p2pk
10. Bitcoin Script Contracts: p2pkh and p2sh
11. Transaction Malleability: The Problem and Motivation for SegWit
12. SegWit Transactions: p2wpkh and p2wsh
13. Advanced Script Features (Optional/Buffer)

**Part 4: Wallets — From Keys to Usability**

14. Private Keys, Public Keys, and Addresses
15. Mnemonics and BIP39
16. Hierarchical Deterministic Wallets (BIP32)
17. Wallet Architecture and Security Models

**Part 5: Mining, Proof of Work, and Settlement**

18. Proof of Work and Mining
19. Merkle Trees and Blockchain Structure
20. Chain Splits, Reorgs, and Settlement Assurance

**Part 6: Second Layers and the Future of Bitcoin**

21. Bitcoin's Security Guarantees
22. Conceptual Introduction to Lightning Network
23. Other Scaling Visions and Open Problems

Chinese DeepSeek-R1 AI Generates Insecure Code When Prompts ...

2025-12-05T10:09:42+01:00

Chinese DeepSeek-R1 AI Generates Insecure Code When Prompts Mention Tibet or Uyghurs

https://thehackernews.com/2025/11/chinese-ai-model-deepseek-r1-generates.html

#deepseek #ai #censorship #security

Adversarial Poetry as a Universal Single-Turn Jailbreak Mechanism ...

2025-11-28T15:57:32+01:00

Adversarial Poetry as a Universal Single-Turn Jailbreak Mechanism in Large Language Models
https://arxiv.org/abs/2511.15304v2

#llm #security

Great post! #nevent1q…jcsp

2025-11-28T10:12:23+01:00

Great post!

quoting
nevent1q…jcsp
Hey guys, I made a small website detailing how to install Phoenixd as a systemd service, and also added some flags that are only found in the source code. I’ll be working on a single-script installer—any feedback is welcome!

GitHub:
https://github.com/btcgdl/Mastering-phoenixd

Site:
https://btcgdl.github.io/Mastering-phoenixd/

PhoenixWallet (nprofile…g3c0) Chris Guida (nprofile…9q73)

Yeah! #nevent1q…4fnk

2025-11-28T10:05:05+01:00

Yeah!

quoting
nevent1q…4fnk
nostr wins if it stops trying to be a twitter clone and starts being the invisible layer underneath apps you actually want to use. like bitchat for location-based messaging, diVine for entertainment, whitenoise for private messaging, zap.stream for streaming, shakespeare for vibe coding, etc.

it wins by unbundling into 50 different apps that all talk to each other, rather than one giant app/corp that traps you. it's all about the ecosystem.

Baofeng UV-5R Dual Band Review ...

2025-11-28T07:35:55+01:00

Baofeng UV-5R Dual Band Review

https://www.besthamradio.com/baofeng-uv-5r/

#radio #baofeng #review

Cloudflare hides 19.3% of all websites—but not perfectly. ...

2025-11-28T07:11:58+01:00

Cloudflare hides 19.3% of all websites—but not perfectly.

CloudRip scans subdomains to find IPs not behind Cloudflare protection, exposing the real origin server:

https://hackers-arise.com/web-app-hackingtearing-back-the-cloudflare-veil-to-reveal-ips/

#security #cloudflare

RHEL 10.1 will introduce the Soft Reboot capability in 2025, ...

2025-11-28T04:21:52+01:00

RHEL 10.1 will introduce the Soft Reboot capability in 2025, finally catching up to FreeBSD, which has offered this feature since 2015—a full decade earlier.

https://thenewstack.io/rhel-10-1-soft-reboot-slashes-downtime-for-updates/

https://cgit.freebsd.org/src/commit/?id=0d3d0cc3588de0467a7e499640499f8e6725d4bb

https://cgit.freebsd.org/src/commit/?id=3f5ac575ea1288891300312b2fb9590c4c1483c4

#rhel #freebsd #softreboot

Nostr event nevent1qqsd27pfxq7u4l4q079266qne6urh82umzpfay6sfz0qm4twdxhgpcszyq6lsz76uwpp4qeexhay839acswnflu7262ldt3lhv6ap5jqdp2uqj23qnt

2025-11-27T14:42:03+01:00

@npub1teawtzxh6y02cnp9jphxm2q8u6xxfx85nguwg6ftuksgjctvavvqnsgq5u Verifying My Public Key: "@_hsmiranda"

iptv: Collection of publicly available IPTV channels from all ...

2025-11-19T08:52:09+01:00

iptv: Collection of publicly available IPTV channels from all over the world

GitHub: https://github.com/iptv-org/iptv

Channels: https://iptv-org.github.io (38,065 channel(s))

Que loucura!

2025-11-15T05:24:06+01:00

In reply to nevent1q…a7dr
_________________________

Que loucura!

WTF??? #nevent1q…p4tj

2025-11-15T05:23:52+01:00

WTF???

quoting
nevent1q…p4tj
⚡️🎙️ NEW - Wikipedia co-founder Jimmy Wales storms out of an interview after just 48 seconds when podcast host Tilo Jung asked him if he was "founder" or "co-founder."

Wales: I'm Jimmy Wales, founder of Wikipedia.

Jung: You're the founder or co-founder?

Wales: I don't care. It's the dumbest question in the world... It doesn't matter.

Jung: Isn't that like, when it comes to Wikipedia, a problem? What are the facts?

Wales: Well, it's not a fact, it's an opinion.

Jung: But for you, you're the founder...

Wales: Can I just say again, it doesn't matter. I've answered your question four times... You know what? I'm done.

Great work!

2025-11-13T04:15:18+01:00

In reply to nevent1q…0ev4
_________________________

Great work!

I agree

2025-11-13T04:13:08+01:00

In reply to nevent1q…pz00
_________________________

I agree

#nevent1q…6u4z

2025-11-13T04:11:20+01:00

quoting
nevent1q…6u4z

Claro n[e, o MB vai ser super beneficiado.

2025-11-13T04:03:45+01:00

In reply to nevent1q…q7x6
_________________________

Claro n[e, o MB vai ser super beneficiado.

Concordo!

2025-11-13T04:02:24+01:00

In reply to nevent1q…yfrf
_________________________

Concordo!

Great talk from #satsconf2025 #bitcoin ...

2025-11-08T19:14:12+01:00

Great talk from #satsconf2025 #bitcoin

https://blossom.primal.net/41e4bc0aaf344093aea4f16fd0835449f8aa4ea61c327f2474e1e17b0940f321

https://www.youtube.com/watch?v=Nv8JzygEYA0

2025-11-02T00:38:59+01:00

https://www.youtube.com/watch?v=Nv8JzygEYA0

The night sky is beautiful!

2025-10-13T03:29:29+02:00

In reply to nevent1q…g928
_________________________

The night sky is beautiful!

🫂

2025-10-13T03:28:32+02:00

In reply to nevent1q…u0s9
_________________________

🫂

Great! #nevent1q…ufmk

2025-09-30T18:10:59+02:00

Great!

quoting
nevent1q…ufmk
https://arxiv.org/abs/2509.02189

Sim pareceu muito kkkkk

2025-09-22T21:11:37+02:00

In reply to nevent1q…tl9m
_________________________

Sim pareceu muito kkkkk

Understanding Debian's security processes ...

2025-08-11T03:57:47+02:00

Understanding Debian's security processes
https://lwn.net/Articles/1030669/ #debian #linux #dev #security

QUIC for the kernel https://lwn.net/Articles/1029851/ #linux ...

2025-08-11T03:57:15+02:00

QUIC for the kernel
https://lwn.net/Articles/1029851/ #linux #kernel #quic #dev

New Method Is the Fastest Way To Find the Best Routes ...

2025-08-07T15:46:21+02:00

New Method Is the Fastest Way To Find the Best Routes https://www.quantamagazine.org/new-method-is-the-fastest-way-to-find-the-best-routes-20250806/ #dev #algorithm

bitcoin++ privacy edition | Rīga, Latvia | Day 1 Replay ...

2025-08-07T15:12:25+02:00

bitcoin++ privacy edition | Rīga, Latvia | Day 1 Replay https://x.com/i/broadcasts/1ypJdZqWvpNKW

2 main columns!

2025-08-05T16:53:31+02:00

In reply to nevent1q…0prt
_________________________

2 main columns!

Discord Attack Surface for OSINT Investigations ...

2025-08-05T16:16:43+02:00

Discord Attack Surface for OSINT Investigations

#OSINT #OPSEC #hacking #discord

Nice post!

2025-08-03T22:39:07+02:00

In reply to naddr1qq…4yh3
_________________________

Nice post!

#naddr1qv…ztm3

2025-08-03T22:38:49+02:00

quoting
naddr1qv…ztm3

As bitcoin adoption continues to increase globally, freelancers and small businesses can now leverage the Lightning Network, a layer-2 solution, to accept fast, low-cost bitcoin payments.

Unlike traditional on-chain Bitcoin transactions, which average 10 minutes and higher fees, Lightning payments settle in seconds with fees as low as $0.001. This comprehensive guide, informed by real-time data, offers small businesses and freelancers the opportunity to tap into the digital economy with confidence.

The Power of the Lightning Network

Since its debut in 2016, the Lightning Network has transformed bitcoin’s scalability, allowing seamless microtransactions for everyday purchases like coffee, freelance services, or retail goods. Its benefits include:

Ultra-Low Fees: Transaction fees cost an average of $0.001 valued at 1 satoshi (Sats), far below credit card fees, which stand at around 2 to 3%, or on-chain Bitcoin transactions. Note that opening or closing payment channels may incur additional fees—$0.10-$1—depending on network condition.

Lightning-Fast Payments: Payments are settled between milliseconds and seconds, compared to 10+ minutes with on-chain Bitcoin.

Global Accessibility: Accept payments worldwide without the delays or high costs of traditional banking, which sometimes reach 6.38% global remittance fees, according to the World Bank.

Customer Appeal: Attract tech-savvy users, improving your brand reputation in a digital-first economy.

Lightning Network adoption is fast-growing, with El Salvador’s Chivo wallet allowing millions to use Lightning for daily transactions and Strike’s partnership with NCR bringing Lightning payments to United States retail chains.

The network’s capacity has grown to 3,700 BTC—$448,938,900 at approximately $119,769/BTC, with an estimated 650M users having potential access through platforms like Cash App.

While powerful, Lightning remains in its experimental phase, so it advised for businesses should use it for smaller amounts and store larger sums in secure on-chain wallets.

Step 1: Select a Lightning-Compatible Wallet

To accept bitcoin, choose a wallet that supports the Lightning Network, available in custodial or non-custodial wallets. Top options include:

Wallet of Satoshi: available for both iOS/Android, custodial. It is user-friendly, has no channel setup, and offers a Lightning Address.

BitPay: available for both iOS/Android, non-custodial. Supports multiple digital currencies.

Electrum: available on Desktop/Mobile, non-custodial. It is secure and customizable for technical and advanced users.

Pay with Flash: available for Android, non-custodial. Designed for businesses with invoicing tools.

Blink Wallet: available for iOS/Android, custodial.

Step 2: Set Up and Fund Your Wallet

Download and Install: Download your wallet from its official source to ensure security.

Create an Account: Follow setup instructions. For non-custodial wallets like Electrum and Flash, safely store the 12-24 word recovery phrase offline to prevent loss of funds.

Fund Your Wallet: Transfer bitcoin from an exchange or another wallet to your Lightning wallet’s on-chain address, starting with “bc1” or “3.” On-chain funding is required for Lightning’s first funding. Start small with 0.001 BTC, worth between $60 and $70 at current prices, to test the system.

Set Up Payment Channels (non-custodial only): Open payment channels by selecting a node and allocating funds. This may incur on-chain fees, approximately $0.10 to $1, depending on network congestion. Custodial wallets handle this automatically.

Business Tip: Flash wallet integrates invoicing, simplifying setup for businesses.

Step 3: Create Payment Options

Generate payment methods to receive bitcoin seamlessly:

Lightning Invoice or QR Code:

Navigate to your wallet’s “Receive” section.

Specify the payment amount; for example, $30 for a service.

Create an invoice (text string) or QR code, which customers can scan for quick, error-free payments.

Share through email, text, or display in-store, like printed QR codes at a checkout counter.

Lightning Address (Wallet of Satoshi):

Receive a reusable address (lightningnews@walletofsatoshi.com) when done setting up.

Customers send payments directly, perfect for repeat clients.

Customize for branding within the app.

Step 4: Receive and Verify Payments

Customer Payment: Clients scan your QR code or enter your Lightning Address/invoice in their wallet.

Instant Settlement: Payments confirm in seconds, with notifications from wallets notifying receipt.

Verify Details: Confirm the amount and transaction details before delivering goods or services.

Channel Management (non-custodial): Ensure sufficient inbound capacity to receive payments. Rebalance or open new channels if needed, which may incur fees. Although custodial wallets handle this automatically.

Note: Lightning’s speed improves customer experience, especially for in-person payments.

Step 5: Secure and Manage Your Funds

Monitor Liquidity (non-custodial): Regularly check channel capacity to prevent transaction failures, using tools like Electrum.

Protect Your Wallet: Store non-custodial recovery phrases offline. Use strong passwords for custodial wallets.

Convert to Fiat (optional): Use exchanges to convert fiat, keeping an eye on tax obligations.

Stay Informed: Follow updates from wallet providers to leverage network improvements and maintain security.

Advantages and Key Considerations

Advantages:

Cost Efficiency: Fees are as low as $0.001 lower than credit card and on-chain Bitcoin fees, ideal for small value transactions.

Speed: Near-instant payments improve checkout speed.

Bitcoin Audience: Attract a growing user base, as seen with X’s Lightning-based tipping feature.

Global Reach: Bypass international banking fees and delays.

Considerations:

Learning Curve: Non-custodial wallets require channel management knowledge.

Price Volatility: Bitcoin’s value fluctuates; convert to fiat in real-time if needed.

Experimental Nature: Lightning may face occasional transaction failures or security risks, so use it for smaller amounts.

Tax Compliance: Track all transactions, as digital currency is taxable in most jurisdictions.

Adoption Metrics: the adoption of lightning network is fast-growing due to its speed,

Real-World Success Stories

El Salvador’s Chivo Wallet: Powers fast, nationwide Lightning transactions, serving millions.

Strike and NCR Partnership: Expands Lightning to United States. retail, allowing merchants to accept bitcoin seamlessly.

Paxful Merchants: Businesses like Lightning Koffee use Paxful’s QR codes for quick and efficient payments.

Watch El Salvador’s Lightning adoption in action:

For freelancers and small businesses, accepting bitcoin through a Lightning Wallet is a game-changer, offering low-cost, instant payments and access to a global audience.

By selecting a wallet, funding it, generating payment methods, and confirming transactions in seconds, businesses can grow in the digital economy. With fees around $0.001 and adoption increasing in regions like El Salvador and United States retail, Lightning is ideal for microtransactions.

Prioritize security, monitor bitcoin’s volatility, and stay updated on network developments.

How to factor 2048 bit RSA integers with less than a million ...

2025-08-02T21:42:06+02:00

How to factor 2048 bit RSA integers with less than a million noisy qubits https://arxiv.org/pdf/2505.15917 #rsa #quantum #cryptography #pqc #security #Benchmark

Nice post! #bitcoin #bitvm #naddr1qv…sluz

2025-08-02T00:57:41+02:00

Nice post! #bitcoin #bitvm

quoting
naddr1qv…sluz

The wait is over! The BitVM Bridge has officially launched on Mainnet.

As the first functional application based on the BitVM paradigm, Bitlayer BitVM Bridge delivers a trust-minimized bridging solution for bitcoin holders, addressing critical demands as Bitcoin DeFi scales toward maturity.

By eliminating reliance on centralized intermediaries, the bridge ensures all transactions remain verifiable, secure, and decentralized.

“Over the past year, we’ve dedicated significant resources to developing the BitVM Bridge, and we’re thrilled to finally deliver this milestone to the community,” stated Kevin He, Co-founder of Bitlayer.

“Post-Mainnet deployment, our focus shifts to scaling asset compatibility and deepening integration with additional blockchain networks.”

Progressing Toward A Trust-Minimized Bridge from Today

The BitVM paradigm has evolved through multiple iterations since its conceptualization by Robin Linus.

As a core contributor to the BitVM Alliance, we believe BitVM Bridge represents the culmination of numerous optimizations and the most future-proof solution to enable seamless interoperability between Bitcoin and other blockchain ecosystems while maintaining the highest standards of security, decentralization, and user experience.

A graph of how BitVM Bridge works

To explore BitVM Bridge workflow, check out the Technical Overview and Demonstration Cases.

Following extensive testing on Bitcoin Testnet3 and BitVMNet, the team has optimized bridge performance and infrastructure resilience, culminating in today’s Mainnet release.

Central to the BitVM Bridge is YBTC, which is a kind of token minted on the Bitlayer rollup and other supported environments when users lock their bitcoin into the BitVM smart contract.

Unlike custodial alternatives, YBTC’s security is not dependent on any single entity. Instead, it derives its integrity from the transparency and verifiability of the BitVM smart contract, which eliminates the need for trust in third-party actors.

YBTC Use Cases in DeFi

Staking: Staking YBTC and earning yield in various BTC staking protocols.

Lending and borrowing: Earn yield by supplying YBTC to lending markets or use it as collateral for loans.

Trading & earning: Swap YBTC on leading DEXs on multichains and earn fees by providing liquidity to YBTC pairs.

Strategic Ecosystem Expansion

Interest in the BitVM Bridge has surged significantly in recent months. The solution has already secured integration with leading ecosystems including Sui, Base, Starknet, Arbitrum, Sonic, Plume Network, and Sundial, dramatically enhancing Bitcoin’s liquidity across these networks.

These collaborations lay crucial groundwork for expanded multi-chain interoperability, with plans to integrate additional networks.

Getting Started with BitVM Bridge Mainnet

Developers and users can now explore the BitVM Bridge with streamlined guides:

For users: https://docs.bitlayer.org/docs/BitVMBridge/UserGuides/GetTestToken

For developers: https://docs.bitlayer.org/docs/Build/GettingStarted/QuickStart

And please visit the documentation site for more detail:
https://docs.bitlayer.org/docs/BitVMBridge/overview

What’s Next

Given that the BitVM protocol is a large-scale undertaking similar to Optimistic Rollup for Ethereum, adhering to the principle of security first and active decentralization, we will proceed with a series of tasks in an orderly manner next, such as establishing a security committee and conducting Beta community activities, audit report release, bug bounty, open source, etc.

As always, the improvements we have made over the past year have resulted from a constant collaborative effort with the BitVM Alliance, open-source contributors, and the broader research community.

As the bridge evolves, Bitlayer remains committed to advancing the vision of the ultimate Bitcoin DeFi infrastructure.

The Mainnet launch is just the beginning. Stay tuned for protocol enhancements, new partnerships, and ecosystem incentives designed to position BitVM Bridge as the cornerstone of Bitcoin’s interconnected future.

Additionally, we again want to thank all those that participated in the testing program for helping us make the best possible user experience on BitVM Bridge.

About Bitlayer

Bitlayer is pioneering the first BitVM implementation. By merging unparalleled security with a lightning-fast smart contract engine, Bitlayer unlocks the full potential of Bitcoin DeFi. Bitlayer is committed to an open and collaborative Bitcoin DeFi ecosystem, working with partners to advance BTC Bridge, Bitcoin Layer 2 and BitVM stack, driving the future of secure, scalable, and programmable Bitcoin finance.

Learn more: https://www.bitlayer.org/

Cool episode! #nevent1q…kzzy

2025-07-29T18:51:19+02:00

Cool episode!

quoting
nevent1q…kzzy
PCR122 - Kieran
https://fountain.fm/episode/SQOwcH2OkkjTPPNYGzh2

DIY Navigation System Floats This Boat ...

2025-07-29T18:40:47+02:00

DIY Navigation System Floats This Boat https://hackaday.com/2025/07/10/diy-navigation-system-floats-this-boat/

Good news :) #naddr1qv…08ah

2025-07-28T14:35:51+02:00

Good news :)

quoting
naddr1qv…08ah

Electrum, an open-source bitcoin wallet, today announced the release of Electrum 4.6.0, a landmark update introducing support for decentralized submarine swaps via Nostr, Lightning Network anchor channels, and a revamped third-party plugin ecosystem. The release marks a significant leap forward in self-custody, privacy, and interoperability within the bitcoin ecosystem.

Electrum 4.6.0 is now available on https://t.co/aHiZIZH54e. This major release adds support for anchor channels, submarine swaps over #nostr and third-party plugins. Check the release notes for the full list of changes. https://t.co/rNyItkvMLb

— Electrum (@ElectrumWallet) July 17, 2025

Key Innovations in Electrum 4.6.0

1. Nostr-Powered Submarine Swaps
Electrum now integrates Nostr (Notes and Other Stuff Transmitted by Relays) to enable decentralized, non-custodial atomic swaps. Users can discover swap providers directly through Nostr relays, eliminating reliance on centralized servers or public Lightning channels. This peer-to-peer system uses ephemeral keys for client privacy while allowing providers to advertise liquidity and fees trustlessly.

2. Anchor Channels for Lightning Network
The update makes anchor commitments the default for new Lightning channels, enhancing capital efficiency. However, this requires accessible on-chain UTXOs for sweeping operations, restricting Lightning functionality in hardware or watch-only wallets without local keys. Existing channels remain unaffected.

3. Third-Party Plugin Ecosystem
Plugins can now be installed via ZIP files on desktop binaries (Windows/macOS/Linux). A mandatory “plugin authorization password” – distinct from wallet passwords – prevents malware installations. Administrator permissions are required to set up this password, adding enterprise-grade security.

4. Privacy & Security Upgrades

Screenshot Protection: Windows users get black rectangles over Electrum windows in screenshots (inspired by Windows Recall), preventing private key leaks.

Memory Access Restrictions: Linux systems now enforce stricter process memory access controls.

Dust Attack Mitigation: New options avoid spending from used addresses to deter surveillance.

5. Desktop & Mobile Enhancements

Qt GUI migrated to Qt6 with improved transaction batching, Lightning address contacts, and wallet unlocking states.

Android overhaul: New QR scanner, notification permissions, and screen brightness controls.

CLI improvements: Better help documentation and new commands like wait_for_sync and hold_invoice management.

Developer & Infrastructure Updates

Python 3.10 Required: Drops support for Python 3.8/3.9.

New Dependencies: electrum-aionostr (forked for Nostr support) and electrum-ecc (standalone libsecp256k1 bindings).

Hardware Compatibility: Ledger “Flex” added; “HW.1” and “Nano” devices discontinued.

Build Requirements: Windows 10 (1809+), macOS 11+, and Linux glibc 2.31+.

Availability

Electrum 4.6.0 is available for download. Full release notes detail additional fixes for Lightning, hardware wallets, and cross-platform optimizations.

About Electrum
Electrum is a lightweight bitcoin wallet serving millions of users with its focus on speed, security, and simplicity. As a non-custodial open-source project, it remains a cornerstone of bitcoin’s infrastructure.

Media Contact
For interviews or technical queries, contact the Electrum team via GitHub or community forums.

Release notes: https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES