The case seemed routine at first. A group of people accused of vandalizing and attacking an ICE detention facility in Alvarado, Texas on July 4, 2025. A federal trial in Fort Worth. Standard digital evidence.

Then, on March 10, 2026, FBI Special Agent Clark Wiethorn took the stand and described something that stopped the security community cold.

Investigators had recovered Signal messages from a defendant’s iPhone. Not because they hacked Signal. Not because they exploited some zero-day vulnerability. Signal’s end-to-end encryption was never touched. The messages were sitting in a completely different place — in Apple’s own internal notification database — and they had been there the whole time, even after Signal had been deleted from the phone.

How end-to-end encryption actually works — and where it stops

End-to-end encryption (E2EE) means that a message is scrambled on your device before it leaves, travels across the internet in unreadable form, and is only decrypted on the recipient’s device. Signal’s servers never see the content. Neither does anyone intercepting the connection.

This is real, and it works exactly as advertised. The problem is what happens next.

When a message arrives on your phone, Signal has to display a notification. To do that, it decrypts the message locally and passes the readable text to iOS — to Apple’s notification system — so it can appear on your lock screen. At that moment, iOS takes that decrypted text and writes it into its own internal notification database. A database that Signal has no control over. A database that doesn’t get deleted when you delete Signal. A database that can retain content for weeks.

Forensic investigators, using tools like Cellebrite, know exactly where that database lives. And with physical access to a seized device, they can pull everything from it — including the full text of messages from apps long since uninstalled.

That is precisely what happened in the Prairieland case. Defense attorney Harmony Schuerman described the mechanism in plain terms in her trial notes:

They were able to capture these chats because of the way she had notifications set up on her phone — anytime a notification pops up on the lock screen, Apple stores it in the internal memory of the device.

Only incoming messages were recovered, not outgoing ones. The notification database captures what arrives on your lock screen, nothing else.

This isn’t a Signal problem. It’s a layer problem.

Signal did not fail here. The encryption between sender and recipient worked perfectly. What failed was an assumption most users make without realizing it: that an encrypted app controls everything that happens to its messages on your device.

It doesn’t.

The operating system is a separate layer, and it has its own logic. Once a message clears the encrypted channel and lands on your phone, the OS can — and does — make its own copies for its own purposes. Notifications, caches, system logs. None of these are within the app’s reach.

The same vulnerability applies to WhatsApp, Telegram, iMessage, and any other app that shows message content in lock screen previews. The Prairieland case surfaced it in a Signal context, but the underlying mechanism is universal.

It’s also worth nothing what this attack requires: physical access to your unlocked device. This is not a remote exploit. It’s not surveillance over the network. It’s a forensic extraction that happens after a device has been seized. For most people, that narrows the threat significantly. For journalists, lawyers, activists, or anyone whose device could end up in the wrong hands — it’s a direct and documented risk.

The fix is two settings, not one

Here is where many guides get it wrong: disabling notification previews at the iOS system level alone is not sufficient. You need to act at both layers.

On iOS:

Go to Settings → Notifications → Signal → Show Previews → Never.

This prevents iOS from writing decrypted content into its notification database.

Inside Signal:

Go to Signal → Settings → Notifications → Notification Content → No Name or Content.

This prevents Signal from passing the decrypted message text to the iOS notification API in the first place.

Both steps are necessary. One without the other leaves a gap.

On Android, the situation is structurally similar but the system’s built-in notification history only retains data for 24 hours by default, and users can disable it entirely via Settings → Notifications → Notification History. The primary mitigation remains the same: inside Signal, set notification content to show nothing. No text reaches the OS layer if it’s never passed there.

Three things that do not fix this problem:

Disappearing messages won’t help — the notification preview is written to the database before Signal’s deletion timer ever runs. Deleting the Signal app won’t help — the OS database persists independently. Enabling iCloud Advanced Data Protection won’t help — that protects cloud backups from server-side access, which is an entirely different threat model.

What have we learnt?

Encryption protects the channel. It does not protect the device. The device can be always seized legally or with violence. You cannot trust data you have on it.

These are two separate threat models, and conflating them leads to a false sense of security. Signal is not broken. Using Signal is still significantly more private than using unencrypted alternatives. But privacy is a stack of choices, not a single switch. The app is one layer. The operating system is another. Physical device security is a third.

The Prairieland case is useful precisely because it makes this concrete. A real investigation. A real forensic technique. A real courtroom exhibit. And a real setting that, had it been configured differently, would have prevented the recovery entirely.

Two settings. That’s all it would have taken.

Want to see exactly how this works — with a full walkthrough of the technical mechanism and the step-by-step configuration for both iOS and Android? I covered everything in a dedicated video on my YouTube channel (in italian): youtube video

If you use servers or communications infrastructure for a business and want to think seriously about your security posture — including private hosting outside major cloud providers — take a look at Denali PRO. Swiss-based infrastructure provider, Lightning Network payments accepted.

Every Bitcoin transaction is permanently recorded on a public ledger. Every UTXO you spend leaves a trace. Every address you reuse becomes a thread that chain analysis firms can pull. This is not a bug — it is how the protocol works, by design. But it does mean that if you care about financial privacy, you need to think carefully about how you move your coins.

The Lightning Network does not solve every privacy problem in Bitcoin. But used with intention, it offers tools that on-chain transactions simply cannot replicate. This article covers how to open Lightning channels with privacy in mind, how to use specific UTXOs for channel funding, how private (unannounced) channels work, and how the loop-out technique can effectively break the on-chain link between old and new UTXOs.

All examples use LND (Lightning Network Daemon) with lncli version 0.20.1 on mainnet.

What the Blockchain Actually Reveals

When you open a Lightning channel, a funding transaction is broadcast on-chain. This transaction creates a 2-of-2 multisig output — the channel itself. It is visible to everyone. The UTXO you used to fund the channel is publicly linked to the channel’s funding transaction. That link is permanent and irreversible on-chain.

This is why the choice of which UTXO you use to open a channel matters. If that UTXO is associated with your identity — because it came from a KYC exchange, or was received at an address you’ve publicly shared — then the channel open carries that identity forward.

Lightning transactions themselves do not appear on-chain. Payments are routed off-chain through channels, using onion routing to obscure the path from intermediate nodes. Common on-chain analysis heuristics — common-input-ownership, change address detection, amount-based clustering — fundamentally do not apply to Lightning payments because there are no on-chain inputs or outputs for each individual payment. The channel balance is known only to the two parties sharing it.

But “better than on-chain” is not the same as “private.” Let’s look at where the real risks and real opportunities lie.

Public Channels vs. Private (Unannounced) Channels

By default, when you open a Lightning channel, you announce it to the network. Your node ID, your peer’s node ID, the channel capacity, and the funding UTXO all become part of the public channel graph — discoverable by anyone querying the network.

For routing nodes, this is necessary. Announcing a channel allows other nodes to route payments through you, which earns fees. But if you are not running a routing node — if you just want to send and receive payments privately — announcing your channels is an unnecessary exposure.

LND offers a --private flag precisely for this purpose. A private channel (also called an unannounced channel) is not broadcast to the network graph. Your peer knows about it, and you can still route payments through it using route hints, but no third party can discover its existence by querying the graph.

Opening a Standard (Announced) Channel

in this example we open to the Loop node, using a specified UTXO in the onchain wallet.

lncli openchannel \
  --node_key 021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d \
  --connect 50.112.125.89:9735 \
  --utxo XXX:0 \
  --fundmax \
  --sat_per_vbyte 5

This opens a channel that will be announced to the network. The channel will appear in graph queries. Anyone can see your node’s connection to this peer.

Opening a Private (Unannounced) Channel

lncli openchannel \
  --node_key 021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d \
  --connect 50.112.125.89:9735 \
  --utxo XXX:0 \
  --fundmax \
  --private \
  --sat_per_vbyte 5

The --private flag tells LND not to announce this channel. The funding transaction still appears on-chain — you cannot avoid that — but the association between your node and this peer is not broadcast to the graph.

Important nuance: the funding transaction is still publicly visible. A sufficiently motivated chain analyst who knows your node’s on-chain wallet addresses can still identify the funding output as a 2-of-2 multisig and flag it as a likely Lightning channel. What they lose is the graph-level confirmation of who your peer is and that this channel exists as an active route. This is a meaningful improvement, not a complete solution.

Coin Control: Choosing Which UTXO Funds the Channel

One of the most significant privacy tools available in modern LND is explicit UTXO selection for channel opens. This was introduced in LND v0.17.0 and is available in all subsequent versions including 0.20.1.

The --utxo flag lets you specify exactly which UTXO the funding transaction will consume. Combined with --fundmax, it ensures the entire UTXO is consumed — no change output is created.

lncli openchannel \
  --node_key <PEER_PUBKEY> \
  --utxo <txid>:<vout> \
  --fundmax \
  --sat_per_vbyte 5

Why does this matter? Two reasons:

No change output. When LND’s wallet automatically selects coins for a channel open, it may combine multiple UTXOs or create a change output. Change outputs are a classic privacy leak — chain analysis heuristics use them to cluster UTXOs and infer wallet ownership. Using --utxo with --fundmax eliminates this by spending the entire selected UTXO into the channel, leaving no residue.

Deliberate UTXO segregation. If you have UTXOs of different origin — some from a KYC exchange, some mined, some received peer-to-peer — you want full control over which history gets attached to a channel open. Letting the wallet pick automatically risks merging inputs from different sources, which is one of the strongest signals chain analysis can find.

To list your available UTXOs before opening a channel:

lncli listunspent

This will show you each UTXO, its txid:vout reference, amount, and confirmation status.

The Loop-Out Technique: Breaking the UTXO Trail

This is where Lightning becomes genuinely useful for privacy beyond just “not broadcasting transactions.” The loop-out technique allows you to effectively sever the on-chain link between an old UTXO and a new one — without CoinJoin, without a centralized mixer, and without closing your channel.

The mechanism is a submarine swap — a trustless atomic exchange between an off-chain Lightning payment and an on-chain Bitcoin output. The key property is that the swap is non-custodial: the counterparty cannot steal your funds because the on-chain payment is conditional on the completion of the off-chain payment, enforced by hash time-locked contracts (HTLCs). As Mastering the Lightning Network explains, submarine swaps allow the exchange of on-chain bitcoin for Lightning payments and vice versa, atomically and without requiring trust in the counterparty.

The privacy flow looks like this:

UTXO you want to dissociate from → channel funding tx → off-chain LN payment → submarine swap → clean UTXO at fresh address

Step by step:

1. Open a channel using the whole UTXO you want to disassociate from. Preferably an unannounced channel.

2. Execute a loop-out: send a Lightning payment through the channel and receive the equivalent amount on-chain at a brand-new address that has never appeared on the blockchain before.

3. Result: the original UTXO is now “inside” the channel’s funding transaction. The blockchain sees the funding tx, then sees a new on-chain output at an unrelated address. The connection between the two is not visible on-chain.

The channel closing transaction will eventually appear on-chain if you close, but by that point the funds have already exited through the loop-out. The chain sees disconnected events, not a direct transfer.

Example opening

we open a private channel to Aciq:

dev@lnbits00:~$ lncli openchannel --node_key 03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f \
--connect 34.239.230.56:9735 \
--utxo edd21f89192aa98592d08323320c6d19d7c92e395664ccXXXX:0 \
--fundmax \
--private \
--sat_per_vbyte 2
{
    "funding_txid": "fab3afc09824bbc7ef22f31727ec390190cfbXXX"
}

result

here the correct channel setup ready to manage with loop out

as you can see onchain, this channel opening has not generated a change output, exactly as we needed for the purpose of this experiment

Using Loop (Lightning Labs)

Loop is the official submarine swap tool from Lightning Labs, the team behind LND. It requires a running LND node:

loop out --amt <satoshis> --addr <new_onchain_address>

Replace <satoshis> with the amount you want to swap out (must be within your channel’s local balance), and <new_onchain_address> with a fresh address generated from a wallet that has no prior transaction history — ideally a hardware wallet address you have never used.

You can monitor progress with:

loop monitor

Loop charges a small fee for the service, which includes both routing fees for the off-chain leg and on-chain fees for the sweep.

Using Boltz (Non-Custodial Alternative)

If you prefer not to use a Lightning Labs service, Boltz offers the same submarine swap functionality and is widely used in the Bitcoin privacy community. The conceptual flow is identical:

you → (private channel) → peer → ... → Boltz → fresh UTXO on-chain

Boltz also operates non-custodially using the same HTLC mechanism. You initiate the swap from their interface or API, pay the Lightning invoice through your node, and receive on-chain funds at the address you specify. No account, no KYC.

What This Does Not Protect You From

Privacy techniques are only useful if you understand their actual scope. Here is what the above methods do not protect you from:

The funding transaction is always public. Whether your channel is announced or private, the on-chain funding transaction exists. A chain analyst can see a 2-of-2 multisig output being created. Post-Taproot, cooperative channel closes look like regular single-sig transactions, which improves this picture — but unilateral closes still reveal HTLC scripts, which are identifiable.

Your peer knows everything about the channel. In a private channel, your direct peer knows the channel exists, knows the funding UTXO, and observes every payment going through it. If your peer is a large, well-connected routing node run by a company, you are trusting them with significant information.

A node with only one channel has no anonymity set. If your node has a single channel to a single peer, that peer can observe all your payments regardless of onion routing. As documented in the Bitcoin Wiki Privacy page, when a Lightning node wallet has only a single channel connection, the intermediate node can obtain a lot of information about payments regardless of the onion-routing used. Multiple channels to diverse peers expand your anonymity set.

Loop-out is not full unlinkability. Blockchain analysis firms like Chainalysis are aware of the patterns created by Lightning channel opens and loop-outs. The “Star” and “Collector” heuristics can identify likely channel funding transactions and cluster activity around Lightning nodes. The loop-out disrupts the direct UTXO link, but if your node’s on-chain wallet is already associated with your identity, the channel open itself carries that forward.

Run your node over Tor. Without Tor, your node’s IP address is publicly associated with your node ID. This is an orthogonal leak but a significant one.

Just a small recap

Lightning channels are not a privacy silver bullet, but they are a meaningful tool when used correctly. The combination of:

• Explicit UTXO selection (--utxo + --fundmax) to control which coin history enters a channel,

• Private channels (--private) to keep your peer relationships off the public graph,

• Loop-out via Loop or Boltz to exit the Lightning layer at a fresh on-chain address,

• Running over Tor to prevent IP-to-identity correlation,

...represents a practical, non-custodial privacy stack available to anyone running LND today.

It requires deliberate effort. It is not zero-risk. But it is real, it works, and it does not require trusting a third party with your funds.

