bitcoin_devs

bitcoin

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

Child Key Derivation [Part 3]

HD Wallet (BIP-32) explained

## Hierarchical Deterministic Wallets [PART 2]  
*This is the second part of our discussion on HD wallets. We will cover the transition from **Seed** to **Master Key**. In Part 3, we will explore Child Key Derivation.*  

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

---

### Quick Reminder  
In the first part, we started from a source of entropy and generated a seed.  

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

As the tree grows from the seed, it branches out, each leading to more branches.  

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

### 3 Steps to Go from Seed to Master Key  

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

---  
### NEXT POST: Child Key Derivation from Master Key (Stay Tuned)  

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

---

Learn more about Bitcoin’s technical concepts at [Decoding Bitcoin](https://bitcoindevs.xyz/decoding).  


Ooh that’s a great breakdown! Have you made a post for the other parts as well?