aiiixiii

bitcoin

BIP-110

But are u okay with the current Bitcoin Core situation and were things are headed with that?

Trying to make up my mind in regard to BIP-110.  
My question for Bitcoin node runners:  
Will you signal/activate BIP-110 and why ?  
 (answer in comments)

Before doing a deep dive, I naively thought Monero was more quantum-resistant than Bitcoin. 
After all, it is a privacy coin with advanced cryptography designed to obscure transactions, while Bitcoin is a transparent, public ledger with standard elliptic curve signatures. 
A closer examination reveals a counterintuitive truth: 
**Monero is structurally more vulnerable to quantum computing than Bitcoin**

## Public Key Exposure

Bitcoin uses ECDSA for signatures. Crucially, public keys are only revealed when a UTXO is spent. This means unspent outputs remain protected even if a quantum computer capable of breaking ECDSA emerges. Users can proactively migrate coins to new addresses before quantum attacks are feasible.

Monero, by contrast, relies on EdDSA (Ed25519) signatures, ring signatures, stealth addresses, and confidential transactions. Public keys, both real and decoy, are revealed on-chain in every transaction. Once discrete logarithms can be efficiently solved by quantum computers, all past outputs could be deanonymized retroactively, breaking the privacy Monero depends on.

## Retroactive Privacy Compromise

Bitcoin’s worst-case scenario under quantum attack is the theft of funds from exposed addresses. Historical transactions remain pseudonymous because unspent outputs’ public keys were never revealed.

Monero faces a different problem: quantum attacks could unmask the true signer in past ring signatures, exposing not only the sender and receiver but potentially the entire transaction graph. Privacy is compromised retroactively, a scenario with far more severe consequences than theft alone.

## Transaction Structure Complexity and Upgrade Challenges

Bitcoin’s transaction model is relatively simple: one signature per input in the UTXO model. Upgrading to a quantum-resistant signature scheme is straightforward and can be rolled out incrementally via soft forks.

Monero’s cryptography is far more complex. Ring signatures, stealth addresses, and confidential transactions are interdependent. Replacing the underlying signature scheme would require migrating all past and future outputs carefully; any failure could compromise privacy across the network. This makes Monero’s upgrade path inherently more difficult and error-prone and surely requires an hard fork.

## Dependence on Vulnerable Cryptography

Bitcoin relies on ECDSA for signatures and SHA-256 for hashing. While ECDSA is broken by Shor’s algorithm, SHA-256 is only quadratically weakened by Grover’s algorithm, offering a relatively resilient hash function. Monero, however, relies heavily on discrete logarithm-based cryptography throughout its ring signatures, stealth addresses, and Pedersen commitments. These are directly vulnerable to Shor’s algorithm, making Monero more fragile under quantum attack.

## Social and Economic Coordination

Bitcoin benefits from a large developer ecosystem, conservative change management, and strong incentives to coordinate upgrades. Monero has a smaller developer base, frequent hard forks, and more complicated migration requirements. Coordinating a quantum-resistant upgrade across Monero’s user base would be challenging, and any incomplete migration could compromise historical privacy.

## Conclusion

Monero is optimized for privacy today, but its very design makes it more susceptible to quantum computing threats than Bitcoin. The key vulnerabilities include permanent public key exposure, retroactive privacy compromise, complex cryptography that complicates upgrades, dependence on Shor-vulnerable schemes, and smaller social and economic coordination incentives.

Bitcoin, while less private, is structurally better positioned to withstand the advent of quantum computing. Its conservative cryptography, minimal public key exposure, and clear upgrade path give it a decisive advantage in long-term security.

Monero’s privacy may be formidable against classical attacks, but in a quantum future, Bitcoin’s simplicity may prove its greatest strength.

Monero Is less quantum resistant than Bitcoin