If you want to go deeper on Lightning node setup, privacy practices, or hosting your own node on a security enhanced VPS with Tor pre-configured, check out denali.pro — we run production Lightning infrastructure and can help you get it right from the start.

The idea

Full-disk encryption is a good baseline. But it only protects you when your machine is off.

Once system is running and you’re logged in, your entire filesystem is decrypted and accessible — to you, to any process running under your user, and to anyone who gets a shell on your system. If your session is open, a stolen laptop, a rogue script, or a compromised application can read everything.

That’s where file-based encryption fills the gap.

gocryptfs is a FUSE-mounted, file-level encryption program. Because it encrypts at the file level rather than the entire disk, your files exist as individual encrypted objects on disk — and only become readable when you explicitly mount the encrypted directory with your password. When you’re done working, you unmount it. The data goes back to being unreadable noise.

The underlying cryptography is solid: AES-GCM for file contents, EME wide-block encryption for file names, and scrypt for password hashing. It was inspired by the older EncFS project, and was specifically designed to fix EncFS’s know n security weaknesses.

The practical upside is that gocryptfs is fast, lightweight, well-documented, and available in most major Linux distribution repositories. It doesn’t require root to mount. It works transparently with your existing tools — your text editor, your file manager, your scripts. You don’t change your workflow; you just add a lock to the things that actually need one.

In this guide, we’ll walk through installing gocryptfs, creating an encrypted vault, mounting and unmounting it, and a few best practices to avoid locking yourself out of your own data.

Installation

Ok now we are confident, we go on with installation and configuration

massmux@penguin:~$ sudo apt install gocryptfs

Now, let’s create our first encrypted gocrypt folder

massmux@penguin:~$ mkdir secret-folder
massmux@penguin:~$ gocryptfs --init secret-folder
Choose a password for protecting your files.
Password:
Repeat: 

Your master key is:
    8f68fc74-9e35626d-36923ce7-9c7adb42-
    31d456a8-90e4367e-d4dcfd2e-067c0ced

The masterkey here is very important: if you forget your password, the masterkey is the only way to recover your folder’s contents. So keep it in a secure place.

Now you can mount, for example on open-folder/ . So what happens? gocryptfs decrypts the encrypted folder and mounts it to open-folder/ where you can freely work in plain.

massmux@penguin:~$ mkdir open-folder
massmux@penguin:~$ gocryptfs secret-folder/ open-folder
Password: 
Decrypting master key
DetectQuirks: Btrfs detected, forcing -noprealloc. See https://github.com/rfjakob/gocryptfs/issues/395 for why.
Filesystem mounted and ready.

We can see that the encrypted folder is uncrypted and mounted

massmux@penguin:~$ df -m
Filesystem                  1M-blocks  Used Available Use% Mounted on
/dev/vdc                        20480  2392     17690  12% /
none                                1     1         1   1% /dev
/dev/vdc                        20480  2392     17690  12% /dev/kvm
tmpfs                               1     0         1   0% /dev/lxd
run                              3236     1      3236   1% /dev/.cros_milestone
9p                               3860     2      3859   1% /mnt/chromeos
tmpfs                            3236     0      3236   0% /mnt/external
tmpfs                               1     0         1   0% /dev/.lxd-mounts
devtmpfs                         3235     0      3235   0% /dev/tty
tmpfs                            3236     0      3236   0% /dev/shm
tmpfs                            1295     1      1295   1% /run
tmpfs                               5     0         5   0% /run/lock
tmpfs                               4     0         4   0% /sys/fs/cgroup
tmpfs                             648     1       648   1% /run/user/1000
/home/massmux/secret-folder     20480  2392     17690  12% /home/massmux/open-folder

When we are ok with our work we can unmount the folder.

massmux@penguin:~$ umount  /home/massmux/open-folder 

And now you can check if all is ok

massmux@penguin:~$ umount  /home/massmux/open-folder 
massmux@penguin:~$ ls open-folder/
massmux@penguin:~$ ls secret-folder/
Fes37GGPQvKs0h4H1AIlBILPWErpmm-Pn9hJuzba4B8  gocryptfs.conf  gocryptfs.diriv  K6t_24a34oeArDCGYjCdPKLAAXm9J0s4pXnRMRTcOf0

As you can see open-folder/ (as it was just a mount point) is empty, while the secret-folder is populated with encrypted files as you expected. If you want, you can sync the encrypted folder to a cloud without risking anything.

Follow me on youtube, instagram, tiktok, X, nostr for more value added contents for free.

In the world of decentralized and open finance created by Bitcoin, the security of the underlying operating system is not a luxury—it is a requirement. Running Bitcoin lightning nodes, payment infrastructures, or web applications demands a platform that is both replicable and resilient. By using an automated Ansible profile to deploy a hardened, Docker-centered Debian environment, administrators can ensure their infrastructure is built on a “secure-by-default” layer that eliminates human error and configuration drift. We need more Lightning liquidity, more nodes and more Bitcoin related transactions (layer1 and superior layers).

The Critical need of a Hardened OS and VPS for Lightning Infrastructure

Operating a Lightning Network Daemon (LND) is not merely about running software; it is about managing a 24/7 financial router that requires absolute precision and high availability. To achieve this, the underlying operating system (OS) and the Virtual Private Server (VPS) must be configured for maximum security, efficiency, and network stability.

1. Precision Timing and System Reliability

A Lightning node must maintain an accurate system clock to stay synchronized with the network state and validate transactions effectively. The provided automation profile ensures this by installing systemd-timesyncd and forcing NTP time synchronization. On a VPS, which is designed for high uptime, this ensures the node never drifts out of sync with the blockchain or with gossip. Furthermore, the use of a swap file (recommended at 2GB or more) with a low “swappiness” value (e.g., 10) prevents the OS from crashing under sudden memory pressure, ensuring the node remains responsive even when system resources are tight.

2. Hardening the VPS Frontier

Because a VPS is exposed to the public internet, it is a constant target for unauthorized access. A secure OS configuration is the first line of defence for your digital assets.

3. Meeting High-Performance Network Demands

The Lightning Network requires a reliable, high-bandwidth connection to handle the constant flow of gossip messages and payment routing. A VPS provides the static IP address and the 100 Mbps (or higher) internet connection necessary for a stable node.

To handle this traffic efficiently, the OS must reside on high-performance hardware. While the minimum requirement is a 1 GHz CPU and 2 GB of RAM, the recommended specification for a professional node is a quad-core processor and at least 4 GB of RAM.

4. Replicability through Containerization

By deploying these requirements within a Docker-centered environment, the node benefits from a standardised layer that is decoupled from the underlying host OS. This ensures that the complex dependencies of Bitcoin Core and LND are isolated, making the environment replicable and easy to migrate across different VPS providers without compromising the security profile.

The Power of a Predetermined Profile

The mentioned goals may be achieved by Ansible playbooks using a specified profile to create a standard environment. Instead of manual configuration, the script automatically detects the specific distribution and codename of the system to ensure the correct repository variables are applied. This level of automation ensures that every server—whether it is a local node or a cloud-based payment gateway—is identical, providing the standardness required for professional-grade Bitcoin operations.

Hardening the Entry Point

Security in this profile is established at the lowest levels of the system:

• SSH Hardening: The configuration proactively secures remote access by disabling password authentication and enforcing key-based access only. It further restricts security risks by limiting MaxAuthTries to two and disabling X11Forwarding.

• Firewall Protection: The ufw (Uncomplicated Firewall) is automatically enabled and configured to allow only essential traffic (Port 22), creating a protective perimeter around the Docker environment from the moment of deployment.

• Privilege Management: Rather than operating as root, the profile creates a dedicated dev user with specific Docker permissions and migrates SSH keys from the root account to ensure a secure, non-root workflow.

Docker: The Standard for Bitcoin Applications

A Docker-centered environment is vital for the Bitcoin ecosystem because it provides a consistent runtime for complex applications. The playbook installs the full Docker suite, including docker-compose-plugin and containerd.io, to facilitate the deployment of containerized services.

This containerization is essential for:

1. Replicability: Ensuring that a Lightning Network node runs exactly the same way in a test environment as it does in production.

2. Isolation: Keeping payment processing logic separate from other web applications or system services.

3. Ease of Updates: Allowing for rapid deployment of Lightning implementation and all the added software updates with minimal downtime.

System Reliability and Precision

Beyond security, the profile optimizes the system for the high-uptime requirements of financial infrastructure. It establishes a swap file with specific “swappiness” values to manage memory pressure gracefully. Most importantly for payment applications involving Bitcoin, it configures NTP time synchronization via systemd-timesyncd, ensuring the system clock is always accurate—a critical factor for valid block propagation and lightning channel state management.

Conclusion

By moving away from manual setups and adopting a hardened, automated profile, operators can deploy Bitcoin infrastructure that is secure, standard, and ready for the demands of the modern web. This profile-driven approach ensures that the layer beneath your applications is just as robust as the decentralized protocols running on top of it.

I felt the need to express my opinion and also cite examples and explanations by Jack Mallers (thank you for your contributions to the freedom), which I fully agree with. I am trying to explain how the modern world is taking time away from people and what Bitcoin means in this context.

Across modern societies, a peculiar paradox has emerged: despite unprecedented technological advancement and productivity gains, the average person finds basic life milestones—homeownership, financial security, family formation—increasingly unattainable. This phenomenon transcends individual circumstances or temporary economic downturns. Instead, it represents a fundamental breakdown in how we store and transfer value across time.

Reconceptualizing Money: The Battery Analogy

At its essence, money serves as a technology for storing human effort. When you spend eight hours building furniture, treating patients, or writing code, you’re converting a non-renewable resource—your finite time on Earth—into something that should retain that value. Think of money as a battery: it’s meant to capture the energy you’ve expended so you can discharge it later to acquire goods or services created by others’ time and effort.

This abstraction—transforming immediate labor into storable value—represents one of humanity’s most crucial innovations. It enables the specialization that defines modern civilization. A surgeon needn’t personally grow food, construct shelter, or manufacture tools. Instead, she can focus entirely on medical expertise, storing the value of her specialized work in a medium that others accept in exchange for their own specialized contributions.

But what happens when the battery itself is fundamentally flawed? What if the container holding your life’s work develops systematic leaks?

The Historical Search for Non-Perishable Value

Throughout history, humans have experimented with various vessels for storing economic energy. Early agricultural societies faced immediate challenges: grain spoils, livestock requires continuous care, and physical commodities are cumbersome to transport. Imagine trying to save a decade of labor in the form of wheat. Beyond the logistical nightmare of storage, you’d watch your accumulated wealth literally rot before your eyes.

This practical problem drove the evolution toward more durable stores of value. Precious metals—particularly gold—emerged as a superior solution because of their chemical stability and relative scarcity. Gold doesn’t oxidize, doesn’t decay, and historically couldn’t be arbitrarily multiplied. For centuries, these properties made gold humanity’s best approximation of a “non-leaky battery.”

Yet even gold-backed systems contained inherent vulnerabilities. Physical gold requires vault storage, creates security risks during transport, and ultimately depends on centralized institutions to guarantee its authenticity and backing. More fundamentally, gold supplies can still expand through mining, and governments can—and historically did—manipulate gold-backed currencies through various mechanisms including fractional reserve practices and outright confiscation.

The Invisible Tax: How Monetary Expansion Steals Time

Modern fiat currency systems have removed even the nominal constraints that physical commodities imposed. Central banks can now expand the money supply through purely digital means, without any physical or chemical limitations. While proponents frame this as necessary economic flexibility, the mathematical reality is far more sobering.

When a central bank creates new currency units, it doesn’t create new value—it divides existing value into more pieces.

If you’ve stored your labor in a currency whose supply then doubles, the purchasing power of your savings is mathematically diluted. The month you spent working last year now buys only half of what it should have.

This process operates as a hidden confiscation. Traditional taxation is explicit: you receive a paycheck, see the deductions, and understand precisely how much the state has claimed. Currency debasement is taxation by stealth. The number in your bank account remains unchanged, creating an illusion of stability, while the actual value—the hours of your life that number represents—quietly evaporates.

Consider the philosophical implication: someone else is reaching backward through time, erasing a portion of work you’ve already completed. They’re retroactively reducing the value of past efforts you can never reclaim. Those hours of your finite existence are gone, and the compensation you received for them has been partially nullified by third-party decision-makers you never elected to control your stored labor.

The Mathematics of Scarcity and Meaning

There exists a profound connection between scarcity and value that extends beyond economics into existential philosophy. Humans derive meaning from their limited time on Earth precisely because it’s limited. If you knew with certainty you would live for ten thousand years, would you maintain the same urgency about your goals? Would today’s effort carry the same weight?

This principle applies equally to money. In a system where supply is theoretically infinite—where central authorities can create unlimited new units—the concept of saving becomes philosophically incoherent. You’re attempting to preserve value in a medium specifically designed to lose value over time through intentional dilution.

A fixed money supply creates what economists call “hard money”—a currency that resists debasement. More importantly, it creates temporal coherence. When the total quantity of monetary units cannot expand, the purchasing power of each unit becomes a more stable representation of human effort across time. Your work today can be reliably stored for future deployment without systematic erosion.

This scarcity mirrors human mortality itself. We value our limited years because we know they’ll end. Similarly, money with a fixed supply respects the temporal limitations of human existence by providing a stable measurement of time already spent.

Empirical Evidence: The Post-1971 Economic Divergence

The year 1971 marked a pivotal transition in monetary history. In August of that year, the United States permanently severed the dollar’s final connection to gold, eliminating the last commodity restraint on currency creation. What followed provides a natural experiment in the consequences of purely fiat monetary systems.

Prior to this shift, housing costs relative to earnings remained relatively stable across generations. In 1970s Britain, a typical physician earning £4,000 annually faced housing prices around £15,000—representing approximately four years of focused saving. This ratio was consistent with historical norms across developed nations.

Fast forward to the present: that same proportion has collapsed catastrophically. Contemporary housing in equivalent areas might cost twenty to thirty times annual earnings, transforming what was once a medium-term goal into a multi-decade struggle that consumes the majority of a working lifespan.

This isn’t merely about housing. The phenomenon extends across fundamental life requirements: education, healthcare, childcare. Each has experienced costs rising far faster than general inflation, while wages—when measured in purchasing power rather than nominal numbers—have stagnated or declined for median workers.

The social consequences are measurable and disturbing. Marriage ages have shifted dramatically upward as young adults delay family formation until achieving financial stability that remains perpetually out of reach. Birth rates in developed nations have plummeted below replacement levels. Mental health indicators have deteriorated. Social cohesion has fractured as economic anxiety converts to political polarization.

