bitcoin_devs

bitcoin

# 📰 TLDR Newsletter – June 9 to June 16

> 📬 Prefer to read via email? Subscribe to our TLDR newsletter: [tldr.bitcoinsearch.xyz](https://tldr.bitcoinsearch.xyz/)  
> 📖 Read this issue directly: [June 9 – June 16 Newsletter](https://tldr.bitcoinsearch.xyz/newsletters/2025-06-02)

---


### 1- Highlights

– [**🚨 Sybil Attack on Libre Relay**](https://gnusha.org/pi/bitcoindev/CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw@mail.gmail.com/T/#mb7e09e4cf5025afb55251e57fadd6eaba37fd471)
Peter Todd revealed a sybil attack targeting Libre Relay nodes to block txs and raise costs for honest relays. Manual peering and Bitcoin Core’s feeler node system are potential defenses.

– [**🔗 Well-Known Bitcoin Identity Endpoint**](https://gnusha.org/pi/bitcoindev/CAEbZFSsA49mnsVia7L-0k9S=oa93nCN4KudHdK8ZnSbboenohw@mail.gmail.com/T/#u#m6ee6a01d2cfe8842946e0812a9726d7213b45d74)
Aviv Bar-el proposed a draft BIP to enable HTTPS-based discovery of Bitcoin contact/payment info, building on the Lightning Address model.

– [**🧬 Post-Quantum Commit/Reveal Proposal**](https://gnusha.org/pi/bitcoindev/CAFC_Vt6gqV-8aoTKt2it1p9LAnvaADueHnC1cM6LQojZf6fjCw@mail.gmail.com/T/#m0085c639b6b596d9aecdc731d3afa917208fb8d4)
Tadge Dryja floated a soft fork idea using commit/reveal to prep Bitcoin for quantum threats without jumping straight to PQ sigs.

---

---

## 2- Recent Threads

- [**Censorship Resistant Transaction Relay - Taking out the garbage(man)**](https://tldr.bitcoinsearch.xyz/posts/626974636f696e2d6465762f4d61795f323032352f636f6d62696e65645f43656e736f72736869702d526573697374616e742d5472616e73616374696f6e2d52656c61792d54616b696e672d6f75742d7468652d676172626167652d6d616e2d-/summary)
**Bitcoin-dev** | 🗣️ Peter Todd, John Carvalho  
  - Sybil attack launched on Libre Relay nodes.  
  - Mitigation via Bitcoin Core's feeler node system.  
  - Manual peering with trusted nodes proposed.

---

- [**Post-Quantum commit / reveal Fawkescoin variant as a soft fork**](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/May_2025/combined_Post-Quantum-commit-reveal-Fawkescoin-variant-as-a-soft-fork)
**Bitcoin-dev** | 🗣️ Tadge Dryja, Nagaev Boris, Sergio Demian Lerner  
  - PQ cryptography integration discussed.  
  - Soft fork with commit/reveal scheme proposed.

---

- [**Sybil resistance in coinjoin implementations**](https://tldr.bitcoinsearch.xyz/summary/delvingbitcoin/May_2025/combined_Sybil-resistance-in-coinjoin-implementations)
**Delving Bitcoin** | 🗣️ 1440000bytes, securitybrahh  
  - Joinmarket uses fidelity bonds to combat sybil attacks.  
  - JoinStr adds aut-ct proofs and optional bonds for flexibility.

---

## 3- Active Discussions

- [**Against Allowing Quantum Recovery of Bitcoin**](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/May_2025/combined_Against-Allowing-Quantum-Recovery-of-Bitcoin)
**Bitcoin-dev** | 🗣️ Agustin Cruz, Jameson Lopp, Sjors Provoost +6  
  - QRAMP proposal: Optional PQ keys → soft fork → deactivation of vulnerable outputs.

---

📚 Stay updated: [tldr.bitcoinsearch.xyz](https://tldr.bitcoinsearch.xyz/)


📰 TLDR Newsletter – June 9 to 16

# 🧠 Lamport Signatures Explained (Visually)

> *Post-quantum signatures built from hash functions. No elliptic curves. No math tricks. Just... hashes.*  
> *Let’s break it down visually 👇*

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



---

### 🧾 Step-by-Step Walkthrough

**1. We want to sign a 256-bit message**

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

---

**2. Generate 256 pairs of secret random numbers**

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

---

**3. Hash each secret to get the public key**


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

---

**4. Hash the message**

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

---

**5. Reveal secrets depending on message bits**

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

---

**6. The revealed secrets form the signature**


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

---

### ✅ How to Verify

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

**1. Hash each revealed secret**

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

---

**2. Compare with the public key**

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

---

**3. If all match, it's valid**


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

---

### ⚠️ Limitation: One-Time Use

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

---

### 💭 Why is this quantum-safe?

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

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

---

### 📌 What’s Next?


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

---

Follow @Bitcoin_Devs for the next post on the "The Burn vs Steal Dilemma"

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

🧠 Lamport Signatures Explained (Visually)

# Commit-Delay-Reveal (CDR) Protocol  (Part 3)

> This is **Part 3** of our visual series on quantum threats to Bitcoin and how we can defend against them.

📚 In case you missed the earlier posts:

- [Quantum vs Bitcoin: A Visual Breakdown (Part 1)](https://stacker.news/items/995113)
- [Quantum Risk to Bitcoin (Part 2)](https://stacker.news/items/997751)

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


---

### 🧠 The Threat: Quantum Computers  



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


Quantum computers can break ECDSA.  
Once your public key is exposed, your funds can be stolen.

---

### 🎯 The Goal  


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

We want to move coins from vulnerable UTXOs (e.g., P2PKH) to a quantum-safe address *without revealing the old key*.


---

### 🛡️ The Solution: Commit-Delay-Reveal  


A protocol with 3 phases:  
Commit ➝ Delay ➝ Reveal

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


---

### 🧩 CDR Phases Overview  


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

**Commit (C)**: You commit to your keys  
**Delay (D)**: You wait for a security window  
**Reveal (R)**: You prove ownership and migrate safely


---

## 🔶 1. Commit Phase  

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

Bob creates a commitment of two keys:
- `pk`: old (ECDSA)
- `pkQR`: new (quantum-safe)

➡️ `H(pk || pkQR)`

---


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

Bob includes this hash in a transaction `T_commit` using `OP_RETURN`.  
This hides the keys, while anchoring the commitment on-chain.

---

## 🟡 2. Delay Phase  

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



Bob waits a period `t_sec` without touching the UTXO.  
This pause prevents attackers from reorg-ing the chain.

---

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

⏳ Suggested delay: **6 months**  
Makes even quantum-powered reorgs too costly.

---

## 🟢 3. Reveal Phase  

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

After the delay, Bob creates `T_reveal` to move the funds using his quantum-safe key `skQR`.

---

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

`T_reveal` must include:
1. `pk` — old key  
2. `pkQR` — new key  
3. `H(pk || pkQR)` — prove it was in `T_commit`  
4. Signature with `skQR`

---

### 🧾 Detailed Breakdown

#### ✅ Step 1: Reveal Old Key  

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

This proves you control the originally locked UTXO.

---

#### ✅ Step 2: Reveal New Key  

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

This is your quantum-resistant key.

---

#### ✅ Step 3: Prove the Commitment  

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

Show that `H(pk || pkQR)` was committed earlier in `T_commit`.

---

#### ✅ Step 4: Sign with Quantum Key  

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

Only someone with the secret key of `pkQR` can authorize the spend.

---

### 🎯 Final Result  

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

The network is convinced:  
The person who controls `pkQR` *also* controlled `pk`.  
The migration is secure.

---

## 🚨 Limitation  

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

To begin the process, users need access to some quantum-safe UTXOs.

---

## ✅ Solution  

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

FawkesCoin protocol solves this by helping bootstrap quantum-safe UTXOs.

---

## 👀 Next Post  

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

We'll dive deeper into FawkesCoin next.

---

## 🤖 Follow for more  

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

Follow [@Bitcoin_Devs](https://twitter.com/Bitcoin_Devs) for more visual explainers on Bitcoin's quantum future.



🛡️ Post-Quantum Commit-Reveal (CDR) Protocol explained

# 🧠 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!*