Days ago, I [posted about](https://stacker.news/items/1319881) the privacy of Bitcoin, and it went completely unnoticed. 
I believe this was intentional, as many Bitcoiners prefer not to shed light on the darker sides of their beloved "idol."

Don't get me wrong...I’m a huge Bitcoiner myself, perhaps even more "maxi" than many here. 
But I think it’s crucial to acknowledge the limitations of this tool, too.  

Yesterday, the [SEC chair called Bitcoin and cryptocurrencies a financial panopticon](https://cryptonews.com.au/news/sec-chair-warns-crypto-could-become-a-financial-panopticon-without-privacy-safeguards), and I'm growing increasingly concerned about this. 
As I mentioned in my original post, I know people who work for agencies involved in blockchain intelligence, and the things they’ve shared with me have left me quite unsettled.  

We’ve always understood that Bitcoin makes a tradeoff between decentralization, transparency, and resistance to censorship, versus privacy. But I don’t think we’ve fully grasped the implications of this: especially now, with the rise of AI technologies that are significantly aiding governments and institutions in this space.

Maintaining privacy on Bitcoin is becoming harder every day, and I fear it will be nearly impossible in a few years if things continue this way.

I’m really curious to hear your honest opinions: How do you perceive this issue? How are you preparing to maximize your privacy on Bitcoin?

Let’s not shy away from uncomfortable topics, ignoring them doesn’t do anyone any good.


A Reality We Can’t Ignore

tutorials

## Abstract
This introductory post is intended for anyone interested in exploring programmatic interaction with Nostr. 
In this tutorial, we’ll build a command-line tool in Rust to explore the Nostr protocol. 
We’ll use the [nostr-sdk](https://crates.io/crates/nostr-sdk) crate for simplicity and modern API support.  
We’ll start simple: just generating keys, and gradually add features: saving keys locally, posting notes to relays, fetching them back etc. 
By the end, you’ll have a small experimental Nostr CLI to play with and that you can expand upon for custom use cases.    


>**NOTE**
>This tutorial has been inspired by tools like [nostrdm](https://github.com/r3DRUN3/nostrdm), that showcase the potential of Nostr as a distributed and decentralised infrastructure.  

## Prerequisites
- Basic knowledge of Nostr.
- Rust [installed](https://rust-lang.org/tools/install/).  
- (a little bit of) programming experience.


## Step 0: Create new project

Run the following command to generate a new rust project via Cargo (rust package manager):  
```bash
cargo new hello_nostr && cd hello_nostr
```  

this will generate the following folder sctructure:
```bash
.
├── Cargo.lock
├── Cargo.toml
├── README.md
└── src
    ├── main.rs
```
Now put these dependencies inside the generated `Cargo.toml` file:  
```toml
[dependencies]
nostr-sdk = "0.44"
tokio = { version = "1", features = ["full"] }
```

## Step 1: Generate a Nostr Keypair  
As per [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md), every Nostr user is identified by a public/private keypair, which is used as the identity for signing events using Schnorr signatures of secp256k1 keys.  
So when we generate a keypair, the public key (npub) is your identity, and the private key (nsec) is your secret for signing events. 

In order to generate a key pair, you need to insert the following code inside `main.rs`:  
```rust
use nostr_sdk::prelude::*;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Generate a new keypair (sec256k1 / Schnorr)
    let keys = Keys::generate();

    println!("Public key (npub): {}", keys.public_key().to_bech32()?);
    println!("Secret key (nsec): {}", keys.secret_key().to_bech32()?);

    Ok(())
}
```  

Now run this code with `cargo run` and observe how the keys are generated for you:  

![](https://m.stacker.news/121332)



## Step 2: Save the Keypair Locally  
To reuse your identity across runs, we’ll save it in a `.env` file (Nostr events require persistent keys, because the signature determines ownership).  
Add `dotenvy` dependency in `Cargo.toml` file:  
```toml
[dependencies]
nostr-sdk = "0.44"
tokio = { version = "1", features = ["full"] }
dotenvy = "0.15"
```  

Now update `main.rs` with the code for saving the generated keys:  
```rust
use nostr_sdk::prelude::*;
use dotenvy::dotenv;
use std::env;
use std::fs;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    dotenv().ok();

    // Load or generate keys
    let keys = if let Ok(nsec) = env::var("NOSTR_KEY") {
        Keys::parse(&nsec)?
    } else {
        let keys = Keys::generate();
        fs::write(".env", format!("NOSTR_KEY={}\n", keys.secret_key().to_bech32()?))?;
        keys
    };

    println!("Public key (npub): {}", keys.public_key().to_bech32()?);
    println!("Secret key (nsec): {}", keys.secret_key().to_bech32()?);

    Ok(())
}
```
Running this code will create a local `.env` file like this:  
```text
NOSTR_KEY=nsec1<rest-of-key-here>
```  


## Step 3: Post a Note to a Pair of Relays  
Once you have a persistent keypair, the next natural step is posting a text note to the Nostr network, as per [NIP-10](https://github.com/nostr-protocol/nips/blob/master/10.md).  
This involves: 
- creating a client 
- connecting to one or more relays 
- building a “text note” event 
- sending it.  

Add the following to your `main.rs`:  

```rust
use nostr_sdk::prelude::*;
use dotenvy::dotenv;
use std::env;
use std::fs;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    dotenv().ok();

    // Load or generate keys
    let keys = if let Ok(nsec) = env::var("NOSTR_KEY") {
        Keys::parse(&nsec)?
    } else {
        let keys = Keys::generate();
        fs::write(".env", format!("NOSTR_KEY={}\n", keys.secret_key().to_bech32()?))?;
        keys
    };

    println!("Public key (npub): {}", keys.public_key().to_bech32()?);

    // Create a client with your keys (signer)
    let client = Client::new(keys.clone());

    // Add relays — you can list multiple for redundancy / broader reach
    client.add_relay("wss://relay.damus.io").await?;
    client.add_relay("wss://relay.nostr.band").await?;
    client.connect().await;

    // Build a text‑note using EventBuilder
    let builder = EventBuilder::text_note("Hello, Nostr from Rust CLI!");

    // Send the note (signed automatically using your keys)
    let output = client.send_event_builder(builder).await?;

    println!("Event ID: {}", output.id().to_bech32()?);
    println!("Sent to: {:?}", output.success);
    println!("Not sent to (if any): {:?}", output.failed);

    Ok(())
}
```

Now run this and observe the output:  

![](https://m.stacker.news/121333)


This tells us that the note has been sent to 2 relays and we can confirm this 
by searching for the user key or note id from a Nostr web explorer like [primal.net](https://primal.net/search/note10gry7824jj6l9sush7s4ehy53sev9ugp6f7pmlg9gveja3v04lnswymz9k):  


![](https://m.stacker.news/121334)


## Step 4: Fetch Notes from a Relay  
Once you can post notes, the next step is fetching them.  
This is where Nostr shines as a decentralized network: you can query multiple relays for events by pubkey, kind, or time range.

Add the following code to `main.rs` to fetch your own recent notes:  
```rust
use nostr_sdk::prelude::*;
use dotenvy::dotenv;
use std::env;
use std::time::Duration;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    dotenv().ok();

    // Load your keys (same as in sending example)
    let keys = if let Ok(nsec) = env::var("NOSTR_KEY") {
        Keys::parse(&nsec)?
    } else {
        panic!("NOSTR_KEY not found in .env");
    };

    let my_pubkey = keys.public_key();

    // Create a client (no signer needed to fetch)
    let client = Client::default();

    // Add relays
    client.add_relay("wss://relay.damus.io").await?;
    client.add_relay("wss://relay.nostr.band").await?;
    client.connect().await;

    // Filter: only TextNote events from this user, limit to 10
    let filter = Filter::new()
        .kind(Kind::TextNote)
        .authors(vec![my_pubkey])
        .limit(10);

    let events = client.fetch_events(filter, Duration::from_secs(10)).await?;

    println!("Got {} events from you:", events.len());
    for ev in events {
        println!("---");
        println!("Event ID (hex): {}", ev.id.to_hex());
        println!("Created at: {}", ev.created_at);
        println!("Content: {}", ev.content);
    }

    Ok(())
}
```  

Run this and observe how your notes are returned from the relays:  

![](https://m.stacker.news/121335)


## Step 5: Subscribe or Stream Events (Live updates)  

So far we’ve performed one-off fetches, but Nostr is designed for long-lived subscriptions where a client maintains a connection and receives new events as they appear.  
This is how dashboards, bots, or feed readers work.  

Here’s how to listen to a continuous stream of events:  
```rust
use nostr_sdk::prelude::*;
use std::time::Duration;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::default();

    client.add_relay("wss://relay.damus.io").await?;
    client.connect().await;

    // Subscribe to incoming text notes
    let filter = Filter::new()
        .kind(Kind::TextNote)
        .limit(50);

    let mut stream = client.stream_events(filter, Duration::from_secs(30)).await?;

    println!("Listening for events (Ctrl+C to exit)…");

    while let Some(event) = stream.next().await {
        println!("--- New Event ---");
        println!("{}", event.as_json());
    }

    Ok(())
}
```  

This code uses the standard subscription model to fetch events from relay and displays them:  

![](https://m.stacker.news/121336)

## Useful Resources  
If you found this introduction to Nostr in Rust interesting and want to go deeper, here are some useful resources: 
- [Nostr Improvement Proposals](https://nips.nostr.com/)  
- [Rust Nostr Book](https://rust-nostr.org/)  

Getting Started with Rust + Nostr: Building a CLI Playground

I am increasingly fatigued by those who claim to be genuine Bitcoiners yet remain obsessively focused on its price in fiat currency.
If you fall into this (unfortunately large) category, you should not consider yourselves Bitcoiners.  
Your understanding of monetary fundamentals is virtually nonexistent; you merely ride Bitcoin opportunistically, like parasites, while your preferred currency is ultimately destined to fail:
here Is what your fiat looks like in the mid/long therm with the soundest Money as the denominator:

![](https://m.stacker.news/121165)

I will never regard anyone as a Bitcoiner unless they meet at least the following minimum criteria:

1. Self-sovereign: They maintain full control over their own private keys and avoid custodial solutions like the plague.


2. Operate their own full node: They validate the rules independently, contributing to network robustness and ensuring they do not rely on third-party verification.


3. Engage in mining, even on a small scale: Whether through modest hardware or lottery-style setups, they participate directly in Bitcoin’s security model.


4. Demonstrate a deep understanding of Bitcoin’s monetary principles: They grasp scarcity, decentralization, immutability, and the separation of money from state control.


5. Use Bitcoin in real economic activity: They transact in Bitcoin when appropriate, rather than treating it solely as a speculative asset.


6. Contribute to the ecosystem: This may include educating others, supporting open-source development, strengthening privacy practices, or advocating for censorship-resistant infrastructure.


7. Commit to long-term stewardship: They view Bitcoin not merely as an investment but as a technological, economic, and philosophical breakthrough that requires responsible participation.




You are not true Bitcoiners

One of the biggest misconceptions in the broader crypto world is that Bitcoin is “anonymous.” 
In reality, Bitcoin’s privacy model is far weaker than many people (even seasoned Bitcoiners) assume, and understanding this is crucial for anyone who interacts with the network beyond a custodial wallet.
If anything, Bitcoin sits on the opposite end of the privacy spectrum: it is radically transparent by design.

## Why Bitcoin Privacy Is Hard

Bitcoin uses a public, append-only ledger. 
Every on-chain transaction reveals:

*Inputs* (UTXOs that are being spent)

*Outputs* (UTXOs being created)

*Amounts*

*Addresses involved*

*Time of confirmation*


Even though addresses are not directly tied to identity, the structure of transactions leaks a surprising amount of information.
Combined with modern blockchain analysis tools, this is often enough to reconstruct entire financial histories.
I know someone who works for a company specializing in blockchain intelligence and transaction analysis, and the amount of information these firms can extract (and routinely share with government agencies) is far beyond what most people imagine. 
Their ability to correlate on-chain activity with real-world identities is easily an order of magnitude more advanced than the plebs generally assumes.  

A few technical realities make privacy especially difficult:

1. The UTXO model is highly linkable

When you spend UTXOs, you typically reveal which “coins” belong to the same entity. If you combine multiple UTXOs in a single transaction, clustering algorithms almost always assume they’re controlled by the same user. This heuristic is often correct and the reason why UTXO consolidation Is a privacy killer.  

2. Reuse of addresses is catastrophic for privacy

Every payment sent to a reused address links back to every prior payment it ever received. Reusing an address effectively creates a public account history.

3. Change outputs leak information

Most transactions create a payment output and a change output. Most wallets are predictable about where change goes. Analysts can often identify which output is the payment and which is the change, which reveals how much the sender actually controls.

4. KYC on-ramps and off-ramps deanonymize real identities

Even if your on-chain footprint is clean, once a KYC exchange knows that a set of UTXOs belongs to you, **almost everything** you do afterward can be tracked with high confidence.

5. Lightning routing data reduces some visibility, but not all

Lightning highly improves privacy compared to on-chain, but it is not a perfect solution: nodes see routing traffic, and certain channel structures can still leak information.


## Why This “Weak Privacy” Has Real Benefits

While it’s easy to frame transparency as a flaw, the public nature of Bitcoin contributes to several core strengths:

• Auditability

Anyone can verify the total supply, validate historical transactions, and inspect suspicious activity without asking permission.

• Simplicity & Robustness

A transparent UTXO model is conceptually and technically simpler than privacy-heavy cryptographic constructions. That simplicity helps Bitcoin remain stable, verifiable, and secure.

• Resistance to complex trust assumptions

Unlike privacy coins, Bitcoin does not rely on trusted setups or opaque cryptography that could hide backdoor or inflation bugs for years.

In other words, Bitcoin intentionally favors transparency and verifiability over strong default privacy. That tradeoff is not a mistake but fundamental to its reliability.


## Practical Ways to Improve Your Bitcoin Privacy

Even though Bitcoin isn’t private by default, users can meaningfully improve their privacy posture. Some of the most effective strategies:

1. Use a fresh address for every payment

Most modern wallets do this automatically through BIP32/HD wallets. If yours doesn’t, switch wallets.

2. Avoid combining UTXOs unless absolutely necessary

Selective coin control helps you avoid linking separate parts of your history.

3. Pay attention to change

Some wallets support “avoid change” transactions or manual coin selection to reduce change-based deanonymization.

4. Use Lightning whenever possible

Lightning transactions are not recorded on the blockchain, which dramatically reduces your long-term footprint. Opening/closing channels still touches the chain, but the majority of activity stays off-chain.

5. Use privacy-focused wallets

Wallets like Sparrow, Samourai, or Wasabi provide tools such as coin control, labeling, Tor connections, and coinjoin. (Different tools have different tradeoffs: study and understand them.)

6. Prefer peer-to-peer acquisition methods when feasible

Non-KYC sats give you a much cleaner starting point, especially when combined with good UTXO discipline.

7. Be mindful of behavioral leaks

Financial privacy isn’t just about the blockchain. IP addresses, timing, spending patterns, and reuse of services all create metadata that can be linked.


## Final Thoughts


Privacy on Bitcoin isn’t automatic; it’s a skill. 
And like any skill, it improves dramatically when you understand how the system works and adopt the right habits.

If Bitcoin users collectively become more privacy-aware, the entire network benefits. Better privacy isn’t just good for individuals but it strengthens the resilience of Bitcoin as a whole.


Bitcoin Privacy Is Worse Than Most People Think

At the beginning of May 2011, the **entire** Bitcoin network had roughly the same hashrate as a single **Bitaxe Gamma 601** does today.  
Think about that for a moment: what was once the cumulative power of every miner on Earth can now be matched by a tiny, efficient, silent, open-source device sitting on a bookshelf.

That contrast tells an important story: Bitcoin has grown unimaginably, but so has the scale of industrial mining. 
Today, the global network runs at over a quintillion hashes per second, and most of that power is concentrated in giant mining, farms, warehouses full of ASICs, optimized and controlled by only a handful of players. The technology is impressive… but the centralization risk is real.

Now imagine something different.

Take only urban Europe as an example: If every house had just one Bitaxe Gamma (roughly 1.2 TH/s) the combined hashrate would contribute **around 10% of the entire Bitcoin network**. Ten percent! Not from mega-farms and steroid-powered mining machines, but from ordinary people: homes, families, hobbyists, citizens choosing to participate and just in urban Europe alone.
If we extend this to every urban household in the world, it could exceed twice the current Bitcoin network hashrate (i.e., ~230%+ of current global hashrate).

This is the beauty of *lottery mining*: you don’t need to chase profitability or compete with industrial operations. 
You don’t need a warehouse or a cooling system. 
You simply add your small, steady trickle of hashes to the global pool. 
You probably won’t find blocks in your lifetime, but every hash you contribute strengthens decentralization, broadens participation, and pushes power back toward individuals instead of corporations. 
You can also join an open pool and receive daily lightning payments for the work your little miner does.
If you join a pool, you dont even need to run your own node for this (although I really suggest it).  

Bitcoin was born from the idea that anyone, anywhere, could participate. 
Today, devices like the Bitaxe bring that spirit back. 
They make it possible for millions of people to contribute tiny amounts of hashrate that, together, form a massive, decentralized foundation.

**So run a miner. Join the network. Strengthen Bitcoin. Even a single terahash matters, it always has.**


Bitcoin needs you

security

Purple teaming detection automation toolkit

I recently started doing lottery mining with this little Bitaxe Gamma 601 and I love watching it work!   
It relaxes me, and I admire its dedication: 
while the whole world seems busy finding new ways to divide and tear us down, while geopolitical tensions paint a bleak picture of the future, while some people panic because Bitcoin’s fiat “price” is dropping, it just keeps going, tirelessly doing its job.  
It reminds me that there’s always hope, and that Bitcoin is there for us, waiting.  

Tick tock, next block 🕓⏹️

![](https://m.stacker.news/117608)

![](https://m.stacker.news/117609)

Be like this little guy!

We stand on the edge of a transformation that very few are examining with the depth it requires.
Everyone is looking at Artificial Intelligence: 
more powerful models, autonomous agents, new digital economies...yet the most uncomfortable question is avoided (or ignored):

𝗶𝗻 𝘄𝗵𝗮𝘁 𝗳𝗼𝗿𝗺 𝗼𝗳 𝘃𝗮𝗹𝘂𝗲 𝘄𝗶𝗹𝗹 𝗮 𝘄𝗼𝗿𝗹𝗱 𝗼𝗽𝗲𝗿𝗮𝘁𝗲 𝘄𝗵𝗲𝗿𝗲 𝗲𝗰𝗼𝗻𝗼𝗺𝗶𝗰 𝗮𝗰𝘁𝗼𝗿𝘀 𝘄𝗶𝗹𝗹 𝗻𝗼 𝗹𝗼𝗻𝗴𝗲𝗿 𝗯𝗲 𝗼𝗻𝗹𝘆 𝗵𝘂𝗺𝗮𝗻?

Look at what’s emerging: 
instant micropayments to access data or APIs; agents that sell output (code, analysis, content) and get paid per request; devices bargaining with each other (machine-to-machine) for energy, bandwidth, or updates; adaptive paywalls.
It’s a software-native economy.  

The problem is that we still rely on financial infrastructures built on anthropocentric assumptions:
bank accounts tied to jurisdictions, credit cards tied to personal identity, regulators imposing borders.
But AI has no passports: an agent operating in Germany won’t wait for business hours, weekdays, currency conversions, and the approval of 9 banking intermediaries to interact with an agent in Australia.  
We need a currency native to cyberspace.
Credit cards don’t scale between machines; national currencies don’t scale in a nationless economy.  

**Bitcoin, with Lightning, does**.  

And this isn’t speculation: 
MCP servers already exist that allow agents to control Lightning wallets: AIs can own, spend, and earn.
The real question is whether we are culturally ready for a world where value flows between non-human intelligences without asking for permission.
If AI is the new actor in history, Bitcoin is the tool that will allow it to participate in the economy. 

**Not understanding Bitcoin today means not understanding the grammar of the future**.

AI, Value, and the End of Anthropocentric Finance

An important part of being a Bitcoiner should be “spreading the word,” talking to others, and building communities.  
As I’ve mentioned several times, whenever I make in-person purchases I always ask the merchants if they accept Bitcoin. 
Unfortunately, the vast majority of the time I get puzzled or judgmental looks, but sometimes there’s interest. 
Once, while talking to a young business owner, I even ended up helping him set up a Bitcoin PoS. Sadly, where I live, Bitcoin culture is very limited and you often feel alone (thanks God places like SN exist!) 
What do you do to connect with other Bitcoiners in your city/region/country? 
How are you working toward building a community and a circular economy based on Bitcoin?

What do you do to build a community?

I come from a strong technical background, yet I have never encountered a technology that pushed me to explore and dive so deeply into fields that seem so unrelated to one another:  
from economics to philosophy, history, mathematics, game theory, and more.  

And the fact that anyone can take part in the network by running their own node, and even join the mining process with a tiny Bitaxe and receive daily sats over Lightning...that for a tech nerd like myself feels like pure magic.

Thanks you Satoshi 🧡

What I love about Bitcoin.

nostr

A friend of mine has developed [this tool](https://github.com/r3drun3/nostrdm) to implement a **1-1 instant private chat** leveraging **Nostr**.  

I had the chance to test it, and it seems quite interesting, although still in an early stage. 
However, wasn’t Dorsey also working on something similar? 🤣
Nostr has great potential as an infrastrutture layer! 

NostrDM: a 1 to 1 instant private chat via Nostr

Hey Bircoiners, I’ve got to ask:
what did it for you?  

What was the “aha!” moment that finally made you take the orange pill and never look back?  

Was it a meme? A book? A transaction that clicked?
Share your story, always curious to hear what finally flips the switch! ⚡️

What orange pilled you? 💊

lightning

If you’re reading this, you’re probably curious about the Lightning Network and how to get hands-on building or using it: with this post I want to list the minimum set of resources that have been invaluable for me in my own jourey toward mastering Lightning.  

> ⚠️ Warning
This post is intended for those who want to get their hands dirty: not just use a custodial wallet, but run and manage their own Lightning node.

Before diving in, a quick heads-up on **prerequisites**:

- A minimum technical familiarity: you should be comfortable running services, using command line/shell, reading docs, configuring things.

- An understanding of how Bitcoin works at a protocol level (UTXOs, blocks, keys, addresses). The Lightning Network is a Layer-2 built on Bitcoin, so the stronger your base, the better.


If you have those, you’re ready to go !!


---

🔧 Key Resources

1. Book: Mastering the Lightning Network (Antonopoulos, Osuntokun & Pickhardt)
This is one of the most comprehensive deep-dives into Lightning: how it works, channel architecture, routing, wiring, security, etc. 
The draft/manuscript is [available for free on GitHub](https://github.com/lnbook/lnbook).  


2. Builder’s Guide by Lightning Labs.
Their [Builder’s Guide to the LND Galaxy](https://docs.lightning.engineering/ ) covers core Lightning Network topics (payment channels, routing, invoices, liquidity) and how to build with their stack (LND, Lightning Terminal, Loop, Pool, Taproot Assets).


3. Practice!
Once you’re familiar with the core concepts covered in the resources above, it’s time to get your hands dirty!
A tutorial I personally found very useful is [Lightning Network the Hard Way](  https://github.com/stackzoo/lightning-network-the-hard-way).
It walks you step by step through the initial node setup and basic transactions, all on the testnet so you wont lose anything if you Fup!



---

✅ Next steps for you

Pick one resource from above and schedule time this week to explore (e.g., read Chapter 1 of the book, or set up a local LND via the sample app).

Set up a test environment (regtest or testnet) and experiment: open a channel, send an invoice, route a payment.

Share your findings or questions here in the comments and feel free to post additional resources you discover so we can all learn together!



---

⚡ Stay charged!

Getting started with the Lightning network ⚡ - A resource Dive

Are you able to live on a Bitcoin standard? 2025 edition

>A gov doesn't give a shit about your BTC .

 
Agree to heavily disagree on this one.  
First of all, all governments are equally parasitic, though they employ different strategies.
Maybe your government doesn’t care how many BTC you hold (which is highly unlikely), but in my country they’ve become a tool for unhetically taxing profits (even if you did not sold them for fiat), and the level of scrutiny has increased dramatically.   
I’ve even received notices for transactions I made six years ago (**before** I stopped using KYC services) and now I’m required to pay substantial taxes on them.
You don’t hold the absolute truth, and you don’t live everywhere.
Have a nice day sir.

Using a govID does not automatically translate in my gov knowing how much BTC I have.

I disagree on this. 
My gov is becoming more and more authoritarian in wanting to trace/control/tax Bitcoin.  
**I dont want my gov knowing how much BTC I have.**

Bitwage is heavily KYC. 
I stopped using those kind of services years ago.