These aren’t disconnected social problems—they’re symptoms of a monetary system that forces individuals to run faster and faster just to maintain the same relative position.

Why Previous Solutions Failed

Recognizing monetary debasement as a root cause, individuals have historically sought alternatives for preserving wealth. Real estate emerged as a popular choice based on the intuition that “they’re not making any more land.” Yet this strategy contains multiple flaws.

First, while land area is fixed, usable space is not. Construction technology allows ever-more-intensive development—building upward, excavating downward, and maximizing density. Second, real estate carries substantial costs: property taxes, maintenance, insurance. Third, it’s profoundly illiquid and location-dependent, making it unsuitable for day-to-day economic activity.

Gold has persisted as an alternative, but it faces its own limitations in modern contexts. Storage requires either personal security measures or trust in third-party custodians. Verification of authenticity and purity requires expertise or specialized equipment. Physical transfer is cumbersome for large values. Most critically, gold’s supply still expands through mining, and its geographic distribution makes it vulnerable to concentrated control.

Equities represent another common approach, but they introduce fundamental mismatches. Companies exist to generate profit through productive activity, not to serve as inert stores of value. Their valuation depends on countless operational factors beyond monetary policy. Using stocks as a savings vehicle conflates the distinct purposes of preserving value and accepting entrepreneurial risk.

Bitcoin: Engineered Finitude

Bitcoin represents a novel approach to the ancient problem of storing economic energy. Rather than relying on physical scarcity (gold) or geographic constraints (real estate), Bitcoin employs mathematical scarcity enforced by cryptographic consensus.

The protocol explicitly limits total supply to 21 million units, with a predictable issuance schedule that cannot be altered without the agreement of a distributed network of independent participants. No central authority can decide to create more bitcoin, regardless of political pressure or economic emergency.

This absolute scarcity is unprecedented. Even gold, humanity’s previous best attempt at hard money, lacks this property—gold supply continuously expands as mining technology improves and new deposits are discovered. Bitcoin’s supply curve is fixed by mathematics, not by the contingent physical properties of matter or the limited extent of planetary crust.

The implications extend beyond mere supply constraints. Because Bitcoin operates on a distributed ledger maintained by thousands of independent nodes, no single institution can confiscate it through legal decree, manipulate its supply through policy decisions, or restrict its transfer through capital controls. It exists as what computer scientists call “permissionless”—anyone can participate without requiring approval from gatekeepers.

The Psychological Shift: From Infinite Debt to Finite Value

Adopting a fixed-supply monetary system requires a profound psychological recalibration. Modern economic thought, trained on decades of fiat currency, assumes that money supply should expand to “stimulate” economic activity and that moderate inflation is not just acceptable but desirable.

This framework normalizes a specific temporal orientation: short-term thinking. If your savings lose purchasing power predictably, you’re incentivized to spend immediately rather than defer consumption. If debt can be inflated away, you’re encouraged to borrow against an uncertain future rather than build actual savings. The entire economic structure optimizes for immediate gratification at the expense of long-term planning.

A fixed money supply inverts these incentives. When the currency reliably maintains or increases purchasing power over time, saving becomes rational rather than self-defeating. Long-term planning becomes feasible because the foundation—the monetary unit itself—provides stable measurement across years or decades.

Economists call this shift “low time preference”—the ability to defer immediate gratification for greater future benefit. It’s the psychological foundation for all forms of civilizational advancement: education, infrastructure development, scientific research, environmental stewardship. These activities require sacrificing present resources for future returns, which only makes sense when the measurement unit itself is stable across that time horizon.

Addressing the Critics: Volatility and Adoption

Skeptics immediately raise Bitcoin’s notorious price volatility as evidence against its suitability as money. This criticism contains validity—Bitcoin’s exchange rate against fiat currencies has experienced dramatic fluctuations since its inception.

However, this objection conflates different phases of adoption. Bitcoin remains in what technologists call “price discovery”—the extended process by which a new asset finds its equilibrium value relative to existing alternatives. During this phase, volatility is not a flaw but an inevitable characteristic as market participants incrementally recognize its properties and adjust their holdings accordingly.

More fundamentally, the criticism accepts fiat currency as the stable reference point against which Bitcoin’s volatility is measured. This framing obscures a deeper question: volatile relative to what? Bitcoin’s supply is perfectly predictable—21 million units, released on a predetermined schedule. Fiat currencies, by contrast, have supplies that vary based on central bank policy decisions that respond to political pressures and changing economic theories.

From a long-term perspective, Bitcoin’s volatility represents growing pains during a transition from near-zero adoption to increasing recognition. The relevant question is not whether it experiences price fluctuations during this transition, but whether its fundamental properties—fixed supply, permissionless access, cryptographic security—provide superior value storage once adoption stabilizes.

The Moral Dimension: Time Theft as Violence

Viewing money as stored time transforms currency debasement from a technical policy debate into a moral crisis. When central authorities dilute the money supply, they’re not merely adjusting abstract economic variables—they’re confiscating the lived experience of millions of people.

Every hour you spent at work, every skill you developed through years of practice, every contribution you made to others’ welfare—all of this gets partially erased when the medium storing that effort is systematically debased. You cannot reclaim those hours. Your life has a finite duration, and the portion already expended is irrevocable.

This makes monetary debasement a form of violence—not physical violence, but a violation of your temporal autonomy. Someone else is deciding that your past efforts are worth less than you agreed to when you accepted payment in that currency. This happens without your consent, often without your awareness, and you have no practical recourse.

Bitcoin offers an alternative: a monetary system where no authority can reach back through time to erase your stored labor. The 21-million cap is not just a technical specification—it’s a commitment that your fraction of the total supply remains fixed, that the time you’ve stored cannot be diluted by policy decisions made in distant capitals.

Conclusion: Restoring Temporal Sovereignty

The case for Bitcoin ultimately rests not on its technological sophistication or its price performance, but on its alignment with fundamental properties of human existence. We live finite lives in which time flows in one direction. We exchange portions of our limited existence for resources that sustain us and allow us to pursue meaning.

Any money that fails to respect this temporal reality—that leaks value through intentional debasement—fundamentally disrespects human dignity. It treats people’s lives as raw material to be consumed by institutions pursuing short-term political expediency.

Bitcoin proposes a different arrangement: a monetary system that acknowledges scarcity as fundamental rather than treating it as a problem to overcome through printing. It offers humanity the possibility of storing time in a vessel that doesn’t leak, of building toward futures that remain coherent because the measurement unit itself remains stable.

The choice before us is not primarily technical or economic—it’s philosophical. Do we continue accepting a system that requires running faster each year just to stay in place? Or do we adopt a tool that respects the finite nature of human existence by providing a finite measure for human effort?

Your time is the only resource you truly possess. The question is whether you’ll store it in a container designed to preserve it, or continue watching it evaporate in a system built for its slow confiscation.

1. Introduction: The Ghost in the Machine

In recent months, a “quantum panic” has permeated the digital asset space, fueled by a relentless cycle of sensationalist media and “miraculous declarations” from Big Tech marketing departments. The narrative is as predictable as it is flawed: the imminent arrival of a universal quantum computer that will instantaneously dissolve Bitcoin’s cryptographic foundations. While researchers and certain “quantum-resistant” shitcoin promoters amplify this anxiety to capture headlines or market share, a scientifically grounded analysis reveals a different reality. To suggest Bitcoin is on the brink of collapse is to ignore the colossal engineering chasm that separates experimental noise-generators from the functional, error-corrected machines required to challenge the decentralized ledger.

2. Takeaway: “Quantum Supremacy” is Currently Just Expensive Noise

Google and IBM’s recent announcements regarding “Quantum Supremacy” are masterclasses in technical obfuscation. In these contexts, “supremacy” merely denotes a machine performing a specialized calculation that a classical computer cannot complete in a reasonable timeframe. It is not a synonym for utility. Google’s Willow processor, utilizing 105 qubits, achieved supremacy by generating a verifiable distribution of random noise. This is computationally impressive but cryptographically irrelevant; generating noise is worlds apart from the structured, high-precision mathematics required to reverse-engineer a private key.

“The fact that some very large companies that provide successful services are shooting out technical terms at random is nothing new. It is not something that should surprise us much; big tech often uses these miraculous declarations to sell cloud services or hype products that aren’t yet scientifically sustainable.”

For the strategist, these machines are currently nothing more than highly specialized, extraordinarily expensive lab experiments that lack the stability to perform a single meaningful operation on Bitcoin timechain.

3. Takeaway: The “Logical Qubit” Chasm and Gate Complexity

The distance between today’s hardware and a machine capable of cracking Bitcoin’s secp256k1 curve is not a gap—it is a canyon. While we currently track “Physical Qubits,” these are essentially useless due to decoherence. To achieve anything practical, the Threshold Theorem requires us to bundle thousands of physical qubits into a single “Logical Qubit” to facilitate error correction. The hardware requirements for a “one-day” crack of a Bitcoin key are staggering:

• Coherence Scale: We currently struggle to keep even a triad of three qubits in a state of coherence for more than 35 seconds.

• Physical Hardware: An attack requires an estimated 13 million physical qubits, whereas current state-of-the-art processors barely exceed 150.

• Gate Precision: We must achieve an astronomical increase in precision, moving from a current error rate of roughly 10^{-4} to 10^{-15}. This represents a million-fold improvement for which no viable engineering roadmap currently exists.

• Circuit Depth: A Shor’s algorithm attack on Bitcoin signatures requires approximately 5 trillion quantum gates (or 10^{10} Toffoli gates).

Managing that level of complexity while shielding the system from a single stray electromagnetic wave is an engineering feat currently comparable to stabilizing a house of cards in a hurricane.

4. Takeaway: The “Quantum Shield” of Hashing vs. Public Key Exposure

A critical distinction must be made between Bitcoin’s two primary cryptographic primitives: SHA-256 (mining) and ECDSA/Schnorr (signatures).

• SHA-256 (Mining Resilience): Using Grover’s algorithm, a quantum adversary achieves only a “quadratic speedup.” This is not a “break” of the system but a hardware shift. Much like the transition from GPUs to ASICs, quantum miners would simply force a hardware migration. Bitcoin’s difficulty adjustment would absorb the increased efficiency, maintaining the 10-minute block interval.

• ECDSA/Schnorr (The Signature Vulnerability): Shor’s algorithm represents an “exponential” threat to signatures. However, Bitcoin has a built-in defense: hashing. In modern P2PKH (Pay-to-PubKey-Hash) addresses, the public key is not revealed on the blockchain until a transaction is initiated. The address itself is a hash, which is quantum-resistant. Your signature only becomes vulnerable the moment you spend, creating a narrow window of attack that requires a machine to solve the discrete log problem faster than the next block is mined.

The real “Quantum Ghost” haunts Satoshi-era P2PK addresses, where the public key sits exposed on the ledger. For the rest of the network, the hashing of public keys provides a robust “quantum shield.”

5. Takeaway: The Economic “TradFi” Shield

If a nation-state ever possessed a machine with 10 billion Toffoli gates, Bitcoin would be a tertiary target at best. The global financial infrastructure rests on the same vulnerabilities but at a far more lucrative scale.

• Target Prioritization: An adversary would likely prioritize de-authenticating global satellite networks, bankrupting rival central banks, or compromising the 154 trillion** fixed-income and **128 trillion equity markets long before attempting to drain individual BTC wallets.

• The Roadmap: Traditional Finance (TradFi) will be forced to develop and deploy quantum-resistant standards (PQC) first. Bitcoin, as a smaller and more nimble target, will benefit from the battle-tested standards developed by central banks and global settlement rails.

6. Takeaway: The Migration Path and the “Bloat” Dilemma

A “soft fork” can introduce Post-Quantum Cryptography (PQC). A proposed Quantum-Resistant Address Migration Protocol (QRAMP) would involve a “burn and migrate” strategy, moving funds to new addresses using lattice-based or hash-based signatures. However, this introduces two major strategic hurdles:

1. The Lost Coin Problem: Satoshi-era or “lost” coins cannot sign the migration transaction. These funds would likely have to be declared unspendable after a hard deadline—a move that challenges the core principle of immutability.

2. Efficiency Degradation: PQC signatures like Dilithium or SPHINCS+ are significantly larger in byte size than current signatures.

“Many of these currently proposed quantum-resistant signatures are ‘untested.’ Some have been found to be insecure even against classical computers because they haven’t been ‘battle-tested’ in an adversarial environment for decades, as ECDSA has.”

7. Conclusion: A Century-Long Horizon

While the underlying physics of quantum computation is sound, the engineering reality is currently in a state of infancy. A practical, cost-effective quantum attack on Bitcoin remains more akin to “interstellar travel” or “low-cost nuclear fusion” than a near-term financial risk. We are likely decades, if not a century, away from the hardware stability required to execute Shor’s algorithm on a 256-bit key.

The ultimate question for the Bitcoin community is not whether the physics will work, but whether we are prepared for the social and technical trade-offs. Upgrading to quantum-resistant signatures means accepting larger transactions, slower validation, and the potential abandonment of “lost” coins. For the foreseeable future, however, the “Death of Bitcoin” remains a science fiction narrative designed to sell cloud services and clickbait, not a reflection of cryptographic reality. We leave such titles to shitty media and newspapers.

An outline of the most important and basic privacy precautions for keeping Bitcoin in self-custody. Self-custody is nowadays the only way to keep safe and secure Bitcoin. Centralized agencies, government and authorities are collecting information and preventing you to use your funds as you would need to. Using self-custody is the only way to protect yourself. Here some basic recap:

1. Never Reuse Addresses

• What: Use each Bitcoin address only once to receive funds

• Why: Address reuse is the single biggest privacy leak. It links multiple transactions together and reveals your balance

• How: Use wallets with built-in address generation (HD wallets). Generate a new address for every transaction

2. Run Your Own Full Node

• What: Download and verify the entire Bitcoin blockchain yourself

• Why: Third-party servers can track all your addresses and transactions. Your ISP can see you’re using Bitcoin

• How: Install Bitcoin Core or similar full node software

• Alternative: Use client-side block filtering (BIP 157/158) if full node isn’t feasible

3. Use Tor for All Bitcoin Network Activity

• What: Route all Bitcoin traffic through the Tor network

• Why: Hides your IP address from peers, ISPs, and transaction surveillance companies

• How: Configure your wallet/node to run over Tor, or use Tails OS for maximum privacy

• Always Broadcast on-chain transactions over Tor this is very important for preventing IP address correlation with transactions

4. Avoid KYC/AML

• What: Obtain Bitcoin without providing personal identification, documents and related information

• Why: KYC exchanges link your real identity to all your Bitcoin addresses and transactions and share these details to government agencies

