02d769cb73

devs

Build a Lightning Wallet in just about 20 mins leveraging the FREE Voltage MutinyNet Lightning Node's to make it easier than ever to build on Bitcoin & Lightning and make REAL payments on a REAL network.

Link to slides: [https://tinyurl.com/20-min-lightning](https://tinyurl.com/20-min-lightning)

Link to completed project: [https://github.com/AustinKelsay/20-min-lightning-workshop](https://github.com/AustinKelsay/20-min-lightning-workshop)

Build a Lightning Wallet in 20 Minutes

bitcoinplebdev

bitcoin

# Bonds...Bitcoin bonds...everywhere!

I remember first hearing about Bitcoin bonds [several years ago](https://www.coindesk.com/markets/2023/12/12/worlds-first-bitcoin-bonds-receive-regulatory-approval-in-el-salvador) when El Salvador was going to build a city on top of a volcano and plug miners into the lava so they could do infinite bitcoin mining and they were going to pay for it all with these cool bonds that [Blockstream somehow was facilitating](https://bitcoinmagazine.com/business/el-salvador-to-issue-bitcoin-bond-on-the-liquid-bitcoin-sidechain). I certainly didn't feel like I had a good handle on what was going on at the time.

Now, we have the Bitcoin Policy Institute [proposing Bitcoin bonds](https://www.btcpolicy.org/articles/bitcoin-enhanced-treasury-bonds-an-idea-whose-time-has-come) as part of the solution to the US's $36 trillion dollar problem, Microstrategy is so far into bonds that Saylor is about to start calling himself double-o-21, and Pierre Rochard has started a company called [The Bitcoin Bond Company](https://bitcoinbondcompany.com/) with a website that really embraces clean and simple.

But I'm still lost as to what a Bitcoin bond actually is. I'll admit this might be because I haven't fully wrapped my head around what a normal bond is.

# What is the difference between a bond and a loan?

Those with a financial (or even basic) education will no doubt mock me now, but can we take a moment to marvel at the fact that a bond is basically just a loan?

Like many concepts in finance, I have always felt a little deceived by bonds. Everybody talks about bonds like they are so much better than loans -- the word even sounds solid, not risky like a liability. Bonds come to maturity while loans are called or due or even delinquent. Bonds have a coupon, while loans have interest payments. But, pretty much, a bond is just a loan. 

When you buy a bond, you are loaning someone money with the hope that they pay you back later (with interest). If you really want to get into the details, a bond is usually paid back all at once at the end of its term, while loans are paid back with regular installments until they are settled. 

Maybe the difference is that most discussion is conducted from a retail perspective: retail wants to be offered a loan but they want to buy a bond.

# The first Bitcoin bonds

So, if we have a rough concept that a bond is a loan, then a bitcoin bond is a bitcoin loan -- that, at least, is where it started out.

In early 2011, a Bitcointalk user named [grondilu](https://bitcointalk.org/index.php?action=profile;u=1663) issued a [bitcoin bond for 100btc](https://bitcointalk.org/index.php?topic=5214.0) to be paid back after 4000 blocks. The bond ended up [selling for 96.1btc](https://bitcointalk.org/index.php?topic=5214.msg76579#msg76579). I believe this was the first bitcoin bond floated in public.

It wasn't too long before the [Global Bitcoin Stock Exchange (GLBSE)](https://web.archive.org/web/20120503233610/https://glbse.com/) was launched. You could sell shares of a company or float bonds and do futures contracts on the exchange.[^1] This [announcement post](https://bitcointalk.org/index.php?topic=6500.msg94943#msg94943) on BitcoinTalk even links to a [sample bond contract](https://gitorious.org/black-market/black-market-client/blobs/master/bond-contract.xml), but sadly it's no longer live and the Wayback Machine didn't crawl it. Things [didn't end well](https://bitcointalk.org/index.php?topic=115669.msg1248736#msg1248736) when GLBSE [shotgun KYC'd their users](https://imgur.com/CiDfd) in 2012, but I'm not sure what people expected given the exchange was founded by a guy named Nefario...

[^1]: In the original command line client all values on GLBSE [were in sats](https://web.archive.org/web/20111210235232/https://gitorious.org/black-market/pages/Tutorial) -- although I haven't been able to figure out if they called them sats or not. Were they BIP 177 groupies?

As a side note, in 2011, Bitcoin bond also could still mean [a surety bond](https://bitcointalk.org/index.php?topic=10008.0) (the operator of a future's market put up 50btc bond to prove his honesty. Winners of the market got 5.72btc and 3.84btc). Such surety bonds still show up in Bitcoin today ([Fidelity bonds](https://clay-v.github.io/joinMarketDocs/users/fidelity-bonds.html)).

**Takeaway: in 2011, Bitcoin bonds were loans of bitcoin paid in bitcoin.**

# Overstock TIGRcub bonds and UBS Smart Bonds

In June 2015, Overstock announced that it was [issuing a bond using colored bitcoin](https://www.nasdaq.com/articles/overstocks-t0-reconciling-fiat-currency-and-bitcoin-blockchain-2015-12-16). They had a [deal with Counterparty](https://bitcoinmagazine.com/markets/overstock-com-offer-worlds-first-cryptosecurity-bitcoin-blockchain-1433797910) and the main selling point of the bond seems to be that it settled much faster than normal bonds. It didn't sell well. 

In 2015, Swiss bank UBS claimed they had developed a ["Smart bond" that was powered by "the blockchain."](https://web.archive.org/web/20150618231037/https://www.ifre.com/bitcoin-technology-will-disrupt-derivatives-says-banker/21202956.article) There are a number of references to these bonds [using Bitcoin](https://web.archive.org/web/20160305205836/http://smartbonds.co/) but I couldn't find any reference to an actual txid (on mainnet or testnet) and it looks like they actually meant to say [Ethereum](https://www.ibtimes.co.uk/ubs-reveals-its-interest-sidechains-well-ethereum-1519706). 

**Whatever the case, in 2015 we have Bitcoin bonds meaning at least some of the logic of the loan is implemented in script on a blockchain.** 

# Microstrategy's convertible bonds

In 2020, Microstrategy issued $650M of convertible 5-year notes (notes are apparently how one should refer to bonds that mature rather quickly) to raise money to buy bitcoin. These bonds are not bitcoin loans nor do they have anything to do with smart contracts or logic enforced by Bitcoin script -- they are just normal corporate loans...but Saylor used the money to buy bitcoin which sounds a lot like a speculative attack. 

The idea behind a convertible bond is that you can convert the bond to shares in the company at some pre-specified share price. [In the case of MSTR](https://www.reddit.com/r/wallstreetbets/comments/1gxc1fe/a_plain_english_explanation_of_mstrs_convertible/), usually this price is a lot more than the price shares trade at when the bonds are issued. Investors can hold the bond to maturity and get their money back plus interest (except most of the Microstrategy bonds don't offer any interest) or if at any point during the bond's term MSTR trades at a price above the convert price, they can convert their bonds to shares and take a nice little profit. It has apparently been working well for folks.  

For the purpose of those of us who would like to understand Bitcoin bonds, the takeaway is that, **in 2020, this is a loan of US dollars to buy bitcoin. It gets paid back in dollars (or shares of MSTR if bond-holders choose to convert). The only thing that makes it Bitcoin-related is that Saylor says he's going to buy bitcoin with it.**

# Volcano Bonds

When Bukele announced a Bitcoin bond to fund a Bitcoin mining enterprise (and a new city?) that would be powered by electricity generated from a volcano, it was yet another departure from a Bitcoin loan.

The volcano bond was denominated in dollars and was going to be sold in dollars. According to the [termsheet](https://archive.is/9s61O) (pictures of the slide [Bukele used to introduce the bond](https://x.com/bradmillscan/status/1462485730962325508)) the plan was to raise $1 billion with a ten-year tenure and a 6.5% coupon. El Salvador was going to use $500M of the money from bond sales to buy bitcoin which it would hold for 5 years before gradually selling this bitcoin and returning 50% of the proceeds (over the initial investment) back to investors.

This bond was [announced in 2021](https://bitcointalk.org/index.php?topic=5377037.0) and continually [teased](https://x.com/nayibbukele/status/1734378704518750656) until 2023 when it got ["tweaked" into a private equity deal](https://www.forbes.com/sites/digital-assets/2023/06/11/renewable-bitcoin-mining-project-tweaks-el-salvadors-bonds-proposal-to-raise-1-billion/) where investors get equity in a Bitcoin mining operation (yet to be built). Oddly, the National Bitcoin Office of El Salvador posted that [the bond was approved](https://x.com/bitcoinofficesv/status/1734366450616336622) to be issued in Q1 2024...and then never really mentioned it again.

Then earlier this year, in order to reach an agreement with the IMF to get a [much needed loan](https://x.com/BitcoinNewsCom/status/1896958450175000955), El Salvador had to [scale back it's pro-Bitcoin laws](https://archive.md/vF42f). It's unclear how this agreement affects any remaining plans to issue a bond, but it probably doesn't increase the likelihood we see such a bond soon.

**So in 2021 we have a government issuing bonds with a promise to buy bitcoin with some of the money and share *some* of any bitcoin price appreciation with their bond holders.** However, what's weird about this is that it's a [bad deal](https://archive.is/Vr0j2): you would make more just buying bitcoin.

# US Gov't Bitbonds

Now, in 2025, we get to Bitbonds. As proposed by the [Bitcoin Policy Institute](https://cdn.prod.website-files.com/627aa615676bdd1d47ec97d4/67eb2832db7319595e75a43c_Bitbonds.pdf),[^3] these are particularly low interest (1%) 10-year bonds issued by the US Treasury that would require the government to purchase bitcoin with 10% of the money raised from the sale of the bonds. Upon maturity, investors receive 100% of any gains from bitcoin price appreciation up to a 4.5% total compounded return, and share any remaining bitcoin upside 50/50 with the government.

[^3]: A fellow named [Brian Estes wrote a proposal for Bitbonds](https://x.com/BrianEstes32/status/1889740793595744259/photo/1) in February 2025, but it didn't get as much attention as the BPI proposal. I don't know if he's connected to them or not.

The BPI says the Bitbonds are a way for the government to get cheaper debt and potentially add to its "strategic Bitcoin reserve". An investor would still do better to just buy bitcoin, but these bonds are backed by the "full faith and credit of the United States government" -- apparently that it still a meaningful statement to some people. Also, many buyers who are not able to buy bitcoin (this needs a separate article itself: who are these entities who "cannot" buy bitcoin and why can't they? I've never understood that) likely can buy US treasury bonds. 

Taking the Bitcoin bond to an even further extreme, Sberbank launched a "bond tied to Bitcoin" in early June that somehow is tied to Bitcoin price in USD. Their [announcement on their website](https://www.sberbank.ru/ru/sberpress/all/article?newsID=75600ba9-38b3-4a30-a5e4-7cd58946f5fb&blockID=1303&regionID=77&lang=ru&type=NEWS) was light in details, with the main selling point being that "investors do not need to open a cryptocurrency wallet or make operations on unregulated foreign platforms."

**In 2025, Bitcoin bonds mean a US dollar loan to a government so it can buy bitcoin...or just price exposure to bitcoin for people who can't otherwise get it.**

# The Bitcoin Bond Company

Pierre Rochard launched his new company, The Bitcoin Bond Company, with a nicely worded memo. The memo seems pretty clearly aimed at corporate bonds, rather than municipal or government bonds. But as far as I can tell from listening to a few podcasts (Pierre has recently turned into a master of podcasts), these bonds are loans of US dollars for the purpose of buying Bitcoin. 

On TFTC, Pierre said,

> We need to recapitalize hundreds of trillions of dollars of bad debt with better collateral.

My understanding of municipal and US treasury bonds is that you don't so much care what the money is used for as much as you care whether issuer has (and will continue to have) the cashflow to pay the bond + coupon. Such bonds aren't backed by an asset so much as the power of violence wielded by the state (they can tax people and seize their property if they don't pay). 

I'm amenable to the argument that Bitcoin is better collateral than serfs and also the argument that, at least on the federal level, because politicians don't like to overtly raise taxes they opt for taking on more debt and so we might as well force them to buy some bitcoin with it. 

Corporate bonds, like the ones Microstrategy[^2] issues, *are* backed by traditional assets, and so I suppose the argument that bitcoin is better collateral makes some sense there.

[^2]: In the same way that I can't reasonably refer to a company that calls itself Good or Honest or Awesome by any such name, I'm not able to call the company Strategy. 


# New York City Bitbonds

At the Bitcoin Conference in Las Vegas, [Mayor Adams announced](https://bitcoinmagazine.com/takes/new-york-city-wont-be-issuing-bitbonds-any-time-soon) that he was going to push for Bitbonds in NYC. Adams was light on details, but he said the bond was going to be for holders of bitcoin to be able to invest in city bonds, as if the bonds were going to be loans of bitcoin to the city.

Shortly after his announcement, the New York City Comptroller [issued a statement](https://comptroller.nyc.gov/newsroom/comptroller-brad-lander-pours-cold-water-on-mayor-adams-bitbonds-proposal/) nixing the idea. The Comptroller claimed that New York City only issued bonds to pay for capital improvements and didn't have any way to do this with bitcoin. Also he said they were incapable of converting bitcoin received from the bond to dollars. 

Shockingly, the New York City Bond proposal (if the opaque statements of two government officials can be taken as the term sheet) is the closest to the origin of bitcoin bonds.

# Why would anyone ever buy such a thing?

My biggest question about the Bitbonds phenomenon (in its recent iteration) is why anyone would buy a bitbond instead of bitcoin? 

Best arguments I can think of are:

1. You "can't" buy bitcoin (regulatory arbitrage).
2. You are worried bitcoin is going to go bust and you want downside protection. 
3. You like to give your money away?

What do people mean when they say Bitcoin bond?

Scoresby

lightning

Tuscany Lightning Summit - The State of the Lightning Network (Giacomo Zucco)

nout

Politics_And_Law

> “As of 6:59 pm ET nearly all pizza establishments nearby the Pentagon have experienced a HUGE surge in activity,” the account Pentagon Pizza Report posted on Thursday.

> Not confining its analysis to pizza, the account noted three hours later that a gay bar near the Pentagon had “abnormally low traffic for a Thursday night”, and said this probably pointed to “a busy night at the Pentagon”.

Pentagon pizza monitor predicted ‘busy night’ ahead of Israel’s attack on Iran

south_korea_ln

bitcoin_Mining

> **This case study compares two Bitcoin mining protocols, Stratum V1 and V2 , and demonstrates how the combined technical improvements of Stratum V2 translate into a substantial profitability increase for miners.**
>
> ![](https://m.stacker.news/96286)
>
> In bitcoin mining, a millisecond can determine whether a miner successfully earns the block reward or loses out to a competitor. At the core of this race lies the mining protocol that connects miners, pools, and the network, with the goal of ensuring effective communication between participants.
>
> For over a decade, Stratum V1 (SV1) has served as the industry standard mining protocol, but as mining competition has intensified over the years, the need for technical improvements on the protocol-side has become apparent. While we have seen massive technical improvements on the mining hardware side over the past decade, miners have been stuck with a less than optimal protocol.
>
> This is why we have developed Stratum V2 (SV2), the successor to SV1. This protocol is associated with miner-side block construction, allowing miners to run their own nodes and create their own block templates. While this remains a critical innovation, SV2 also introduces substantial improvements in security and efficiency impacting profitability.
>
> **[...read more at stratumprotocol.org](https://stratumprotocol.org/blog/case-study/hashlabs/)**



How Stratum V2 Increases Mining Profitability

0xbitcoiner

BTC Mesh: Sovereign Communication and Off Grid Bitcoin Transactions

eddieoz

# 🧠 Long-Range vs Short-Range Quantum Attacks on Bitcoin

Quantum computers will change the security assumptions of Bitcoin. But how exactly?

Let’s break it down.👇

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

---

Bitcoin relies on ECC to protect your private keys.  
But quantum computers break ECC.

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

---


Quantum computers open two attack windows:
- **Short-range:** pubkey is revealed before confirmation
- **Long-range:** pubkey was exposed long ago and still sits on-chain

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

---

## 🔐 1- Short-Range Attacks  (a.k.a. Transaction Hijacking)

Let’s start with a **P2PKH** transaction.  
It looks secure… until you broadcast it.

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


---

### 👀 When Does the Public Key Appear?

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

In P2PKH, your **public key stays hidden**  until you spend.  
The moment you sign a transaction, your pubkey becomes visible.

---

###  A Window for Attack
![](https://m.stacker.news/94934)

From that moment, there’s a race:  
Can a quantum attacker compute your private key before your transaction gets mined?

---
### ⏳ Mempool = Danger Zone

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

Here’s how it plays out:
1. You sign and broadcast your tx
2. It enters the mempool
3. Miner hasn’t mined it yet  
→ That’s the **attack window**

---


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

---

### Next step: they broadcast a conflicting transaction that spends the same coins.


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



---
### Miner Chooses the Higher Fee


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



---


### 🕵️ 10. Transaction Hijacking

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

Also known as a **front-running attack**.  
It’s specific to the *time window between broadcast and mining*.

---

## 🧱 2- Long-Range Attacks

These are scarier.  
They target coins that already have public keys exposed — like old `P2PK` outputs.

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

---

These UTXOs are permanently vulnerable.  
A quantum attacker can sweep them **at any time**.


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

---

Once a public key is on-chain, the attacker doesn’t need perfect timing.  
They can break it **at any moment** in the future.


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

---

Examples of **script types vulnerable to long-range attacks**:
- P2PK  
- P2MS  
- P2TR (script-path)  
All reveal the pubkey before spend.


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

---

## 📊 P2PK Holds 8.68% of All BTC

That’s **~1.72 million BTC** sitting in publicly-exposed outputs.  
Mostly Satoshi-era coins.

*(Source Chaincode last report on "Bitcoin and Quantum Computing")*

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

---

Even P2PKH isn't totally safe.  
If a user reuses the address, their public key becomes exposed and vulnerable to future long-range attacks.


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

---

## 🔜 What’s Next?

In upcoming posts, we’ll cover:

- Bitcoin Mining and Grover’s Algorithm  
- The “Burn vs Steal” Dilemma  
- Post-Quantum Proposals: Lamport, OP_CAT, P2QRH...

Stay tuned.

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

---

👉 Make sure to follow [@Bitcoin_Devs](https://twitter.com/Bitcoin_Devs)  
so you don’t miss what’s coming next!

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

---

Quantum Risk to Bitcoin (Part 2)

bitcoin_devs

HUGE Blotto update:
- Buy multiple tickets at once
- Nostr Bot with enthusiastic AI announcer (Powered by https://ppq.ai)
- Many bug fixes & improvements!

Starting with a 40K prize pool donated from the last game that was unclaimed and 5 hours to go!

I didn’t expect so many tickets purchased in the previous game (198 tickets purchased). The game was made with a 1-shot prompt on https://lnfly.albylabs.com - Alby’s experimental lightning vibe prototyping tool, and this has motivated me to make a better version.

This follow up version is also made with a single 1-shot prompt, but much refined to fix a lot of bugs and issues in the original game. Both versions were made with Claude Sonnet 4.

Let's see how big the prize pool will get and how long the game lasts!

HUGE BLOTTO Update - Blotto V2 (Purchase multiple tickets, AI Nostr Bot + more)

rolznz

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

BIP 119 OP\_CHECKTEMPLATEVERIFY allows users to restrict outputs by committing to nVersion, nLockTime, scriptSig hash, input count, sequences hash, output count, outputs hash and input index. In this post, we will focus on committing to multiple inputs because it could help in improving payjoin.

Example from the BIP:

        Path A: <+24 hours> OP_CHECKSEQUENCEVERIFY OP_CHECKTEMPLATEVERIFY <Pay Alice 1 Bitcoin (1 input) nLockTime for +24 hours>
        Path B: OP_CHECKTEMPLATEVERIFY <Pay Bob 2 Bitcoin (2 inputs)>

In this case, there are 24 hours for the output to, with the addition of a second input, pay Bob 2 BTC. If 24 hours lapses, then Alice may redeem her 1 BTC from the contract. Both input UTXOs may have the exact same Path B, or only one.

Let’s make some changes in this example so that it could work as payjoin:

        Path A: <+1 hour> OP_CHECKSEQUENCEVERIFY OP_CHECKTEMPLATEVERIFY <Pay Alice 0.01 Bitcoin (change) and Pay Bob 0.02 Bitcoin (1 input) nLockTime for +1 hour>
        Path B: OP_CHECKTEMPLATEVERIFY <Pay Bob 0.03 Bitcoin and Pay Alice 0.01 Bitcoin (change) (2 inputs)>

This will result in 3 transactions:

1.  Funding tx (sender)
    
2.  Funding tx (recipient)
    
3.  Spending tx
    

We can reduce it to 2 transactions by using P2A as described by stutxo in this repository: [https://github.com/stutxo/simple\_ctv](https://github.com/stutxo/simple_ctv) It would improve privacy for this protocol because P2A can be can spent by anyone along with their inputs.

Differences compared to normal payjoin:

1.  Less interaction
    
2.  Recipient broadcasts the transaction (path B)
    

Most importantly this protocol fixes the [UTXO probing attack](https://uncensoredtech.substack.com/p/utxo-probing-attack-using-payjoin).

Payjoin with CHECKTEMPLATEVERIFY

# Quantum Threats to Bitcoin — Part 1

Bitcoin’s security is based on hard math.

Quantum computers break that assumption.

Let’s walk through how visually.

---

## Bitcoin’s Security is Based on Math

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

Bitcoin uses math (ECDSA, secp256k1, ..) to protect your coins.  
So far, no one can break it…  

---

## 1- But Quantum Breaks That Math

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

Quantum computers can punch through math-based defenses.  
What’s hard for your laptop becomes easy for a quantum machine.


---

## 2- Classical Computers Use Bits


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

Bits can only be 0 or 1.  
All computations are done one step at a time.

---

## 3- Quantum Computers Use Qubits


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

Qubits can be 0, 1, or both.  
This allows quantum computers to do things in parallel (a massive leap in speed)

---

## 5- Parallelism Changes Everything


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

Classical = tries one possibility at a time.  
Quantum = tries *all* possible combinations simultaneously.

---

## 🔐 What Does This Have to Do with Bitcoin?


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

Bitcoin uses elliptic curve cryptography (ECC).  
Private key `k`, public key `P = k*G`.

---

## 🔁 ECC Is Easy One Way, Hard the Other

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

Easy: k → P  
Hard: P → k  
This asymmetry protects your Bitcoin.

---

## 🕳️ Brute Force Takes Forever


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

A normal computer would need ~10³⁸ operations to go from public key → private key.  
That’s trillions of years.

---

## 🧠 Pollard’s Rho: The Best Classical Attack


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

Right now, attackers try all keys one-by-one.  
The best known method is Pollard’s rho (still slow)

---

## 💥 Shor’s Algorithm Changes That

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

Quantum computers can run Shor’s algorithm, which breaks ECC.  
It only takes around **10⁶ steps**.

> Classical: “Trillions of years”  
> Quantum: “Hours to days”


---

## 🚨 When You Spend BTC, You’re Vulnerable

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


When you spend, your public key is revealed.  
A CRQC could see it, extract your private key, and steal your funds.

---

## 📉 20–50% of All Bitcoin at Risk


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

> “Roughly 4–10 million BTC could be stolen if CRQCs arrive.”  
— Last Chaincode Labs report on "Bitcoin and Quantum Computing"

---

## 🕰️ When Will They Arrive?


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

Experts give a **50% chance** we’ll see quantum computers that can break ECC by **2030–2035**.  
NIST plans to **ban ECC by 2035**.

---

## 🔜 Next Up

![](https://m.stacker.news/94500)
Next explainer in the series:  
**Script Types and Their Quantum Vulnerability** (P2PK, P2PKH, P2TR, etc.)

---

## 🧡 Stay Updated


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

We’ll be sharing more visual explainers on quantum threats, Bitcoin script vulnerabilities, and post-quantum proposals.

Follow [@Bitcoin_Devs](https://twitter.com/Bitcoin_Devs) to stay in the loop.

---

*Inspired by the Chaincode Research Report on Quantum Threats to Bitcoin.*




Quantum vs Bitcoin: A Visual Breakdown

Dr. Jack Kruse's MINDBLOWING Answer to "Who is Satoshi Nakamoto?"

jinformatique

A simple lottery game where the countdown extends by 10 minutes each time someone buys a ticket.

Winner will be paid out to their lightning address.

Made with LNFly (an experimental platform to vibe coding bitcoin lightning apps) https://lnfly.albylabs.com/

⚡ BLOTTO - Lightning Lottery

As you (old stackers) may know I am building a small house for my homestead place. Yes, is a big project that goes slow because I am building it myself without machinery and professional tools.
For those that don't know the story here you can read about it https://darthcoincitadel.substack.com

But now with this post, I only want to show you some latest updates and an example of how I literally stack sats with this house.

Earthbags - bought with sats (direct payment to provider)
Beers - bought with sats (direct payment to provider)

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

Each beer can is recycled into... a protection wall. If I already paid those beers with sats, it means that each can can represent 1 sat (is just an example not sure if is literally 1 sat) that is stacked now into a wall.

Each earthbag also can represent 21 sats, stacked into a wall.

Stacking also means spending wisely your sats, only when is really needed. Yes, I am a "beer man", every day drinking beer. So I thought it would be a real waste of sats if I throw away those beer cans. And also I realized (after some tests) that the wall built with cans is very efficient and strong protection level for the earthbags wall. 

Yes, this is not finalized wall, it will come another fine cover (plaster) for that "cans wall" and then painted.

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

Here is latest update: I started to fix in place the first beams for the roof.

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

Using a simple technique to combine their weight and also pushing each others to form a natural force. Some will say that doesn't even need nails/screws, but I will put some just for the sake of having them.

On top of these beams will come the wooden plates from some pallets, then a rubber insulator carpet and then a small rocks level, then dirt and grass level. Yes, will be a GREEN roof with grass and flowers, as a very good insulator for cold and hot and water.

This is only the half of the house and only the first house that I am building. More will come later, once this small one is ready.

Is hard damn work, because I am alone, into the wilderness, far from any car accessible road and all necessary must be carried on my backpack.

So... stackers, this summer you will not see me too much online on SN. I am really busy and I hope will have a very fruitful building season if the weather is favorable. Will keep you posted here on SN and at the end of season on my dedicated substack with more details: https://darthcoincitadel.substack.com

How literally do I stack sats building a house

DarthCoin

tech

This link was posted by [Tycho](https://news.ycombinator.com/user?id=Tycho) 2 hours ago on [HN](https://news.ycombinator.com/item?id=44097144). It received 113 points and 37 comments.

Engineers discover new class of materials that passively harvest water from air

I was _ultimately_ nerd sniped last LN spec meeting’s discussion [^0] of the privacy impact of surfacing granular HTLC hold times via attributable failures [^1]. This post contains a recap of the discussion (as I understand it) and a summary of my sniping.

Recap of meeting discussion:

*   The current version of the spec allows forwarding nodes to specify the time they held the HTLC in ms.
*   It’s likely that sending nodes will use this value in the future to pick low latency routes.
*   Adding a random forwarding delay ([^2], [^3]) improves payment privacy.
*   Surfacing hold times may dis-incentive this privacy-preserving delay as nodes race to the bottom to be the fastest.

The solution suggested in the meeting was to change the encoding to represent blocks time instead, so that the smallest encodable value still leaves time for processing and a random delay. This can’t be done by keeping ms encoding and enforcing some minimum, because nodes can always report smaller values; by changing the encoding, communicating a value under the smallest block of time becomes impractical [^4].

Some questions that came up in the meeting:

*   What value should we set this minimum to?
*   How should we manage the UX/privacy tradeoff of fast payments vs forwarding delays?
*   What happens if we need to increase forwarding delays in future?

### [](#p-5107-understanding-forwarding-delays-privacy-1)Understanding Forwarding Delays + Privacy

To understand how these forwarding delays impact payment privacy, I took a look at a few research papers on the subject - summarized below. Of course, any inaccuracies are my own, I’d really recommend reading the papers to form your own opinion.

We are concerned about two different types of attackers:

1.  **On path**: attacker creates channels, routes payments and attempted to deanonymize them.
2.  **Off path**: attacker controls an AS, and is able to monitor messages at a network level

#### [](#p-5107-on-path-adversary-2)On Path Adversary

As outlined in [^5]:

*   Attacker probes the network to get latency estimates for nodes.
*   Attacker opens up low-fee and low-expiry channels to attract channels.
*   Recipient identification:
    *   Record the time between `update_add_htlc` and `update_fulfill_htlc`
    *   Compare to latency estimates to calculate number of hops the HTLC took.
*   Sender identification:
    *   Only works if the sender retries along the same path.
    *   Fail the first HTLC seen, and record time between `update_fail_htlc` and replacement `update_add_htlc`.
*   Use amount and CLTV of HTLC to reduce set of possible senders/receivers.
*   Use latency estimates to identify possible paths based on recorded time.

A _random_ forwarding delay is helpful here because it interferes with the ability of the attacker to compare the time they’ve recorded with their latency estimates. In lay-carla’s terms (give or take some noise), the delay is successful if it equals at least the processing time of a single hop, because this means that the attacker will be off by one hop and fail to identify the sender/receiver.

#### [](#p-5107-off-path-adversary-3)Off Path Adversary

As outlined in [^6]:

*   Attacker ICMP pings nodes in the network to get latency estimate.
*   Attacker controls an AS and passively monitors network traffic.
*   The commitment dance for a channel can be identified by message size and direction.
*   With knowledge of the LN graph, an adversary can construct “partial paths” by tracing flow of `update_add_htlc` messages through the channels they observe.
    *   This is timestamp based: if an incoming and outgoing `update_add_htlc` are processed within the estimated latency, they are assumed to be part of a partial path.
*   Set limits for the possible payment amounts:
    *   Minimum: largest `htlc_minimum_msat` along the partial path (can’t be smaller than the biggest minimum).
    *   Maximum: smallest `htlc_maximum_msat` or `capacity` along the partial path (can’t be bigger than the smallest channel).
*   Perform a binary search to get a payment amount range:
    *   Find the path from first to last node in the partial path for an amount.
    *   If the computed path differs from the partial path, the amount is discarded.
*   Remove channels that can’t support the estimated payment amount.
*   Identify sender and receiver:
    *   Nodes that remain connected to the first/last hop in the partial path are candidate sender/receivers
    *   Check payment path between each possible pair for the payment amount.
    *   If the path uses the partial path, then the pair is a possible sender/receiver.

A forwarding delay is helpful here because it interferes with the ability of the attacker to construct partial paths. Notably, once these paths are constructed the attacker still has a large anonymity set to deal with, and the attack relies heavily on deterministic pathfinding at several stages to reduce this set.

[^7] also examines how a malicious AS can identify nodes roles in a route with the goal of selective censorship:

*   Senders: `update_add_htlc` messages sent “out of the blue” indicate that the node is the original sender.
*   Intermediaries: timing analysis is used to connect an incoming `revoke_and_ack` with an outgoing `update_add_htlc` to identify forwarding nodes.
*   Recipient: sending a `update_fulfill_htlc` message after receiving a `revoke_and_ack` message identifies the recipient, independent of timing.

Note that senders and receivers are identified based on the size of messages, without needing to rely on any timing information. Here, a forwarding delay isn’t helping sender/receiver privacy at all - per the suggestions in the paper, it seems like message padding and possibly cover traffic are the most promising defenses.

### [](#p-5107-incentives-4)Incentives

While reading through all of this, it stood out to me that we’re relying on forwarding nodes to preserve the privacy of senders and receivers. This doesn’t seem particularly incentive aligned. Attributable failures and hold times aside, a profit driven node is incentivized to clear out payments as fast as it can to make efficient use of its capital. This seems sub-optimal on both ends:

*   Senders and receivers who care about privacy can’t hold forwarding nodes accountable for adding a delay, because these values _must_ be random to be effective. If you see that nobody delayed your payment, it may have just happened to get a very low delay on each hop.
*   Forwarding nodes don’t know how long a HTLC’s payment route is, so they can’t easily pick a good delay time that they’re certain will help with privacy (unless they over-estimate, adding an additional hop’s latency) [^8].

Is there something better that we can do?

#### [](#p-5107-on-path-adversary-5)On Path Adversary

In this attack, the attacker depends on the time between `update_add_htlc` and `update_fulfill_htlc` to make inferences about the number of hops between itself and the recipient to deanonymize the recipient. It doesn’t matter where the delay happens, just that there is enough delay for it to be ambiguous to the attacker how many hops there are to the recipient. It seems reasonable that we could implement delays on the recipient, instead of with the forwarding nodes. This puts the decision in the hands of the party whose privacy is actually impacted. It also works reasonably well with other hold-time aware systems like jamming mitigations and latency-aware routing, because we have to accommodate the MPP case where the recipient can hold HTLCs anyway.

For sender de-anonymization, the attacker needs to fail a payment and be on-path for the retry. This is more trivially addressable by adding a cool down between attempts and using more diverse retry paths. This is within the control of the sender, so it is nicely incentive aligned.

#### [](#p-5107-off-path-adversary-6)Off Path Adversary

While timing information is used in this attack, my impression from [^6] was that predictable routing algorithms are what makes reducing the anonymity set feasible for the attacking node. This is again a level that we could provide the sender to toggle as they see fit rather than relying on forwarding nodes. Without the ability to prune the network, the anonymity set for this attack remains infeasibly large.

This attack also gets significantly easier for larger payments, as the attacker can prune more channels (that wouldn’t be able to facilitate the amount). So more aggressive payment splitting is another option for privacy conscious sending nodes that does not rely on forwarding nodes for protection.

### [](#p-5107-what-to-do-for-attributable-failures-7)What to do for attributable failures?

Practically in today’s network, we don’t have any privacy preserving forwarding delays deployed:

*   LND (80-90% of public network): has a 50ms commitment ticker to batch updates, but it is not randomized so can trivially be accounted for in the attacks listed above [^9].
*   Eclair (major router): does not implement forward delays.

So we do not currently have any defenses against the above listed attacks implemented. And we should fix that!

My opinion is:

If we truly believe that forwarding delays are the best mitigation:

*   We should all implement and deploy them.
*   We should change encoding in attributable failures hold times to enforce minimum value.

If that’s not the case (which I don’t necessarily think it is):

*   We should investigate and implement some of the suggestions listed above.
*   It’s fine to leave the attributable failures hold times encoded with millisecond granularity.

### [](#p-5107-footnotes-8)Footnotes

[^0]: [Lightning Specification Meeting 2025/05/19 · Issue #1258 · lightning/bolts · GitHub](https://github.com/lightning/bolts/issues/1258#issuecomment-2892255704)

[^1]: [Attributable failures (feature 36/37) by joostjager · Pull Request #1044 · lightning/bolts · GitHub](https://github.com/lightning/bolts/pull/1044)

[^2]: [bolts/04-onion-routing.md at 011bf84d74d130c2972becca97c87f297b9d4a92 · lightning/bolts · GitHub](https://github.com/lightning/bolts/blob/011bf84d74d130c2972becca97c87f297b9d4a92/04-onion-routing.md?plain=1#L301)

[^3]: [bolts/02-peer-protocol.md at 011bf84d74d130c2972becca97c87f297b9d4a92 · lightning/bolts · GitHub](https://github.com/lightning/bolts/blob/011bf84d74d130c2972becca97c87f297b9d4a92/02-peer-protocol.md?plain=1#L2394)

[^4]: Forwarding nodes could flip a high bit to indicate that they’re using ms, but this would require sender cooperation and lead to devastating penalization if senders aren’t modified (because it would lead to their hold time being interpreted as massive).

[^5]: [https://arxiv.org/pdf/2006.12143](https://arxiv.org/pdf/2006.12143)

[^6]: [Revelio: A Network-Level Privacy Attack in the Lightning Network | IEEE Conference Publication | IEEE Xplore](https://ieeexplore.ieee.org/document/10190502)

[^7]: [https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.AFT.2024.12](https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.AFT.2024.12)

[^8]: Yes, we may very well have an incredibly privacy conscious and altruistic routing layer. Even if that’s the case (quite probably, since there isn’t much money to be made with it), we shouldn’t be relying on it to make privacy promises.

[^9]: Heavily emphasized across all papers is that this delay needs to be random to be impactful.

Originally posted by @actuallycarlakc in [DelvingBitcoin](https://delvingbitcoin.org/t/latency-and-privacy-in-lightning/1723/1)

Latency and Privacy in Lightning

supratic

I came across [PeerSwap](https://www.peerswap.dev/) the other day when looking over the apps that are installable on Umbrel. I had never heard of it before. I'm curious if any stackers have heard of it or used it. Do you have opinions? I have experience with a couple other tools like Boltz and Lightning Loop but not PeerSwap.

Here's what their site says.

> PeerSwap enables Lightning Network nodes to balance their channels by facilitating atomic swaps with direct peers. PeerSwap enhances decentralization of the Lightning Network by enabling all nodes to be their own swap provider. No centralized coordinator, no 3rd party rent collector, and lowest cost channel balancing means small nodes can better compete with large nodes.

> PeerSwap currently has a working implementation for both CLN and LND nodes.

> At the moment PeerSwap is suitable for power node operators with Linux command line skills. Implementations of control panel GUI interfaces are currently underway which will make PeerSwap easier to use for ordinary end users.

They have a chart comparing their service to others as well.

What do you think?

PeerSwap - Thoughts on this Lightning Channel Rebalancing?

kepford

Construction_and_Engineering

@DarthCoin Should Contact This Lady

siggy47

There has been a lot of debate about a [recent discussion](https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ) on the mailing list and a [pull request](https://github.com/bitcoin/bitcoin/pull/32359) on the Bitcoin Core repository. The main two points are about whether a [mempool policy](https://bitcoin.stackexchange.com/q/120269/5406) regarding OP_RETURN outputs should be changed, and whether there should be a configuration option for node operators to set their own limit. There has been some controversy about the background and context of these topics and people are looking for more information.
Please ask short (preferably one sentence) questions as top comments in this topic. @Murch, and maybe others, will try to answer them in a couple sentences. @Murch and myself have collected a few questions that we have seen being asked to start us off, but please add more as you see fit.

Quick questions about OP_RETURN? Quick answers here.

tidwell

BooksAndArticles

Why tether moved their HQ to ES right before Trump inauguration?
This is a whole new rabbit hole...

El Salvador's Gulag Cryptopelago

bitcoin_beginners

If you do not want to read all the rest here is my TLDR answer: because most of them are just noobs (without good knowledge of networking), followers of influencers promoting Tor only nodes and believe that Tor is the magic wand that fix everything. IT IS NOT. Tor is a false illusion of "privacy" for BTC LN nodes and is useless.

---

Ok now let's get into this question. With this post I want to make more noobs to think about and take the right decisions.

### Why most of bitcoiners run a Tor only BTC LN node ?

Because most of them are using bundle nodes boxes (Umbrel, Start9, Raspiblitz, MyNode etc) that mainly are by default Tor connected to the rest of the internet.
Why they use Tor?
Because is damn easier plug'n'play for a noob that doesn't know what is LAN, WAN, ports, IP, domain, FQDN, HTTP(S), packets, encryption etc you name it... Tor is making their life easier, without having to configure routers, ports, IPs etc. And the influencers are "selling" the idea that "run Tor nodes for your privacy" but not explaining what really is privacy.

Let's say it clearly: INTERNET IS A PUBLIC PLACE ! So if you do not want to expose your private activity, then DON'T DO IT ON INTERNET. Anything you do on internet became PUBLIC.

People nowadays cannot make the difference between PRIVATE and PUBLIC but they still demand privacy in a public place LOL. Is like walking naked on the street and you demand to people not to look at you because is private.

### Is it Tor such an ultimate "privacy tool" ?

>The fundamental question becomes: How can conscientious individuals maintain their privacy online? If absolute privacy—complete evasion of government data collection—is the goal, then the internet is simply not suitable. While it may be possible to protect information from hackers and corporations, completely avoiding surveillance by large governments is essentially impossible.

Source - [Tor and the Illusion of Anonymity](https://johnwlittle.com/tor-and-the-illusion-of-anonymity/) - by John Little

As I said before: if you do not want to reveal private parts of your activity, don't do it online! Or at least do it under a pseudonym, another false identity, hide into the crowd that cannot identify or link the REAL you.

Despite its benefits, Tor is not a foolproof solution for online privacy. Here are some reasons why:

1. Exit Node Vulnerability
The data leaving the Tor network through the exit node is decrypted. If the exit node is malicious or monitored, your traffic can be intercepted and analyzed. While your IP address remains hidden, sensitive information like login credentials or personal data could be exposed if the website you’re visiting doesn’t use HTTPS.

2. End-to-End Tracking
While Tor hides your IP address, it doesn’t encrypt the data you send to or receive from websites. If you log into a personal account or share identifiable information, your anonymity could be compromised.

3. Browser Fingerprinting
Tor Browser’s settings are designed to minimize browser fingerprinting, a technique used to identify users based on their browser and device configurations. However, if you modify Tor’s default settings or install additional plugins, you increase your risk of being identified.

4. Correlation Attacks
Advanced attackers, such as nation-states, can use timing correlation attacks to de-anonymize Tor users. By monitoring entry and exit nodes, they can potentially link your activities to your IP address.

5. Malware and Phishing
Tor doesn’t protect you from malware, phishing, or malicious websites. Clicking on harmful links or downloading infected files can still compromise your privacy and security.

6. Adding more time to response
Speed is crucial for BTC LN nodes. Maybe for a BTC only node (not LN) it is OK to sync every 10 min a block, is not a big deal. But for a PUBLIC ROUTING LN node it is crucial to have fastest response. And Tor network is adding huge delays ! That makes your LN node UNRELIABLE FOR ROUTING.

NOTE: we are talking about PUBLIC LN nodes here, not PRIVATE (those that are not doing public routing and are not 24/7 online).

So using a public routing node only behind Tor is totally useless and against the most important thing: routing. You are literally doing more harm than good to the entire Lightning Network because your node will be a bottleneck for all those trying to pass through your shity node a payment.
If you are already a public node, is already known information, so is useless to think you are hiding behind a Tor onion address...

If you really want to not reveal your IP from where your LN ndoe is operating, use a VPN IP, with a Wireguard tunnel towards your LN node machine. That will add a faster route to your node and also full control of the traffic.

You rent a VPS, that is a simple virtual machine in a datacenter. You install your own software OS and Wireguard tunnel. So chances that somebody else is watching your traffic are almost null.
On the other side, using Tor, ask yourself: are you really in full control of the exit nodes? Do you really know who is on the other side of the Tor network that will have to decrypt your traffic in order to forward it to the destination?

---

Another aspect I do not understand from many users: OK they run a Tor only n ode because they run a bundle node software that do not offer a clearnet connection and they are not technically capable to build their own infrastructure with independent software.
The question is: why then use for example to connect over Tor with your own LN node? ARE YOU NOT TRUSTING YOURSELF?
Why do you not use a Tailscale connection, that is a private VPN tunnel, over a private IP (not public IPs).
[I've explained in more details in this guide what is a Tailscale network.](https://darth-coin.github.io/nodes/tailscale-vpn-your-node-en.html). It's damn easy to setup and use, even for not so knowledgeable users and offer enough security and privacy when is about to connect remotely to your Tor boxes. Or even https://holesail.io/

---
If you really want to run a public routing node, then start by learning a lot about networking, security, servers, VPS, VPN, traffic routing etc.

I wrote more guides about these aspects and I invite you all to read them and think more about when is time to run a LN node over Tor:
- https://darth-coin.github.io/nodes/recommendations-ln-node-operators-en.html
- https://darth-coin.github.io/nodes/lightning-node-maintenance-en.html
- https://darth-coin.github.io/nodes/private-ln-nodes-en.html
- https://darth-coin.github.io/nodes/public-private-node-liquidity-scenario-en.html
- https://darth-coin.github.io/merchants/operating-ln-as-merchant-en.html
- https://darth-coin.github.io/wallets/bitcoin-and-privacy-en.html

And here are some very good step-by-step guides about how to run a LN node behind a VPS tunnel, @Hakuna wrote these excellent guides:
- https://github.com/TrezorHannes/Dual-LND-Wireguard-VPS
- https://github.com/TrezorHannes/Dual-LND-Hybrid-VPS

There are even more guides out there about how to configure a wireguard tunnel. Read them all and adapt to your needs. But remember: Tor is not a reliable solution for your LN node !

Why bitcoiners are so "in love" using Tor for their BTC LN nodes?

bitdevs

> Sender can find recipient’s UTXO(s) in payjoin without even broadcasting the final transaction. This attack is described in BIP 77 and 78 however often ignored by privacy advocates.
>
> In a normal bitcoin transaction, the recipient shares their address to receive bitcoin although payjoin requires more information. Recipient needs to share their signed UTXO with the sender to finalize the payjoin transaction. Hence, payjoin cannot be used with untrusted senders.