bitcoin_devs

bitcoin

# 🧠 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)

# 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

# Common-input-ownership heuristic  
(An intro to PayJoin)

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

---

Meet Alice, a new employee at a **chain analysis** firm


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


Her job?  
Track and analyze transactions on the Bitcoin network



Alice’s first onboarding session:   **"common-input heuristic"**

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

> All inputs of a given tx are assumed to be owned by the **same owner**

---

To explain it:

Let’s say Bob buys a coffee from Carol with 1 BTC

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

Looking at this Tx, it's clear that the outputs are:

- 1 BTC payment to Carol  
- 2 BTC change back to Bob

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


---

That’s how input correlation works —  
This is what surveillance companies use to violate your privacy

---

So here’s the question:

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

> What if we could break this heuristic…  
> but still make the tx look totally normal?

---

### PayJoin

**PayJoin** is one way to disrupt this heuristic, allowing a tx to be interpreted in various ways

So now, the same tx — but with PayJoin looks like this:

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

Can you tell who owns what now?
Yeah... pretty hard.

---



Follow [@Bitcoin_Devs](https://twitter.com/Bitcoin_Devs) for more technical bitcoin posts

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

An intro PayJoin: Common-input-ownership heuristic

# CISA: Full-Aggregation & Interactivity issues  

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

---

### Reminder  
In the previous post, we explained:

- **Half-Agg** → Non-interactive  
- **Full-Agg** → Interactive


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



## 🔍 What does "interactivity" mean?

Let’s break it down 👇

---

Creating an aggregate signature requires **communication between participants**

Let’s illustrate this with Alice and Bob
![](https://m.stacker.news/84445)



To create `Sigₐgg`, Alice and Bob must  exchange cryptographic commitments.

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

After sharing commitments, each signer creates a partial signature

Partial signatures are then combined to produce the final aggregate signature

```
Sigₐgg = (∑Rᵢ, ∑sᵢ)
```

---
## ❌ This is the flaw with Full-Agg
![](https://m.stacker.news/84426)


---

## ⚠️ For protocols like CoinJoin or PayJoin,  
Full-Agg introduces **complexity**:

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

---

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

---


## ✅ But Full-Agg works great  
when **one user controls all inputs**

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

---

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

*(Source: HRF CISA Research Paper)*

---

## 🧬 The hybrid approach  
**Combine Full-Agg and Half-Agg**

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


*from: [hrf.org/latest/cisa-research-paper](https://hrf.org/latest/cisa-research-paper)*

---
Follow [@Bitcoin_Devs](https://twitter.com/Bitcoin_Devs)  for more Bitcoin technical posts.

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



CISA: Full-Aggregation & Interactivity issues

Dust Attack explained

 nearly 30% of all the UTXOs have a value of 546 sats 

(from w_s_bitcoin on X)
![](https://m.stacker.news/84356)

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

# 🧹 Dust Attack Explained

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

---

## What is "Dust" in Bitcoin?

Dust refers to **tiny amounts of Bitcoin** that are so small, they become **unspendable** due to high transaction (tx) fees.

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

---

## Why can't dust be spent?

Because the **transaction fees** required to move the dust are **greater than its value**.

> `tx fees > value of the dust`

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

---

### Example:  
If a UTXO is only 300 sats, but it costs 500 sats in fees to spend it, it's considered *dust*.

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

> 💡 Most wallets set the dust limit around **546 satoshis** for legacy addresses.

---

## Why should I care?

Because **dust can be used in attacks to track your transactions**.

---

##  How a Dust Attack Works:

###  Step 1: Attacker sends tiny BTC amounts to your wallet  
Then waits for you to spend them.

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

---

###  Step 2: Linking Addresses  
When you spend the dust, you likely combine it with your real UTXOs.

This links your **real addresses** to the **dust address**.

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

---

###  Step 3: De-Anonymizing  
Once your addresses are linked, attackers can **analyze transactions** and try to **trace your identity**.

---

🔁 Follow [@Bitcoin_Devs](https://twitter.com/Bitcoin_Devs) for more technical breakdowns like this.


# CISA Part 2: Half Signature Aggregation (Half-Agg)

Let’s break down how it works and where it can be used — with diagrams 👇

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

---

## Quick reminder from Part 1

CISA allows multiple Schnorr signatures from different inputs to be combined into **one aggregated signature**.

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

---

## CISA has two modes:

→ Full agg: Interactive  
→ Half agg: Non-Interactive

In this post, we explain **half-agg**.

---

## Half-agg allows signatures to be combined into one  
**WITHOUT signers needing to interact**  
Each signer signs independently, and an aggregator compresses the result later.

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

---

## Why does half-agg save ~50% in size?  
*(If you're not into technical breakdowns, feel free to skip this part 😁)*

---

### BEFORE  
– Each Schnorr sig = 64 bytes  
– So for `n` inputs: `n × 64 bytes`

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

---

### AFTER  
– Keep `R` values  
– Combine all `s` values into one  
➡️ New size: `32 × n + 32 bytes`

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

---

## Based on recent Bitcoin usage...  
Estimated savings using half-agg:  
- ~19.3% space  
- ~6.9% fees  
*(Assumes no major behavior change post-CISA)*

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

---

## Now that we understand how half-agg works…  
Let’s look at **where it can actually be used** 👇

---

### Application #1: Transaction-wide Aggregation  
Combine all input signatures within a single transaction.

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

---

### Application #2: Block-wide Aggregation  
Combine all input signatures across a whole block.

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

---

### Application #3: Off-chain protocols / P2P  
Used for things like Lightning gossip messages — no miner or soft fork required.

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

---

## But there are challenges!!

At the block level, half-agg can:  
– Break adaptor sigs (e.g. DLCs, atomic swaps)  
– Impact reorg recovery of transactions

We’ll explain more in the next post 👇

---

### Follow [@Bitcoin_Devs](https://twitter.com/Bitcoin_Devs) for more Bitcoin technical threads.

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



CISA: Half-Agg explained

CISA (Cross Input Signature Aggregation) explained

forgot to include this important info in the first post 😬 here it is:

from https://hrf.org/latest/cisa-research-paper/

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

will break down this into multiple posts this week

# CISA (Cross-Input Signature Aggregation) Explained

![CISA Overview](https://m.stacker.news/83885)

---

**CISA**  is a way to combine multiple signature from a transaction into one

![Signature Aggregation](https://m.stacker.news/83886)

This is made possible thanks to the **linearity** property of **Schnorr signatures**, which enables aggregation of multiple signatures into a single one.

Originally, CISA was considered for inclusion in **Taproot**, but the idea was abandoned to keep Taproot simple and manageable.

---

> ⚠️ Don’t confuse **CISA** with protocols like **MuSig** or **FROST**  
> **Signature aggregation ≠ Key aggregation**

---

## CISA vs Key Aggregation

### Difference #1: 

![CISA vs Key Aggregation](https://m.stacker.news/83882)

---

### Difference #2:

- **Key Aggregation**: The verifier only needs the aggregated public key and a single message.  
- **CISA**: The verifier needs all the individual public keys and their corresponding messages.

![Verifier Differences](https://m.stacker.news/83883)

---

### Difference #3:

- **CISA** is used during **transaction signing**  
- **MuSig** is used during **address creation**

---

There are two types of CISA: 

- **Half-Agg**
- **Full-Agg**

🧵 *We’ll explain them in upcoming posts.*

![Half-Agg vs Full-Agg](https://m.stacker.news/83884)


---

## More Resources

- [CISA Research](https://cisaresearch.org)  
- [HRF CISA Research Paper](https://hrf.org/latest/cisa-research-paper)  
- [Blockstream CISA GitHub](https://github.com/BlockstreamResearch/cross-input-aggregation)


## BIP-68: Relative LockTime using nSequence

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



### **Bitcoin Has Two Types of Time-Based Transactions:**
1. **Relative LockTime:**  
   - Transaction is locked for a period **after the input is confirmed**  
   - Example: “Spendable **100 blocks after confirmation**.”

2. **Absolute LockTime:**  
   - Transaction is locked **until a specific time or block**  
   - Example: “Spendable **after block 800,000**.”

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

Today we wil cover **nSequence** 👇

---

### **Understanding `nSequence`**
Every Bitcoin **input** has a `sequence` field, which can **delay spending**.  
It makes the input **unspendable** for a set time **after its corresponding output is confirmed**.

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

---

## **How `nSequence` Works?**
Let’s take this scenario:  

> **Bob wants to send Alice 10 BTC but wants to ensure she cannot spend it until 3 days after confirmation.**

1. **Initial Transaction:**  
   - Bob **receives 10 BTC** in a confirmed transaction.

2. **Bob Creates a New Transaction:**  
   - He signs a transaction sending **10 BTC to Alice**.
   - He sets **nSequence = 3 days** (**~432 blocks**).

3. **Effect of `nSequence`:**  
   - Alice **cannot spend** the BTC **before 3 days**.
   - If she tries earlier, **the network rejects the transaction**.
   - After **3 days**, Alice can **spend the BTC freely**.

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

---

## How to Define a Sequence Number?

### 1. Disabled Flag (Bit 31)
- **If set**: BIP-68 is disabled, meaning nSequence has no effect.
- **If not set**: BIP-68 is enabled, allowing relative lock-time.

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

### 2. Type Flag (Bit 22)
- **If set**: The sequence number is interpreted as **time-based** (lock-time in seconds).
- **If not set**: The sequence number is **block-based** (lock-time in block height).
![](https://m.stacker.news/83352)
### 3. Value (Bits 0-15)
- Represents the actual **relative lock-time** value, either in **blocks** (if Type Flag is not set) or in **time units** (if Type Flag is set).
![](https://m.stacker.news/83353)




---
Next Post we will cover **BIP 112- CSV Transaction**

BIP-68 (Sequence number) Explained

We’re running a track at the MIT Bitcoin Expo Hackathon in a few weeks! 

For it, we’re going to stand up a network of bitcoin core nodes and teams will compete to take down as many as possible. 

## First place gets $3k
Participate in person OR remotely. 

[Sign up today!](https://t.co/5vK59isFFd)

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



BDP <> MIT Hackathon

deleted by author

How are mnemonic phrases generated ?

We're experimenting with short videos explaining Bitcoin technical topics!

Our first one covers how to generate a Mnemonic phrase.  

Check it out & let us know what you think! Should we make more? 👀

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

 *Note: This video doesn’t have a voice-over yet—we’re testing the format first!*

HD wallet [Part 2]

# Child Key Derivation [BIP 32]

*This is the third part of our discussion on HD wallets. We will cover Child Key Derivation*}

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

---

## Quick reminder
- In part 1 we started from a source of entropy and generated a seed.
- In part 2 we generated the master key from the seed 

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

Actually in part 2 we generated 3 things from the seed:
- Master private key
- Master public key
- Chain code

## Now, we’ll see how to derive child keys from parents

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

--- 
### Step 1
![](https://m.stacker.news/81503)

### Step 2
![](https://m.stacker.news/81504)


### Step 3
![](https://m.stacker.news/81506)

### Step 4
![](https://m.stacker.news/81507)


### Step 5
![](https://m.stacker.news/81508)

---

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

---

Stay tuned for a video series explaining HD wallets in detail in [Decoding Bitcoin](https://bitcoindevs.xyz/decoding)

(Sneak peek 🤫)


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