• How: Use cash trades, Peer2Peer purchases, Bitcoin ATMs without KYC, earn Bitcoin, or mining

• Avoiding AML/KYC is the number 1 and most basic rule for an individual to improve their privacy”

5. Practice Coin Control

• What: Manually select which UTXOs (coins) to spend in each transaction

• Why: Prevents accidentally linking separate income sources or revealing your total balance

• How: Use wallets with coin control features

• Coin control as essential for preventing privacy leaks from transaction inputs

6. Avoid Change Outputs When Possible

• What: Structure transactions to spend entire UTXOs without creating change

• Why: Change addresses can be detected and linked to future transactions

• How: Use exact amounts, consolidate UTXOs, or accept slightly higher fees

• Try to avoid creating change addresses, for example when funding a lightning channel spend an entire UTXO into it without any change

7. Use Lightning Network for Payments

• What: Make off-chain Bitcoin payments through payment channels

• Why: Lightning transactions don’t appear on the blockchain and have much better privacy properties

• How: Set up a Lightning wallet connected to your full node

• Use Lightning Network as much as possible, it provides near-instant, private, cheap transactions. Better is using it with your own Lightning Node, where keys and channels are under your control.

8. Implement CoinJoin for On-Chain Privacy

• What: Collaborative transactions that mix your coins with others

• Why: Breaks the common-input-ownership heuristic that surveillance companies rely on

• How: Use JoinMarket, other solutions are nowadays less affordable

9. Minimize Information Disclosure

• What: Be cautious about sharing any Bitcoin-related information

• Why: Data fusion can combine small leaks into major privacy breaches

• How:

  • Don’t publish donation addresses publicly

  • Use email aliases

  • Avoid posting transaction IDs or addresses online

  • Be careful with delivery addresses when purchasing goods

• Be careful to reveal as little information as possible about yourself when transacting;

10. Secure Your Devices

• What: Protect your wallet files and transaction history from physical access

• Why: Digital forensics can extract all your Bitcoin activity from hard drives

• How:

  • Use encrypted wallets

  • Consider Tails OS or a debian with full OS encryption

  • Securely wipe old devices

  • Use hardware wallets for cold storage

• Never forget devices with clear data on it

11. Understand Your Threat Model

• What: Define who you’re protecting your privacy from

• Why: Privacy measures should match your specific risks and adversaries

• How: Consider whether you’re protecting against:

  • Casual observers

  • Transaction surveillance companies

  • Hackers and criminals

  • Government agencies

  • Family members or employers

• Think about what you’re hiding from, what is your threat model and what is your adversary. This is necessary to understand how to modulate trade off in your configuration.

12. Never Use Web Wallets or Custodial Services

• What: Avoid wallets where someone else controls your keys

• Why: These services see every transaction you make and can link your identity to your Bitcoin activity

• How: Use self-custody wallets like Electrum (with your own server) with keys managed with hardware wallets

• Never should not use web wallets, they are evil for privacy

Priority Ranking for Beginners

Must do immediately:

1. Never reuse addresses

2. Avoid KYC exchanges

3. Use Tor for transactions

Should implement soon: 4. Run your own full node 5. Use Lightning Network 6. Practice coin control, 7. Create your own Lightning node

Advanced but important: 8. Use CoinJoin 9. Avoid change outputs 10. Secure your devices properly. 11 Use Swap techniques for enhancing privacy.

If you looking for how to run your own Lightning node in an easy way, you may want to try Nimblenode which is a preconfigured LIT, Neutrino stack running on a VPS powered by denali.pro

Today my proposal is to discuss about a possible way to enhance privacy of your UTXOs through a technique involving Lightning Network. While Coinjoin remains without any doubt the most effective way to increase privacy if the anonset is enough, it’s good to test additional methods with different trade offs and results and analyze them. Here is one.

Description

Let's say I have a bitcoin UTXO in a wallet. I want to increase the privacy of this UTXO but without using coinjoin. This is the plan of this setup.
- Open a Phoenix wallet using Tor on a phone. it is installed from scratch and first connected with tor;
- Spend the entire UTXO (you have on a wallet where you own the keys) to a Phoenix onchain address (as provided by the new installed wallet). Phoenix will automatically open a channel to handle this operation;
- Once the channel is open (a channel to acinq), create 2 or more swaps on Boltz from Lightning (on phoenix) to On-chain and pay for them using Phoenix, resulting in the transaction being sent to another of unused onchain addresses you own, through the Boltz service. These swaps need to be executed from tor and without any timing and amount relationship correlations with the original UTXO.
The initial amount of the UTXO will be recovered into 2 or more swap operations on 2 or more on-chain destinations without correlation of time and amount.

Let’s analyze what we have

What you are doing:

• You are effectively breaking the chain of direct on-chain transactions;

• Using the Lightning Network as an intermediary creates an obfuscation by going on the layer 2 on the blockchain;

• Boltz swap adds an additional layer of separation;

• Using Tor with Phoenix helps protect privacy at the network level;

Issues and limitations:

Opening a Phoenix channel: When you send funds on-chain to Phoenix, the channel opening transaction is visible on the blockchain and directly links your initial UTXO to the Lightning channel address. This link is public and traceable. This channel will be open from the acinq LSP.

Temporal analysis: If transactions occur in quick succession (send to Phoenix → Boltz swap), temporal analysis could correlate the transactions, especially if the amounts are similar or identical. For this reason is strongly important to care this aspect.

Amounts: If the final amount is very close to the initial amount (minus fees), this can be an indicator of correlation. For this reason it is strongly important to break the initial amount to different LN/On-chain swaps in different time frames.

Phoenix as a centralized point: Acinq can theoretically see both the channel opening and the Lightning payments you make, so they could correlate the transactions. This is a point you have to consider. there is no trustless privacy in this part.

Boltz: Boltz, as a swap service, also sees the correlation between the incoming Lightning payment and the outgoing on-chain UTXO.

So what?

For an external observer of the blockchain who does not have access to Phoenix or Boltz data, the final funds have no direct on-chain link to the initial UTXO.

But there are tradeoffs. Privacy is not absolute (when ever it could be) because:

• The initial transaction to Phoenix is public

• You must trust that Phoenix and Boltz do not share/correlate data

• Time and amount analysis may suggest links, so you must be careful about time and amounts

  

Variations

We can do more effective variations to enhance the results. For example using on- demand lightning nodes (like nimblenode for example). Or using another layer on liquid swaps. We will go inside these techniques in the next articles and video contents. Stay tuned.

The role of OP_RETURN in Bitcoin has long been a point of debate among developers, miners, and businesses building on top of the protocol. Introduced as a standard mechanism for embedding small pieces of arbitrary data in a provably unspendable output, OP_RETURN has historically been constrained by strict relay policies, most notably the long-standing 80-byte limit enforced by Bitcoin Core. Up to version v29, Bitcoin Core maintained conservative restrictions to discourage on-chain data storage and preserve Bitcoin’s primary function as a decentralized monetary network.

With the release of Bitcoin Core v30, however, these rules have undergone their most significant shift in nearly a decade: the maximum permitted OP_RETURN payload has been dramatically increased, and transactions are now allowed to include multiple data-carrying outputs. These changes—still firmly within policy, not consensus—have opened the door to new use cases while simultaneously raising fresh concerns about bandwidth, storage costs, and the potential for blockchain bloat.

At the same time, Bitcoin Knots, an alternative Bitcoin implementation known for stricter validation rules and a more conservative stance on data-carrying transactions, continues to enforce tighter limits on OP_RETURN. This divergence between Bitcoin Core and Knots highlights a broader discussion within the Bitcoin ecosystem about data embedding, node resource requirements, miner incentives, and the trade-offs between flexibility and long-term sustainability.

This article examines how OP_RETURN worked up to Bitcoin Core v29, what has changed in v30, how Bitcoin Knots approaches data-carrying outputs, and the benefits and risks associated with each model. The goal is to provide a clear, factual, and balanced analysis for developers, node operators, and Bitcoin infrastructure providers evaluating the implications of these evolving policy choices.

Limits on op_return on both Bitcoin Core and Knots

The limit on the data carrier size, which relates to the op_return field in a transaction, is a key point of debate between Bitcoin Core and Bitcoin Knots implementations.

• Bitcoin Knots: The default setting for the data carrier size (or op_return limit) in the mempool is 42 bytes. This small amount of data allows people to embed certain information, such as a little bit of text, but not a huge amount. Knots offers additional configurability for the mempool, allowing users to change this setting. For instance, a user can set the limit to zero bytes to filter out all op_return transactions from their mempool.

• Bitcoin Core (v29): The previous implementation of Bitcoin Core (v29) has a default data carrier size of about 83 bytes.

What Bitcoin Core v30 actually changes about OP_RETURN

released october. The main changes:

1. -datacarriersize Default Raised to 100,000 Bytes

   • In v30, the default value for -datacarriersize is increased to 100,000 bytes.

   • According to the release notes, at that size “the maximum transaction size limit will be hit first,” meaning the OP_RETURN limit is no longer the bottleneck for “standardness” under many circumstances.

   • You can still override this to the previous behavior by setting -datacarriersize=83 to revert to the older limit

2. Multiple OP_RETURN Outputs Allowed

   • v30 allows multiple data-carrier (OP_RETURN) outputs in the same transaction (for relay and mining).

   • The -datacarriersize limit applies to the aggregate size of those OP_RETURN scriptPubKeys (i.e., it sums over all those outputs), not individually.

3. Policy Change, Not Consensus Change

   • These changes are policy-level, not consensus rules. That means they affect what a node will relay or accept into its mempool, not whether a block is valid.

   • Because of that, there’s no risk of a chain split solely due to this change

4. -datacarriersize Option Still Present

   • Even though the default is increased, the -datacarriersize configuration option remains available.

   • There was discussion of deprecation of -datacarriersize, but based on a late-stage change (PR #33453), the deprecation warning was removed.

   please checkout: https://github.com/bitcoin/bitcoin/issues/33595

   One of the many problems cited with this implementation is that it allows users to put in full JPEGs, small MP4s, audio, or illicit material into the blockchain. Historically, increasing this limit (as seen with BSV, which increased it to 100 kilobytes) resulted in child abuse imagery being embedded in that blockchain.

Differences between what happens to a transaction in mempool compared to what happens when a transaction is included in a block

The processing of a transaction differs significantly between the mempool (implementation layer) and inclusion in a block (consensus layer).

mempool is a temporary waiting space for transactions after they are broadcast to the network. It is the “waiting room before it gets put into a block”. They are governed by Mempool Policy. These are optional, subjective decisions and filters set by the individual node runner.

Consensus Rules. These are the base layer rules that all miners must accept as valid. A node uses its filters to decide if it will accept and relay a transaction to its peers. If a transaction violates the node’s policy (e.g., fee too low or op_return too large), it is rejected from that node’s mempool. A miner includes transactions from their mempool into a block they mine, and this block is added to the blockchain. Effect Policies result in different mempools across the network; no mempool looks exactly the same. Filtering can make it more difficult or expensive for transactions to get mined. Inclusion in a block is permanent.

If a transaction violates consensus rules, it does not get included in any mempool. If a transaction is consensus-valid but violates many mempool policies, a miner can still include it, bypassing the filtering mechanism of most nodes.

Mempool policy configuration is often described as self-defense of a node’s resources (disk, bandwidth, RAM) against spam. While filtering can make things more difficult and align incentives by increasing the economic friction for certain transactions, it cannot fully censor a consensus-valid transaction, as a miner can still choose to include it.

The mempool policy is like your individual email spam filter—you can set it strictly to protect your inbox (your resources), but that doesn’t stop the sender from mailing the same letter to someone else who uses a laxer filter.

What does Slipstream Mara do?

Slipstream is a product that facilitates submitting a transaction directly to a miner, completely bypassing the standard mempool policy filters of the network.

• Function: Users can use Slipstream to submit transactions, often those containing a really high op_return or large amounts of data.

• Provider: The service is provided by the massive mining pool Mara.

• Cost: Mara charges a massive premium to include transactions submitted via Slipstream, sometimes double the current mempool fee rate.

• Internal Filters: Despite enabling users to bypass network-wide mempool filters, Slipstream itself has terms and conditions that act as filters. Users are prohibited from using Slipstream to engage in activities that violate applicable laws, including participating in money laundering or uploading illegal content (such as illicit images). This policy is necessary because, without it, the ability to put massive op_returns into the blockchain could lead to the inclusion of illegal material.

Please let me know what is your opinion about what described in this article. What will be the future of Bitcoin and your position on how spam should be handled in this debate.

The Lightning Network uses source-based onion routing with the SPHINX protocol to enable private, censorship-resistant payments. The sender controls the entire routing path while intermediate nodes only see their immediate neighbors, ensuring transaction privacy across the network.

1. Introduction: What is Onion Routing?

Onion routing is a privacy-preserving technique where data is wrapped in multiple layers of encryption—like the layers of an onion. As the data passes through each node in the network, one layer is “peeled” off, revealing only the next destination.

Key Concept: The Lightning Network adapted this technique (originally from the Tor network) specifically for payment routing, using a variant called SPHINX.

Why Onion Routing for Lightning?

Traditional internet routing reveals the sender, receiver, and all intermediaries to each routing node. Lightning Network needed a protocol that:

• Hides payment source and destination

• Prevents censorship

• Maintains efficiency for financial transactions

• Protects against traffic analysis

2. Source-Based Routing: The Sender is in Control

2.1 Overview

In the Lightning Network, the sending node determines the complete payment path from source to destination. This is called source-based pathfinding.

Important: Unlike traditional internet routing where routers decide the path, in Lightning the sender has full control over:

• The exact route (sequence of nodes)

• Total number of hops

• Total fees paid

• Time-lock values (CLTV) at each hop

2.2 Path Discovery Process

The sender builds their routing strategy using three key data sources:

Network Topology (Channel Graph)

The sender maintains a local “map” of the Lightning Network by collecting:

• Node announcements: Public keys and addresses of Lightning nodes

• Channel announcements: Information about payment channels between nodes

• Channel updates: Routing policies (fees, timelocks) for each channel

This information is gathered through the gossip protocol—a peer-to-peer mechanism where nodes share network topology data.

Practical Example: Alice Pays Dave

Let’s follow a concrete example:

Scenario Setup:

• Alice wants to pay Dave 4,999,999 millisatoshis (≈ 5,000 sats) for a coffee

• Dave generates an invoice containing:

  • amount: 4,999,999 msats

  • payment_hash: Hash of a secret preimage

  • payee_pub_key: Dave’s public key

  • min_final_cltv_expiry_delta: 9 blocks (safety buffer)

Alice’s Network View:

Alice’s available paths to Dave:

Path 1: Alice → Bob → Charlie → Dave
  - Channel AB (fee: 200 base + 2000 ppm)
  - Channel BC (fee: 100 base + 1000 ppm)
  - Channel CD (fee: none, Dave is receiver)

Path 2: Alice → Eve → Charlie → Dave
  - Channel AE (fee: 300 base + 3000 ppm)
  - Channel EC (fee: 100 base + 1000 ppm)
  - Channel CD (fee: none, Dave is receiver)

Fee Calculation (Working Backwards)

Alice must calculate fees backwards from the destination:

Path 1 Calculation:

1. Dave receives: 4,999,999 msats

2. Charlie’s fee: 100 + (1000/1,000,000) × 4,999,999 = 5,100 msats

   • Charlie forwards: 5,005,099 msats

3. Bob’s fee: 200 + (2000/1,000,000) × 5,005,099 = 10,211 msats

   • Bob forwards: 5,015,310 msats

4. Total Alice pays: 5,015,310 msats (15,311 msats in fees)

Path 2 Calculation:

1. Dave receives: 4,999,999 msats

2. Charlie’s fee: 5,100 msats (same as above)

   • Charlie forwards: 5,005,099 msats

3. Eve’s fee: 300 + (3000/1,000,000) × 5,005,099 = 15,316 msats

   • Eve forwards: 5,020,415 msats

4. Total Alice pays: 5,020,415 msats (20,416 msats in fees)

Result: Alice selects Path 1 as it’s cheaper by 5,105 msats.

3. Constructing the Onion: Layer-by-Layer Encryption

3.1 The Onion Packet Structure

Once Alice has selected her path, she constructs the onion packet—a fixed-size encrypted message containing instructions for each hop.

Key Components:

• Version byte: Protocol version identifier

• Ephemeral public key: Used for shared secret derivation (different for each hop)

• Routing information: Encrypted payloads for each hop (1300 bytes fixed size)

• HMAC: Message authentication code for integrity verification

3.2 What Each Hop Needs to Know

Each intermediate node receives a hop payload containing:

Hop Payload Fields:
├── short_channel_id    # Which channel to forward on
├── amt_to_forward      # Amount to send (minus their fee)
├── outgoing_cltv_value # Time-lock value for next hop
└── hmac                # Authentication for next hop’s packet

Critical Privacy Feature: Each hop payload is encrypted specifically for that node—no other node can decrypt it.

3.3 Example: Building Alice’s Onion

Using our Alice → Bob → Charlie → Dave example:

Step 1: Dave’s Payload (Innermost Layer)

Payload for Dave:
- amt_to_forward: 4,999,999 msats
- outgoing_cltv_value: 1010 (current height 1001 + 9 block delta)
- Payment is final (no next hop)

Step 2: Wrap with Charlie’s Payload

Payload for Charlie:
- short_channel_id: CD (channel to Dave)
- amt_to_forward: 4,999,999 msats
- outgoing_cltv_value: 1010
- Encrypted payload for Dave (Charlie cannot read this)

Step 3: Wrap with Bob’s Payload

Payload for Bob:
- short_channel_id: BC (channel to Charlie)
- amt_to_forward: 5,005,099 msats
- outgoing_cltv_value: 1020 (1010 + Charlie’s 10 block delta)
- Encrypted payload for Charlie (Bob cannot read this)

Step 4: Final Onion Sent to Bob

Complete Onion Packet:
- Version: 0
- Ephemeral key: [Bob’s ephemeral public key]
- Routing info: [Bob’s payload | Encrypted(Charlie’s payload | Encrypted(Dave’s payload))]
- HMAC: [Authentication code]

3.4 The SPHINX Protocol: Advanced Encryption

The Lightning Network uses a modified SPHINX Mix Format with these features:

Shared Secret Derivation

• Each hop derives a shared secret using Elliptic Curve Diffie-Hellman (ECDH)

• The ephemeral key is randomized at each hop using a “blinding factor”

• This prevents linking packets across hops

Key Generation Formula

For hop i:
- Shared secret: ss[i] = ECDH(node_private_key[i], ephemeral_public_key[i])
- Blinding factor: b[i] = HMAC-SHA256(ss[i], “blinding”)
- Next ephemeral key: ephemeral_key[i+1] = ephemeral_key[i] * b[i]

Stream Cipher (ChaCha20)

Lightning uses ChaCha20 (not AES) for:

• Performance optimization

• Generating cipher streams to encrypt/decrypt payloads

• Maintaining fixed packet size

4. Intermediate Nodes: Limited Visibility by Design

4.1 What Each Hop Can See

When Bob (an intermediate node) receives the onion packet, he can ONLY:

1. Decrypt his own layer using his private key

2. Read his hop payload containing:

   • Which channel to forward on (short_channel_id)

   • How much to forward (amt_to_forward)

   • What timelock to use (outgoing_cltv_value)

3. See predecessor: He knows Alice sent the packet to him

4. See successor: He knows he should forward to Charlie

4.2 What Each Hop CANNOT See

Bob cannot determine:

• Who is the original sender (could be Alice, or she might be forwarding)

• Who is the final recipient (Dave? Or is Charlie forwarding further?)

• Total path length (how many hops total?)

• His position in the route (is he hop 1, 2, 3, or n?)

• Contents of other hops’ payloads

• The original payment amount

Critical Privacy Mechanism: The onion packet size remains constant at 1,300 bytes at every hop. After Bob removes his payload, the packet is padded with encrypted “junk data” to maintain the same size.

4.3 The Forwarding Process

Bob’s Actions:

1. Receive onion from Alice
2. Verify HMAC (check integrity)
3. Decrypt his layer using shared secret
4. Extract his hop payload:
   - Channel BC
   - Forward 5,005,099 msats
   - CLTV value 1020
5. Remove his payload from packet
6. Left-shift remaining data
7. Add random padding to maintain 1,300 bytes
8. Construct new onion with updated ephemeral key
9. Forward to Charlie via channel BC

Charlie’s Actions: Same process—Charlie:

• Decrypts his layer

• Extracts payload for channel CD

• Forwards to Dave

• Still doesn’t know this is the final hop

Dave’s Actions:

• Receives final payload

• Sees empty HMAC (indicating final destination)

• Verifies he has the preimage for payment_hash

• Claims the payment

4.4 Visual Analogy: Nested Envelopes

Think of the onion like nested, locked boxes:

┌─────────────────────────────────────┐
│  For Bob (locked with Bob’s key)    │
│  ┌───────────────────────────────┐  │
│  │ For Charlie (Charlie’s key)   │  │
│  │ ┌─────────────────────────┐   │  │
│  │ │ For Dave (Dave’s key)   │   │  │
│  │ │   [Payment: 5000 sats]  │   │  │
│  │ └─────────────────────────┘   │  │
│  └───────────────────────────────┘  │
└─────────────────────────────────────┘

• Bob opens his box, finds instructions and another locked box for Charlie

• Bob hands Charlie’s box to Charlie (can’t open it himself)

• Charlie opens his box, finds instructions and Dave’s box

• Dave opens his box and finds the payment

5. Privacy Guarantees

The combination of source routing and SPHINX onion routing provides these security properties:

5.1 Core Privacy Features

Feature Implementation Benefit Route Anonymity Sender determines path No intermediate node sees full route Source Hiding Ephemeral keys Sender’s identity hidden from intermediaries Destination Hiding Layered encryption Recipient identity hidden until final hop Position Hiding Fixed packet size Nodes can’t determine their position Path Length Hiding Constant 1,300 byte packets Total hop count is unknown Unlinkability Key blinding Packets can’t be correlated across hops

5.2 What the Network Sees

From a network observer’s perspective:

Observer sees: Encrypted packet traffic between nodes
Observer CANNOT determine:
  - Which packets belong to the same payment
  - Payment source
  - Payment destination
  - Payment route
  - Payment amount

5.3 Practical Privacy Considerations

Important Caveats:

• Timing attacks: Sophisticated attackers might correlate payments by timing

• Amount analysis: If amounts are unique, they could potentially be tracked

• Route selection: Using optimal (cheapest) routes reduces anonymity sets

• Network topology: Public channels reveal possible routes

Mitigation Strategies:

• Random route selection (sacrifice cost for privacy)

• Shadow routing (add dummy time delays)

• Multi-path payments (split across routes)

• Blinded paths (recipient hides last hops)

6. Technical Implementation Details

6.1 BOLT #4 Specification

The Lightning Network onion routing protocol is formally defined in BOLT #4: Onion Routing Protocol.

Key Technical Specifications:

• Packet size: 1,366 bytes total

  • 1 byte version

  • 33 bytes ephemeral public key (compressed)

  • 1,300 bytes routing information

  • 32 bytes HMAC

• Encryption: ChaCha20-Poly1305

• Shared secret: ECDH with secp256k1

• Hash function: SHA-256 for HMACs

6.2 Replay Protection

Problem: Attackers could potentially replay old onion packets to confuse nodes or steal funds.

Solution: Lightning implements multi-layered replay protection:

1. Ephemeral key log: Nodes maintain a log of used ephemeral keys and reject duplicates

2. Payment hash binding: HMAC includes payment_hash in associated data

3. HTLC timelock expiry: Once HTLCs expire, replay logs can be garbage collected

4. Economic disincentive: Reusing payment_hash lets nodes claim the full payment

6.3 Error Handling and Failure Messages

When a payment fails, error information must propagate back to the sender while maintaining privacy.

Error Return Process:

1. Node detecting error (e.g., Charlie):
   - Derives error key from shared secret
   - Creates error packet with failure reason
   - Encrypts error packet
   - Sends back to predecessor (Bob)

2. Each intermediate node (Bob):
   - Derives error key from their shared secret
   - Adds another layer of encryption
   - Forwards back to predecessor (Alice)

3. Sender (Alice):
   - Receives encrypted error packet
   - Peels layers using shared secrets
   - Identifies which hop failed
   - Sees failure reason (e.g., “insufficient balance”)

Common Error Types:

• temporary_channel_failure: Channel temporarily unavailable

• amount_below_minimum: Payment amount too small

• fee_insufficient: Routing fee too low

• incorrect_cltv_expiry: Time-lock value mismatch

• channel_disabled: Channel not accepting payments

6.4 Modifications from Original SPHINX

Lightning Network adapted the SPHINX protocol with these changes:

Change Reason MAC over entire header No need for SURB (Single-Use Reply Blocks) Removed end-to-end payload Reduce packet size, not needed for payments ChaCha20 instead of LIONESS Performance optimization Added per-hop payload Provide routing instructions (amount, channel, CLTV) Payment hash in HMAC Strengthen replay protection using HTLC properties

7. Complete Example Walkthrough

Let’s trace the complete journey of our example payment:

Phase 1: Invoice Generation

Dave creates invoice:
{
  “amount”: 4999999,
  “payment_hash”: “a1b2c3...”,
  “payee_pub_key”: “02dave...”,
  “min_final_cltv_expiry_delta”: 9
}

Phase 2: Path Finding

Alice builds channel graph from gossip:
- Discovers Path 1: Alice → Bob → Charlie → Dave (cheaper)
- Calculates fees: 15,311 msats
- Determines CLTV values at each hop

Phase 3: Onion Construction

Alice creates onion packet:
- Generates ephemeral keys for each hop
- Derives shared secrets
- Encrypts hop payloads (Dave → Charlie → Bob)
- Constructs 1,366 byte onion packet

Phase 4: Payment Initiation

Alice → Bob:
- update_add_htlc message
- payment_hash: a1b2c3...
- amount_msat: 5,015,310
- cltv_expiry: 1030
- onion_routing_packet: [1,366 byte onion]

Phase 5: Forwarding (Bob)

Bob receives packet:
1. Verifies HMAC
2. Derives shared secret using ephemeral key
3. Decrypts his layer
4. Reads: “Forward 5,005,099 on channel BC, CLTV 1020”
5. Verifies he can forward (sufficient balance, fee acceptable)
6. Peels his layer, maintains 1,300 bytes with padding
7. Generates new ephemeral key (blinded)
8. Sends update_add_htlc to Charlie

Phase 6: Forwarding (Charlie)

Charlie receives packet:
1. Verifies HMAC
2. Decrypts his layer
3. Reads: “Forward 4,999,999 on channel CD, CLTV 1010”
4. Verifies forwarding requirements
5. Peels layer, maintains packet size
6. Sends update_add_htlc to Dave

Phase 7: Payment Settlement

Dave receives packet:
1. Verifies HMAC
2. Decrypts final layer
3. Sees empty HMAC (indicates final destination)
4. Checks payment_hash matches invoice
5. Verifies amount: 4,999,999 msats
6. Reveals preimage: “preimage123...”
7. Updates commitment with Charlie (claims HTLC)

Payment propagates backwards:
Charlie ← preimage ← Dave (claims his HTLC from Bob)
Bob ← preimage ← Charlie (claims his HTLC from Alice)
Alice ← preimage ← Bob (payment complete!)

8. Advanced Topics

8.1 Trampoline Routing

For lightweight clients that can’t maintain full channel graph:

• Client connects to “trampoline node”

• Trampoline nodes handle pathfinding

• Creates nested onion routing (onion within onion)

8.2 Multi-Path Payments (MPP)

Split large payments across multiple routes:

• Sender creates multiple smaller payments

• Each follows different path

• Recipient atomically accepts/rejects all parts

• Improves payment reliability and privacy

8.3 Blinded Paths (BOLT #12)

Enhanced recipient privacy:

• Recipient creates “blinded route” for last few hops

• Sender doesn’t know recipient’s actual node

• Useful for receiver privacy and unannounced channels

9. Security Analysis

9.1 Attack Vectors and Mitigations

Timing Analysis:

• Attack: Correlate payment timing across hops

• Mitigation: Random delays, batching, trampoline routing

Balance Probing:

• Attack: Send fake payments to discover channel balances

• Mitigation: Return generic errors, rate limiting

Traffic Analysis:

• Attack: Monitor network traffic patterns

• Mitigation: Tor integration, decoy traffic, MPP

Route Fingerprinting:

• Attack: Unique route selections identify users

• Mitigation: Route randomization, shadow routing

9.2 Comparison with Tor

Aspect Tor Lightning Path Selection Random guards + middle + exit Source-based (sender chooses) Optimization Balanced load Cost-optimized (fees/latency) Anonymity Set Large (random selection) Smaller (deterministic routing) Performance Higher latency tolerated Low latency required Packet Format Original SPHINX Modified SPHINX

Key Difference: Lightning prioritizes performance and cost over maximum anonymity, trading off some privacy for payment efficiency.

10. Resources and Further Reading

Official Documentation

• BOLT #4: Onion Routing Protocol - Official specification

• lightning-onion Repository - Go implementation

Educational Resources

• Mastering the Lightning Network, Chapter 10 - Comprehensive book chapter

• Elle Mouton: Onion Routing Preliminaries - Excellent visual tutorial with diagrams

• Voltage Blog: What is Onion Routing - Beginner-friendly explanation

Academic Papers

• Danezis & Goldberg (2009): “Sphinx: A Compact and Provably Secure Mix Format” - Original SPHINX paper

• “How Lightning’s Routing Diminishes its Anonymity” - Analysis of privacy trade-offs

Network Visualization

• LnRouter Graph Visualization - Explore Lightning Network topology

• 1ML.com - Network statistics and node explorer

11. Glossary

Channel Graph: Local map of Lightning Network topology built from gossip protocol messages

CLTV (CheckLockTimeVerify): Time-lock mechanism ensuring HTLCs expire at specific block heights

Ephemeral Key: Temporary public key used once per payment to derive shared secrets

Gossip Protocol: P2P mechanism for nodes to share network topology information

Hop Payload: Encrypted instructions for each intermediate node in payment route

HTLC (Hash Time-Locked Contract): Conditional payment that requires cryptographic proof (preimage)

Onion Packet: Fixed-size encrypted message containing routing instructions for all hops

Payment Hash: SHA-256 hash of preimage used in HTLC contracts

Preimage: Secret value whose hash is in the invoice; revealing it claims the payment

Shared Secret: Secret derived through ECDH, known only to sender and specific hop

Source Routing: Routing paradigm where sender determines complete path (vs. router-determined)

SPHINX: Cryptographic packet format providing layered encryption and unlinkability

Pros/Cons

Lightning Network’s onion routing represents a sophisticated balance between:

• Privacy: Hiding sender, receiver, and route information

• Performance: Enabling instant, low-latency payments

• Efficiency: Optimizing for low fees and high success rates

• Decentralization: Avoiding trusted third parties

The SPHINX-based implementation ensures that no single intermediary node can:

• Determine the payment source or destination

• Learn their position in the route

• Discover the total path length

• Link packets belonging to the same payment

This privacy-preserving architecture, combined with source-based routing, creates a censorship-resistant payment network where users maintain control over their transaction paths while protecting their financial privacy.

I try to explain why I believe Bitcoin will become the global reserve asset and an ethical method to pay and being paid, preserving all the value inside the real economy without the need of banks.

Bitcoin’s Role and Macroeconomic Shift

Bitcoin doesn’t need governments institutions or even you. But you, institutions and governments all need Bitcoin. Bitcoin is an unstoppable technology destined to push humanity forward. People own Bitcoin because it is apolitical and has succeeded regardless of government actions, not because of what any political leader says or tweets. Government actions or words are just noise for Bitcoin.

The current macroeconomic situation can be seen as the most fascinating time of our era and a monetary regime change. I am quite sure that US dollar will not remain as the world reserve currency. If the dollar continues on its path, debt will explode, and Bitcoin will become the global reserve currency.

As the world reserve currency issuer, the United States has the most debt and runs the largest fiscal deficits, suggesting it will inevitably develop an interest in transitioning away from that status and stockpiling a world reserve asset.

Institutional Demand and the End of Traditional Portfolios

There is a significant institutional demand for Bitcoin and we can see it every day.

People having wealth to store, are now seeking real returns, real balance sheets, and real growth, leading them to Bitcoin, which is compounding at 60% a year. Adopting Bitcoin requires humbling oneself and realizing that “this thing is bigger than all of us”. Bitcoin is the safest place to store one’s work because it is bound to the physical realities of the universe and is impossible to produce more of, making it the hardest money ever conceived. About these assumptions, please give a look to my previous contents about time and energy aspects of Bitcoin.

Bitcoin has officially entered its hyper adoption phase. This phase is characterized by scarcity becoming the driver of value, leading to a potential supply-driven price breakout compared to US dollar.

Focus on Utility and the Hodler’s Dilemma

There is the “hodler’s dilemma”. This dilemma arises because Bitcoiners, who have amassed wealth in the scarce asset, still need liquidity for life expenses (like marriage, travel, or buying a house or car, etc) but do not want to sell their holdings.

On the other hand we need Bitcoin even to transact in day-to-day spending, in such a way that it may circulate in real economy, dragging away wealth from banking powers and give it to people who produce value inside the real economy.

The real economy without banks

Bitcoin, combined with the Lightning Network, is no longer just a store of value — it’s becoming a tool for everyday payments. Thanks to Lightning’s instant and low-cost transactions, people can now send and receive Bitcoin as easily as sending a message. This opens the door to an entirely new kind of economy — one that operates fully outside the traditional banking system.

In this emerging model, value flows directly between individuals and businesses. A freelancer can receive Bitcoin instantly for their work. A café can accept Lightning payments for a coffee without paying fees to payment processors or banks. Merchants and consumers transact peer-to-peer, in real time, with global reach and without permission from any centralized entity.

Such an economy keeps wealth circulating within the real economy — the network of people actually creating value — instead of being locked into financial intermediaries that extract fees and inflate the money supply. As more people start accepting Bitcoin for their products and services, money returns to its natural role: a medium of exchange directly connecting producers and consumers.

Bitcoin with Lightning is not just a payment innovation; it’s a path toward economic sovereignty. It empowers individuals to earn, spend, and save in a system built on open protocols, not banks — where value flows freely and wealth stays in the hands of those who create it.

The way people acquire Bitcoin is at a crossroads. As regulatory frameworks tighten around centralized exchanges and privacy concerns mount, many users are reevaluating how they convert their fiat currency into cryptocurrency. Understanding the trade-offs between centralized exchanges (CEXs) and peer-to-peer (P2P) platforms has never been more critical.

The Centralized Exchange Model

Centralized exchanges like Coinbase, Kraken, and Binance have dominated the Bitcoin onboarding experience for years. They offer a familiar, user-friendly gateway that mirrors traditional financial services. You create an account, verify your identity, deposit fiat currency, and purchase Bitcoin with a few clicks and very low fees but you have a great penetration in your private sphere.

Advantages of CEXs:

The primary appeal of centralized exchanges lies in their convenience and liquidity. These platforms provide instant execution of trades at market prices, with deep order books ensuring you can buy or sell significant amounts without dramatic price slippage. Customer support teams stand ready to assist with technical issues, and the interface resembles online banking—familiar territory for newcomers to cryptocurrency.

Security infrastructure at major exchanges has matured considerably. Most employ cold storage for the majority of user funds, maintaining only a small percentage in hot wallets for immediate withdrawals. Insurance policies, though limited, provide some protection against platform breaches. The regulated nature of these entities means they must meet certain standards and undergo periodic audits.

Disadvantages of CEXs:

The convenience comes at a steep price: your privacy. Know Your Customer (KYC) requirements mean surrendering extensive personal information including government-issued identification, proof of address, facial recognition data, and increasingly detailed financial history. This creates a comprehensive dossier linking your real-world identity to every Bitcoin transaction originating from the exchange.

This data aggregation presents multiple risks. Exchanges become honeypots for

hackers seeking not just cryptocurrency but identity information. Data breaches have exposed millions of users’ personal details. Beyond security concerns, this information flows to tax authorities, law enforcement, and potentially other government agencies depending on jurisdiction.

Centralized exchanges also introduce custodial risk. Despite improved security measures, the fundamental structure means you don’t control your Bitcoin until you withdraw it. Platform failures, regulatory seizures, or simple technical glitches can lock you out of your funds. The collapse of major exchanges throughout Bitcoin’s history—from Mt. Gox to FTX—demonstrates that even prominent platforms can fail catastrophically.

The Peer-to-Peer Alternative

Peer-to-peer platforms like Bisq, HodlHodl, and the new BitcoinVoucherBot (Peer2Peer edition) take a fundamentally different approach. These platforms facilitate direct trades between individuals, removing the intermediary that holds your funds and personal information so removing any custodial risk.

Advantages of P2P Platforms:

Privacy stands as the paramount benefit. Many P2P platforms require minimal or no KYC, allowing users to acquire Bitcoin without creating a permanent record linking their identity to their cryptocurrency holdings. Bisq, for example, operates as fully decentralized software with no company controlling user data. BitcoinVoucherBot uses the Lightning Network and Tor to provide strong privacy guarantees.

The decentralized architecture eliminates single points of failure. No company holds a database of user information to be hacked or subpoenaed. No central authority can freeze your account or prevent you from trading. This resilience against both technical failures and regulatory pressure makes P2P platforms attractive for users prioritizing sovereignty over convenience.

P2P trading also offers flexibility in payment methods. While centralized exchanges typically support only bank transfers and major payment processors, P2P markets accommodate cash transactions, gift cards, payment apps, and various local payment systems. This diversity can be crucial in regions with limited banking infrastructure or capital controls.

Disadvantages of P2P Platforms:

The decentralized model introduces complexity and inconvenience. Trades take longer—sometimes hours rather than seconds. You must evaluate counterparty reputation, communicate directly with trading partners, and navigate escrow mechanisms. The learning curve is steeper, and mistakes can be costly.

Liquidity represents another challenge. P2P markets have thinner order books, meaning you may not find buyers or sellers at your desired price point, especially for larger amounts. Price spreads are wider, effectively increasing the cost of acquisition. In some jurisdictions or for certain payment methods, you might pay a premium of 5-10% above exchange rates.

Some payment methods are reversible, creating chargeback risks for sellers that translate into higher prices or stricter trading conditions for buyers.

The Regulatory Tightening of 2025-2026

The regulatory landscape governing Bitcoin exchanges is undergoing dramatic transformation. Understanding these changes is essential for anyone looking to acquire Bitcoin in the coming years.

Enhanced KYC and Surveillance Requirements:

The European Union’s Markets in Crypto-Assets Regulation (MiCA), which came into full effect in 2024, is setting global precedents. Under MiCA, exchanges must collect and verify increasingly detailed customer information, including source of funds documentation for transactions above relatively low thresholds. This means explaining not just who you are, but where your money came from and potentially what you intend to do with your Bitcoin.

The Financial Action Task Force (FATF) “travel rule” is being implemented more stringently across jurisdictions. This regulation requires exchanges to collect and share personal information about both senders and recipients for cryptocurrency transfers above certain amounts. When you withdraw Bitcoin from an exchange to your personal wallet, the exchange must now collect information about that destination address and potentially report it to authorities.

In the United States, proposed regulations would treat certain cryptocurrency software providers and wallet services as money transmitters, extending KYC requirements far beyond traditional exchanges. The Infrastructure Investment and Jobs Act’s expanded reporting requirements for cryptocurrency brokers, taking effect in phases through 2026, will create comprehensive transaction reporting comparable to traditional securities.

Transaction Monitoring and Reporting:

Exchanges are implementing increasingly sophisticated blockchain analytics tools that monitor withdrawal addresses for connections to sanctioned entities, mixing services, or other “suspicious” activity. Addresses flagged by these systems may result in account freezes, withdrawal limitations, or mandatory additional verification procedures.

Tax reporting requirements are expanding globally. Exchanges must report not just annual summaries but detailed transaction-level data to tax authorities. This creates comprehensive government visibility into cryptocurrency holdings and movements for anyone using centralized platforms.

Impact on Privacy:

These regulations fundamentally undermine Bitcoin’s potential for financial privacy. Every Bitcoin purchased through a KYC exchange is now linked to your identity in multiple government and corporate databases. Blockchain analysis firms can trace these coins through subsequent transactions, potentially identifying your spending patterns, business relationships, and wealth accumulation.

The privacy implications extend beyond individual transactions. Aggregated data about cryptocurrency users, their geographic distribution, political affiliations, and financial behaviors becomes available to governments and potentially leaked to bad actors. This surveillance infrastructure, once established for Bitcoin, sets precedents for monitoring all financial activity.

Impact on Security:

Increased regulation will decrease rather than enhance security for users. As exchanges accumulate more detailed personal and financial data, they become more attractive targets for sophisticated hackers and state-level actors. The correlation between identity information and cryptocurrency holdings creates specific kidnapping and extortion risks for visible Bitcoin holders.

Regulatory complexity also concentrates the market among large, well-capitalized exchanges that can afford compliance costs. This concentration increases systemic risk—fewer platforms holding more user funds and data. When large centralized exchanges fail, whether through hacks, fraud, or regulatory action, the damage is correspondingly greater.

Enhanced regulatory scrutiny can also paralyze platforms during crises. Exchanges facing regulatory uncertainty may freeze withdrawals or impose arbitrary restrictions, trapping user funds during the exact moments when access is most critical.

Making the Choice in the New Regulatory Environment

The tightening regulatory environment makes the choice between centralized exchanges and peer-to-peer platforms more consequential than ever. Your decision should reflect your priorities, technical capabilities, and risk tolerance.

For complete newcomers with limited technical knowledge, regulated exchanges still offer the easiest entry point despite privacy concerns. If you plan to purchase small amounts for short-term speculation or to experiment with cryptocurrency, the convenience may outweigh privacy considerations. Those comfortable with the traditional financial system and unconcerned about transaction surveillance may find the familiar interface and customer support valuable.

Additionally, if you need to convert large amounts of fiat to Bitcoin quickly and at tight spreads, centralized exchanges provide liquidity that P2P markets struggle to match.

The Growing Case for P2P:

As regulations tighten, the advantages of P2P platforms become more compelling. For users prioritizing financial privacy, P2P represents the only realistic option for acquiring Bitcoin without creating permanent identity linkages. This privacy isn’t merely about hiding illicit activity—it’s about maintaining the financial sovereignty and freedom from surveillance that Bitcoin was designed to enable.

Long-term Bitcoin holders (often called HODLers) should seriously consider P2P acquisition. The Bitcoin you purchase today without KYC retains greater fungibility and privacy for future transactions. As blockchain analysis becomes more sophisticated, the premium for “clean” Bitcoin without exchange history may increase.

Users in jurisdictions with capital controls, unstable currencies, or authoritarian governments find P2P platforms essential. Europe is becoming a stricter and more authoritative juristiction as well. When official channels close or become prohibitively restricted, peer-to-peer markets provide crucial financial access. The decentralized architecture offers resilience against both technical failures and political interference.

Practical Considerations

Security Best Practices:

Regardless of which acquisition method you choose, never leave significant amounts of Bitcoin on any platform—centralized or peer-to-peer. Withdraw to a personal wallet where you control the private keys. Hardware wallets provide the strongest security for long-term storage.

For P2P trading, start with small transactions to build reputation and learn the platform. Carefully verify counterparty credentials, use platform escrow systems, and prefer payment methods that offer you protection based on whether you’re buying or selling.

Staying Informed:

The regulatory environment continues evolving rapidly. Rules implemented in 2025 and 2026 may look different from what’s described here as jurisdictions learn from each other and the industry adapts. Stay informed about regulations in your specific jurisdiction and how they affect both centralized and decentralized platforms.

The path from fiat currency to Bitcoin is becoming increasingly surveilled and regulated. Centralized exchanges offer convenience and liquidity but at the cost of comprehensive identity disclosure and custodial risk. Peer-to-peer platforms preserve privacy and decentralization but require more effort and technical sophistication.

As regulatory frameworks tighten through 2025 and 2026, the privacy and security implications of how you acquire Bitcoin become more significant. The choice between centralized and peer-to-peer isn’t merely technical—it’s philosophical. It reflects your values regarding financial privacy, your trust in centralized institutions, and your willingness to trade convenience for sovereignty.

For those who believe in Bitcoin’s original vision of permissionless, censorship-resistant money, peer-to-peer acquisition aligns with those principles. For others prioritizing ease of use within the existing regulatory framework, centralized exchanges remain viable despite their trade-offs.

The important thing is making an informed choice. Understanding what you’re gaining and what you’re surrendering—in privacy, security, convenience, and cost—allows you to select the approach that best serves your needs in an increasingly complicated regulatory landscape. As Bitcoin matures and regulations evolve, the method you choose for converting fiat to Bitcoin may prove as important as the decision to acquire Bitcoin itself.

The possibility of having our digital communications sniffed and stored is a serious threat on our life. It is not just a leak of privacy but it is also a danger for our personal security and our family safety. We must be aware that everyone who may get our digital communication messages has an important way to attack us, even physically. So we must protect ourself and people living with us.

What is happening?

The digital landscape is increasingly under scrutiny, with proposals such as the European Parliament's 'Chat Control' law sparking significant debate over privacy and fundamental rights. This proposed regulation, aimed at combating online child sexual abuse material, has raised grave concerns about mass scanning of private communications, including those protected by encryption, thereby threatening to undermine the data security of citizens, businesses, and institutions. In this environment, peer-to-peer messaging platforms like Briar (and others) offer a robust model for resisting pervasive digital surveillance.

The Threat of 'Chat Control': A Blow to Privacy

The 'Chat Control' or CSAM regulation, as reviewed under the Danish Presidency, proposes a technical approach based on automated content analysis tools. Critics highlight that such tools often produce high rates of false positives, creating a risk of innocent users being wrongly incriminated.

More fundamentally, the proposal envisages a mandatory weakening of end-to-end encryption, which is a cornerstone of secure digital communication. This weakening would create security gaps exploitable by cybercriminals, rival states, and terrorist organisations, potentially harming the competitiveness of the digital economy.

The core questions raised by Members of the European Parliament include the regulation's compatibility with Article 7 of the Charter of Fundamental Rights, how it will ensure effective child protection without violating citizens' rights, and how it plans to prevent the negative impact on cybersecurity and economic competitiveness caused by weakened encryption.

Briar: A Decentralised Shield Against Surveillance

In stark contrast to central server-reliant messaging software that exposes messages and relationships to surveillance, Briar is designed from the ground up to resist surveillance and censorship. It operates as a messaging app for activists, journalists, and anyone needing a secure, easy, and robust communication method. But finally it will be useful for every citizen who cares their own privacy and security. Unlike traditional apps, Briar doesn’t rely on a central server; instead, messages are synchronised directly between users' devices. This decentralised design is key to its resilience against various forms of digital intrusion.

Here's how Briar directly counters the threats posed by proposals like 'Chat Control':

1. End-to-End Encryption as a Core Principle: While 'Chat Control' proposes weakening end-to-end encryption, Briar ensures that all communication between devices is encrypted end-to-end, protecting content from eavesdropping or tampering. This fundamental design choice safeguards the privacy and integrity of conversations.

2. Protection Against Metadata Surveillance: Briar actively combats metadata surveillance by using the Tor network when the Internet is available. This prevents eavesdroppers from learning which users are communicating with each other, thus protecting users and their relationships from surveillance. Each user’s contact list is also encrypted and stored only on their own device.

3. Resistance to Content Filtering and Takedown Orders: Briar's end-to-end encryption inherently prevents keyword filtering, a method often employed in mass surveillance proposals. Furthermore, due to its decentralised design, there are no central servers to block or attack, making it impervious to server-based takedown orders. Every user who subscribes to a forum keeps a copy of its content, eliminating any single point where a post can be deleted.

4. Resilience to Internet Blackouts and Denial of Service Attacks: Briar is engineered to keep information flowing even if the internet is down. It can synchronise messages directly via Bluetooth and Wi-Fi . This capability means it can operate even during Internet blackouts or if long-range communication channels are comprehensively monitored or blocked by an adversary. Its forums have no central server to attack, ensuring access to content even if users are offline.

5. Robust Threat Model: Briar's design is based on a threat model that assumes an adversary with extensive capabilities, including comprehensive monitoring, blocking, delaying, replaying, and modifying traffic on all long-range communication channels (internet, phone network). It's also designed to be resilient even with limited monitoring or blocking on short-range channels (Bluetooth, Wi-Fi). This explicit focus on adversarial conditions makes it a powerful tool for secure communication in challenging environments.

We can recap link this:

• Peer-to-peer encrypted messaging and forums

• Messages are stored securely on your device, not in the cloud

• Connect directly with nearby contacts, even without Internet

• Free and open source software

The Future of Secure Communication

Briar's long-term vision extends beyond messaging, aiming to support secure, distributed applications for crisis mapping and collaborative document editing. The ultimate goal is to enable individuals in any country to create safe spaces for debate, event planning, and organising social movements.

In an era where proposals like 'Chat Control' threaten to erode fundamental rights and compromise cybersecurity through mass scanning and weakened encryption, platforms like Briar stand as critical tools. By embracing decentralisation, strong encryption, and robust threat models, they offer a powerful counter-narrative, ensuring that secure, private digital communication remains a possibility for everyone.

We stand for free Palestine! ❤️

For many, including myself, the creation and printing of money represents a profound ethical problem that is becoming really unacceptable. This perspective posits that entities which monopolize, print, and allocate capital on behalf of others commit actually a moral violation. Such actions are seen to deplete the opportunities, time, and energy of future generations, leading to a level of indebtedness that is now impossible to overcome for western people. These behaviors concentrate power in the hands of a few persons, who are often corrupt, and encourage wars and oppression of people all over the world. In this article I am taking in consideration the ideas from Gigi and Jack Mallers who were extremely inspirational for me all along my path to Bitcoin.

So we must ask ourselves what Bitcoin really is and how we feel it is different from the traditional economy we have seen until now. What Bitcoin can do for the humanity and what we can do to raise awareness of Bitcoin among people.

In response to this perceived ethical dilemma exposed above, Bitcoin has emerged as something far beyond mere open source computer code or a digital asset. Instead, it is increasingly understood as a moral code. This redefinition positions Bitcoin as a fundamental philosophical framework for economic interaction. And we know that economic interactions are the foundation of our individual freedom and the free market.

The core tenets of Bitcoin's moral code are remarkably simple and direct and can be resumed like these:

• do not inflate

• do not confiscate

• do not counterfeit

This foundational ethical stance is what makes Bitcoin, for many, very ethical and moral. The underlying premise is that everyone operates under the same rules and has the same access to the system. Bitcoin is open to anyone and no one can be prevented from using it. The difference from the traditional economic system is obvious.

Ultimately, for me, Bitcoin is a moral idea and a philosophy. It is an idea expressed in open source and collaborative code that operates as a network that is realized as an asset (cit). This profound shift in understanding signifies that what has been learned in Bitcoin transcends technical specifications; it delves into the realm of ethical governance of monetary systems. It is an ethical revolution which is going to fix issues in the modern age.

Share

We want to run a Lightning node in the simplest way and with the minimum hardware requirements. There are a lot of solutions out there and you know that i am usual speaking about nodes and smart solutions to get into the Lightning world in a fast and easy way.

So today i am talking about the solution of LIT with neutrino built in. I specifically made a full setup that makes this configuration magic. Let’s see together.

Specifically, when running LiT, you can choose to run the bundled LND in "neutrino mode". This means that LiT, via its integrated LND instance, can utilise Neutrino as its backend. This configuration allows for a quick setup, as it avoids the need to run Bitcoin Core on your machine.

Install and run

Register a domain name and point the DNS A record to the VPS's public IP or you can use a CNAME of an existing domain. Don't start the procedure until the zone is propagated and you have a fully qualified domain name which A to your VPS

git clone https://github.com/massmux/nimblenode

• edit docker-compose.yml setting: 1) the UI password (at least 8 chars long), 2) your node's ALIAS, 3) your fully qualified hostname

• I have created full docker image ready to go. You can pull the image from dockerhub

• port 80 must be open on the host machine to allow letsencrypt automation on the selected domain

docker pull massmux/lit

• Run the container

cd nimblenode
docker-compose up -d

• Create the wallet. first usage

./scripts/create

You will be asked about the wallet encryption key and how to setup the seed phrase. Backup them all carefully offline. As you can see you own the seed and the encryption key.

• that's it

• after around 20 minutes, connect to the server with:

https://your-domain-name:8443

IMPORTANT: if you stop the docker container and restart you need to unlock your wallet with command

./scripts/unlock

Configuration files are kept on your node’s disk in the .lit/ directory. In that directory a lit configuration file is stored and can be customized.

The primary configuration parameter for LiT to use a built-in LND, which subsequently leverages Neutrino as its backend, is:

• lnd-mode=integrated

When litd (the Lightning Terminal daemon) is executed in this integrated mode, it bundles and runs LND directly within its process. In this setup, the integrated LND instance is configured to use the Neutrino backend. This is also referred to as running in "neutrino mode".

Maintenance

Just connect to your running container with

docker exec -ti lit bash

then you can access the lncli command as usual to manage your node from the command line. With lncli you can do whatever you want in terms of maintenance of your node, such as macaroons creation, channel opening and so on.

If you want to see logs, just move into the docker-compose directory and run the following command:

dev@lnbits00:~/smnode$ docker-compose logs -t -f --tail 300

Your logs page while running:

You can connect to the Lightning terminal through the pairing phrase and in that way you can manage your node without hassles.

What is Neutrino?

Neutrino is a lightweight Bitcoin client protocol. It enables wallets to verify Bitcoin transactions and manage balances without needing to download the entire blockchain, which typically requires a full node.

How Neutrino Works with Lightning Wallets:

• Neutrino uses compact block filters (BIP157 and BIP158). Instead of downloading every block, the wallet downloads these much smaller filters (only a few kilobytes per block) to identify relevant transactions.

• Lightning wallets, like those compatible with LiT, need to monitor the Bitcoin blockchain to track channel states and detect any attempts by counterparties to broadcast outdated states (which could be a form of cheating). A Neutrino-based Lightning wallet can perform this securely without requiring a full node.

Advantages of using Neutrino with LiT:

• It offers greater privacy compared to Simplified Payment Verification (SPV) wallets, as you don't reveal your addresses to a remote server.

• It provides a path to non-custodial Lightning channels on personal devices like phones or laptops.

• It is significantly lighter and faster to set up than a full Bitcoin node. As demonstrated in the "LND Speed Run" video, setting up a functioning LND Lightning node using litd in integrated mode with Neutrino can be done in approximately 13 minutes

Share

To get in touch with me please contact me on https://massmux.com and consider what i can do for you or for your Bitcoin or freedom project. If you have an event of speech you want to organize, a project to build and create, contents and so on, feel free to contact me.

The Lightning Network (LN) operates through a complex collection of protocols that form a protocol suite, also known as BOLTs (Basis of Lightning Technology). These BOLTs are detailed specifications that define the rules and procedures for how the Lightning Network should operate, ensuring that different LN implementations can communicate and work together seamlessly. Unlike Bitcoin, which has a reference implementation (Bitcoin Core) as its standard, Lightning uses these specification documents for interoperability and has several implementations.

The Layers

The BOLT protocol suite is generally classified into five distinct layers, where each layer builds upon and uses the protocols below it:

• Network Connection Layer: This foundational layer handles how nodes establish connections. It contains protocols that interact directly with internet core protocols like TCP/IP, as well as overlay networks such as Tor (v2/v3), and internet services like DNS. This layer is also responsible for the cryptographic transport protocols that protect Lightning messages.

  • BOLT 8: Encrypted and Authenticated Transport details how all interactions between Lightning nodes are encrypted and authenticated by default, using a unique public key as each node's identity. This ensures confidentiality, integrity, and protection against man-in-the-middle (MITM) attacks. The Lightning Network utilises a custom variant of the Noise Protocol Framework, for this purpose, offering strong security guarantees like authentication, encryption, forward secrecy, and identity privacy. The Noise_XK handshake specifically offers identity hiding for the responder's public key during connection initiation.

  • BOLT 10: DNS Bootstrap and Assisted Node Location outlines a method for nodes to discover each other using the Domain Name System (DNS). This helps new nodes find peers and allows existing nodes to track known peers. A new node can issue an SRV query to a DNS seed server (e.g., nodes.lightning.directory) to obtain a set of candidate bootstrap peers.

• Messaging Layer: This layer is responsible for defining message structures and encoding formats. It ensures an encrypted and secure communication and exchange of information via the network connection layer.

  • BOLT 1: Base Protocol serves as the cornerstone, outlining fundamental message structures and connection protocols, including how nodes initiate, sustain, and multiplex connections. It defines the Type-Length-Value (TLV) format, which allows the protocol to evolve by adding new features without altering its core structure. TLV records are used to extend messages in a forward and backward compatible manner, meaning older nodes can safely ignore information they don't understand.

    common ports:

    • Bitcoin mainnet port number 9735 or the corresponding hexadecimal 0x2607

    • Bitcoin testnet port number 19735 (0x4D17)

    • Bitcoin signet port number 39735 (0x9B37)

  • BOLT 9: Assigned Feature Flags governs the feature bits (or flags) that nodes use to communicate which capabilities they support. Features are typically assigned in pairs (optional and required bits), enabling nodes to determine compatibility with peers. The simple rule "it's OK to be odd" signifies that odd-numbered feature bits are optional, allowing for more flexible interactions. These feature bits are found in node_announcement, channel_announcement, and init messages, enabling peers to negotiate features for connections and payment types.

• Peer-to-Peer (P2P) Layer: This is the primary protocol layer for communication between Lightning nodes. It includes control messages and protocols for channel establishment, operation, and closing.

  • BOLT 2: Peer Protocol for Channel Management defines the rules for how payment channels can be opened and closed on the Lightning Network, and how nodes can update the channel's balance during normal operation. Channel establishment involves an exchange of messages such as open_channel, accept_channel, funding_created, funding_signed, and funding_locked.

  • BOLT 7: P2P Node and Channel Discovery elucidates the mechanisms for peer-to-peer node and channel discovery, eliminating the need for third-party information distribution. This is primarily achieved through the gossip protocol.

• Routing Layer: This layer defines the rules for creating payment channels between nodes and is responsible for routing payments between nodes end-to-end and atomically.

  • BOLT 4: Onion Routing Protocol outlines the structure and routing of an onion packet, facilitating payments from an origin node through intermediate nodes (hops) to a final destination. It describes how nodes build successive nested layers of encryption that are "peeled" off by each intermediary node, ensuring that only the sender knows the full route and only the immediate neighbors are known to each hop. This protocol is based on the SPHINX Mix Format. The onion packets are sent as part of the update_add_htlc message.

• Payment Layer: This is the highest layer of the network, presenting a reliable payment interface to applications. It defines the rules for using Hash Time-Locked Contracts (HTLCs) to route payments.

  • BOLT 11: Invoice Encoding for Lightning Payments introduces a straightforward and adaptable protocol for requesting Lightning Network payments, designed for compatibility with QR codes. BOLT 11 invoices include the payment hash, amount, description, and expiry time. A key limitation of BOLT 11 invoices is that they are generally single-use and specify a fixed amount.

  • BOLT 12: Offers is an upgrade that aims to address BOLT 11 limitations by enabling reusable payment requests and allowing static QR codes for both receiving and sending payments. Offers can be used multiple times and can be generated by either the sender or receiver. They contain enough information for a wallet to dynamically fetch a "real" invoice from the vendor through the Lightning Network itself, eliminating the need for external web servers.

Communication mechanisms

Key communication mechanisms within these layers include:

• Gossip Protocol: This peer-to-peer protocol allows nodes to share information about the topology of the Lightning Network. Nodes open encrypted connections and share (gossip) information received from other peers, such as newly created channels. This information is crucial for nodes to construct a channel graph (a map of publicly advertised channels and nodes) to find paths for payments. The main messages are node_announcement (communicates node public key, network address, and features), channel_announcement (proves channel existence and capabilities), and channel_update (describes routing policies like fees and timelocks for each channel direction). These messages are authenticated to prevent counterfeiting.

• Hash Time-Locked Contracts (HTLCs): HTLCs are a fundamental component for routing payments across multiple channels atomically and trustlessly. They are Bitcoin Scripts that require a recipient to either spend the payment before a deadline by presenting a secret preimage (derived from the payment hash in the invoice) or the sender can claim a refund after a timelock expires. The disclosure of the preimage propagates backward along the payment path, effectively settling all intermediate HTLCs. The update_add_htlc message is used to add an HTLC to a channel, while update_fulfill_htlc and update_fail_htlc are used for successful redemption or failure, respectively.

• Payment Routing: Payments are forwarded along a path of channels from the sender to the recipient. The sender (origin node) selects the entire payment path in a process called source-based pathfinding. The routing information for each hop is then encoded within the onion packet, encrypted layer by layer.

Changes to existing BOLTs or the introduction of new ones (like BOLT 12) require at least two distinct Lightning Client implementations to successfully integrate the feature and demonstrate interoperability before formal inclusion in the official specifications.

Share

The are many aspects of privacy on the Lightning Network and they are more complex compared to transactions happening on the base layer (on-chain transactions).

The first important aspect to understand is the use of onion routing. This mechanism is designed to provide different levels of information to the participants in a payment route. In fact each payment is routed from the source to the destination through the channels network and onion is used to perform such an action.

Onion Routing at work

Here's how:

• For the sender (origin node) and the recipient (final node):

  • Typically, only the sender and the recipient are fully aware of the source, destination, and amount transacted in a particular payment.

  • The sender knows the entire path of payment channels chosen to route the payment.

  • In a standard invoice-based payment, the recipient provides the invoice, containing the payment hash and their node ID, to the sender. So a certain amount of information are revealed to the sender node.

• For intermediary nodes (routing nodes):

  • Due to onion routing, intermediary nodes are only explicitly aware of the one node immediately preceding them and the one node immediately following them in the route.

  • They do not know who initiated the payment or to whom the payment is ultimately destined.

  • Intermediary nodes see the payment amount for the specific HTLC traversing their channel, as well as Timelock deltas. This is necessary for them to create the outgoing HTLC to the next hop (on the chosen path).

  • Features like fixed-length onion packets and padding are used to prevent intermediaries from determining their position in the path or the total length of the path, further enhancing privacy from these nodes.

The end parties (sender and receiver) possess full knowledge of the transaction details (in a different way) and path (for the sender), while the intermediate routing nodes are intentionally blinded to the origin and final destination, seeing only the immediate previous and next hop, along with the amount and timelock for their specific segment of the route. This architecture allows payments to traverse the network while minimizing the information available to third parties involved only in forwarding.

What if a LSP is involved?

If you use a Lightning Service Provider (LSP) – which can be described as third-party or central hub nodes that wallets connect to or rely on for services – they can gather certain information about your node and its activity.

Here is the type of information a third party, such as a central hub node that a wallet connects to, might gather:

• When you connect your node or wallet to the LSP's node, the LSP learns your node's public key and your network address (e.g., IP or Tor address). This permanently links your node identity to your network location for the LSP.

• If your wallet relies on the LSP's node for routing payments, the LSP (acting as an intermediary or hub) can know the sender of a payment.

• The LSP can potentially know the recipient of a payment, especially if they are involved in constructing the payment route on your behalf.

• They will observe the payment amount for payments routed through their node.

• If the LSP is providing channel management or is the node you opened a channel with (as discussed in relation to wallet types using third-party nodes), they would have knowledge of the details and state of that payment channel, although the channel balance distribution between you and them is only fully known to the two channel partners.

• Relying on a "hub" node for functionality simplifies the user experience but reduces user privacy. Outsourcing wallet components or functionality to a third party means you give up some privacy as that third party will learn some information about you.

So, finally, by connecting your node via an LSP (a third-party hub), you are diminishing the privacy benefits typically offered by Lightning's onion routing for those specific transactions.

As you can see there are no definitive recipes for getting the best privacy. There are always trade offs and everything must be evaluated for your specific case.

Share

On the Lightning Network we cannot just interconnect nodes with channels, we must find a way to route transactions across the existing channels. Infact our node cannot connect each existing node which it wants to send funds to; this would not escalate. This is why pathfinding and routing is basics on the Lightning Network theory.

Path-finding vs routing

Pathfinding is the process of finding and choosing a contiguous path made of payment channels that connects a sender (origin node) to a recipient (final node). It is important to distinguish pathfinding from routing, which refers to the series of interactions across the network that attempt to forward a payment along the previously selected path.

In the Lightning Network, pathfinding is source-based, meaning that the sender of the payment is responsible for finding the path through the network to the intended destination. This differs from typical internet routing where intermediary nodes decide how to forward packets.

To find a path, the sending node needs information about the network's structure or topology. This information is gathered by nodes building an internal map of the Lightning Network, known as a channel graph.

Channel Graph Construction

• The channel graph is the interconnected set of publicly advertised channels and the nodes that these channels interlink.

• Nodes build and maintain their perspective of this graph by listening to gossip protocol messages from their peers.

• Key gossip messages include:

  • node_announcement: Provides information needed to create the nodes (vertices) of the graph.

  • channel_announcement: Allows nodes to create the edges of the graph representing payment channels. Since channel balance splits mean liquidity differs in each direction, the graph is directed. A channel_announcement also includes proof that a channel exists between two nodes. Channels are referenced using a short channel ID (scid), which encodes their location in the Bitcoin blockchain.

  • channel_update: Contains metadata for a channel, such as routing fees and timelock duration. This allows incorporating fees and timelocks to set the cost or weight of the graph edges.

• Nodes continuously build and update their channel graph from the moment they start and connect to peers. More gossip information improves a node's "map" and pathfinding effectiveness.

• It is crucial to understand that there is no single, canonical "the" channel graph; each node constructs its own channel graph based on the information it has received, which is necessarily incomplete, incorrect, and out-of-date to some extent.

The Pathfinding Problem

• Pathfinding in the Lightning Network falls under graph theory and graph traversal. It's a problem of finding a path through a directed graph with numerical capacity constraints on its edges, similar to a flow network.

• If exact channel balances were known, standard pathfinding algorithms could easily compute paths, optimizing for factors like fees.

• However, channel balances (liquidity) are not known to the sender for privacy and scalability reasons. Nodes only know the aggregate channel capacity. For a payment to succeed, there must be adequate balance on the sending side of each channel in the path in the correct direction.

• This lack of knowledge about liquidity makes pathfinding significantly more complex than in theoretical computer science problems. The information is also highly dynamic.

Finding Candidate Paths

• With only partial information about channel liquidity, innovative pathfinding strategies are needed.

• Nodes can use the channel graph information (nodes, channels, topology, announced capacities, fee policies) to find paths.

• Since fees are accumulated from the recipient backward to the sender, pathfinding algorithms like Dijkstra's or A* are often applied backward from the recipient to the sender. The cost function for edges might include fees, estimated liquidity, timelock delta, or a combination.

• Paths must have sufficient liquidity not only for the payment amount but also for the cumulative fees of all subsequent hops.

Payment Delivery (Trial-and-Error Loop)

• The pathfinding mechanism currently implemented in Lightning nodes often involves creating a list of candidate paths, filtering and sorting them by some function (e.g., cost, capacity combination).

• The node or wallet then probes paths by attempting to deliver the payment in a trial-and-error loop until a path is found that successfully delivers the payment. This probing is not directly seen by the user but may cause delays.

• During the trial-and-error process, nodes can learn from failures and successes. For example, receiving an "insufficient balance" error from a node for a specific channel narrows the estimated range of liquidity for that channel. A successful payment indicates that all channels on that path had sufficient liquidity for the amount plus fees, allowing the node to update its liquidity estimates. This reduces the uncertainty of balances.

Multipart Payments (MPP)

• Multipart payments (MPP) are an advanced pathfinding strategy where a large payment is split into multiple smaller parts and sent over different paths simultaneously.

• This strategy helps overcome the challenge of uncertain liquidity, as smaller payments have a higher chance of succeeding on individual channels.

• MPP algorithms aim to find the optimal number of splits and amounts for each split, potentially utilizing paths that might not have sufficient liquidity for the full amount but can handle a smaller part.

• The process can involve multiple rounds of pathfinding, updating the channel graph after each round based on payment successes and failures to optimize subsequent attempts for any remaining amount.

While the process of finding the "best" path is complex and still an area of active research, the combination of building a channel graph from gossip, utilising pathfinding algorithms adapted for uncertain liquidity, and the trial-and-error probing process with learning from failures/successes enables payment delivery on the network. Pathfinding is not specified in a BOLT standard, allowing different implementations to use varying strategies.

Share

Closing a channel

A good and wisely open channel seldom needs to be closed. By “good channel” we mean a channel open with an interconnected and well managed partner, with good capacity and efficient flow of transactions. By the way sometimes we need to close a channel, in order to terminate the financial relationship between our node and the remote one, and we can do that cooperatively.

Cooperatively closing a Lightning Network channel is the preferred method for ending a channel partnership. This method involves a series of steps designed to ensure both parties receive their respective balances without delays or excessive fees.

What happens when a channel is closed? When a Lightning Network channel is closed, the funds that were held within the channel's 2-of-2 multisignature address are settled on the Bitcoin blockchain, and the channel is no longer available for transacting or routing payments. So the current balance of both parties is returned to each owner on-chain.

How the procedure looks like?

1. Initiating the Closure:

• shutdown Message: One channel partner (e.g., Alice) initiates the closing process by sending a shutdown message to the other partner (Bob). This message includes:

• channel_id: The unique identifier of the channel to be closed.

• scriptpubkey: A Bitcoin script specifying the address where Alice wants to receive her funds. This could be any standard Bitcoin address. Just for recap: normally, referring to an on-chain transaction, a scriptPubKey is a locking script that is placed on a transaction output, specifying the conditions that must be met to spend that output in the future.

• Acknowledgement: Bob responds with his own shutdown message, indicating his agreement to close the channel and providing the scriptpubkey for his chosen receiving address.

2. Negotiating Closing Fees:

• closing_signed Message (Alice): Alice, as the channel funder, initiates the fee negotiation by sending a closing_signed message to Bob. This message proposes a transaction fee for the on-chain closing transaction and includes Alice's signature for the transaction.

• closing_signed Message (Bob): Bob can either:

• Accept: If Bob agrees with the proposed fee, he responds with a closing_signed message echoing the same fee and his own signature for the transaction.

• Propose a Different Fee: If Bob disagrees, he responds with a closing_signed message containing a different fee_satoshis value.

• Fee Negotiation: This back-and-forth exchange of closing_signed messages continues until both parties agree on a suitable fee for the closing transaction.

3. Constructing and Broadcasting the Closing Transaction:

• Final Agreement: Once Alice receives a closing_signed message from Bob with the same fee she proposed, the negotiation concludes.

• Transaction Construction: Both nodes construct the final closing transaction, which is similar to a commitment transaction but without timelocks or penalty mechanisms. The outputs of this transaction directly pay Alice and Bob their respective balances at the specified addresses.

• Transaction Broadcast: Alice, as the initiator, broadcasts the signed closing transaction to the Bitcoin network.

4. Channel Closure Confirmation:

• Transaction Confirmation: The closing transaction is confirmed on the Bitcoin blockchain, effectively closing the channel.

• Fund Availability: Alice and Bob can now spend their received funds as desired.

What is important to remember:

• Cooperative Nature: Both channel partners actively participate in the closing process, agreeing on the final balance distribution and the transaction fee. They both need to be online during the whole closing process.

• On-Chain Fees: Closing a channel incurs on-chain transaction fees, which are paid by the channel funder.

• Efficiency: A cooperative close generally results in lower fees and faster fund availability compared to a unilateral force close. This is because the parties agrees on all the aspects of the closing process.

• Finality: The confirmed closing transaction provides a definitive record of the final channel balance on the Bitcoin blockchain and terminates the channel existence.

• Up-Front Shutdown Script (Optional): An optional feature where parties can pre-specify a "delivery address" for their funds during the channel opening. This enhances security by restricting the destination of funds upon closure, mitigating risks in case of a compromise.

  Share

  I hope you enjoyed this value added article. If you did, please share it and subscribe to my other social channels as Youtube, Instagram, Tiktok for even more contents.