bitcoin_devs

bitcoin

# Episode 5

A 5-minute animated explainer on the 64-byte transaction bug, how it breaks Merkle proofs, tricks SPV wallets, and why BIP 54 bans them.

Part of the Consensus Cleanup soft fork BIP54.

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

Sources:

* [https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design](https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design)
* [https://github.com/bitcoin/bips/blob/master/bip-0054.md](https://github.com/bitcoin/bips/blob/master/bip-0054.md)
* [https://www.bitmex.com/blog/64-Byte-Transactions](https://www.bitmex.com/blog/64-Byte-Transactions)

The 64-byte Transaction Bug Explained Simply

### Episode 3: Garbled Circuits explained

Visual explainer on garbled circuits, the cryptographic primitive that lets two parties compute a function together without revealing their private inputs.

This is the same technique used in BitVM3s to enable trustless computation



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

Next up in the series: how BitVM 3s uses garbled circuits on Bitcoin.
Follow @bitcoin_devs for more.

Garbled Circuits explained

#### Episode 2: SegWit Address explained

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

Ep 2: Segwit Address

#### Episode 1: Off-by-One Difficulty Bug  

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

Next Episode: Time Warp Attack and How BIP54 Fixes It

Off-by-one difficulty bug explained

In **[Part 1](https://stacker.news/items/1413216)**, we explained the **padding** step of SHA-256.

In this part, we move to the **next step: the Message Schedule**.



```
┌───────┐    ┌─────────┐    ┌──────────────────┐    ┌──────────────┐    ┌──────┐
│ Input │ -> │ Padding │ -> │ Message Schedule │ -> │ Compression  │ -> │ Hash │
└───────┘    └─────────┘    └──────────────────┘    └──────────────┘    └──────┘
                 ↑                    ↑
             Part 1               Part 2 (current)
```

---

## Reminder:


After padding, the message becomes a **single 512-bit block**.

Now this block goes into the **message schedule** step.

```
Input ("bitcoin")
        │
        ▼
┌─────────┐ ---> ┌────────────────────────────────────┐ ---> ┌──────────────────┐
│ Padding │ ---> │ 512-bit padded block               │ ---> │ Message Schedule │
└─────────┘ ---> └────────────────────────────────────┘ ---> └──────────────────┘
                 │  01100010011010010111010001100011  │
                 │  01101111011010010110111010000000  │
                 │  00000000000000000000000000000000  │
                 │  00000000000000000000000000000000  │
                 │  00000000000000000000000000000000  │
                 │  00000000000000000000000000000000  │
                 │  00000000000000000000000000000000  │
                 │  00000000000000000000000000111000  │

```


---

## Step 1: Split Block Into Words

The padded block has:
``` 512 bits total ```

We split it into:
`16 pieces`

Each piece is:
`32 bits`

And each piece is called a **word**.

So we get: `W0, W1, W2, ..., W15`


These come directly from the padded message.
```
w0 = 01100010011010010111010001100011
w1 = 01101111011010010110111010000000
w2 = 00000000000000000000000000000000
w3 = 00000000000000000000000000000000
w4 = 00000000000000000000000000000000
w5 = 00000000000000000000000000000000
w6 = 00000000000000000000000000000000
w7 = 00000000000000000000000000000000
w8 = 00000000000000000000000000000000
w9 = 00000000000000000000000000000000
w10 = 00000000000000000000000000000000
w11 = 00000000000000000000000000000000
w12 = 00000000000000000000000000000000
w13 = 00000000000000000000000000000000
w14 = 00000000000000000000000000000000
w15 = 00000000000000000000000000111000
```

---

## Step 2: Notice We Need More Words

The compression step needs:

`W0 → W63 (64 words total)`

But we only have:
`W0 → W15`

So we must **compute 48 additional words**:
`W16 → W63`

---
## Step 3: How New Words Are Built


Each new word is computed from **four earlier words**

So every new word depends on previous schedule values.

Example for W16:
```W16 = W0 + σ0(W1) + W9 + σ1(W14)```

We reuse earlier words to generate new ones.

---

## Step 4: Bit Mixing Functions σ0 and σ1

The functions σ0 and σ1 mix bits using rotations and shifts:

```
σ0(x) = ROTR7(x) XOR ROTR18(x) XOR SHR3(x)
σ1(x) = ROTR17(x) XOR ROTR19(x) XOR SHR10(x)
```

These operations spread information across bits.

Check https://hashexplained.com/ for more details about σ0 and σ1

---

## Step 5: General Rule for All Remaining Words

All later words are computed using:
```
W[t] = W[t-16] + σ0(W[t-15]) + W[t-7] + σ1(W[t-2])
```

Repeat this until: *W63 is computed*

After computing everything:
```
w16 = 10111000111111010101100100111010
w17 = 01101111100001000110111010000000
w18 = 00000111100101000011010000110111
w19 = 10111010100010111101101100101001
w20 = 10011100100111001000011000110101
w21 = 10010110110111110100100011100010
w22 = 11010011111110110101101100110100
w23 = 00000110010001100000011110100000
w24 = 00110110010011000111101111010100
w25 = 11001010101110011100011010100001
w26 = 01101101001010001110101000011010
w27 = 01111000010100101111100010101111
w28 = 11111111001101000111100111101101
w29 = 11110111010101111010001011010001
w30 = 00101010010010001001010100001001
w31 = 10001111011111001000110001011111
w32 = 11110010011101011110000100001111
w33 = 00011000001001011011000100010111
w34 = 01111111011011111100100101100011
w35 = 10000001100101111000101001111101
w36 = 10110111010001010010011011101000
w37 = 10011010100011101001110000110100
w38 = 01011100001010001101000100000000
w39 = 01000110110001101000000001111110
w40 = 11101100100100111001011010000111
w41 = 11011110010001001100000111111100
w42 = 10011000001110011100100011000101
w43 = 00000010111100100001110101110100
w44 = 11001100110011111010111001010100
w45 = 11010010111101000111101010001010
w46 = 00100001110010010110110011101000
w47 = 10101000000110100101110010011110
w48 = 10101110000011010100010011011010
w49 = 01010001101000011111101011011010
w50 = 10010110111011100010011010101011
w51 = 10011110110001010100011010101100
w52 = 00111111010010001000101110110010
w53 = 00000111011110011101001110001111
w54 = 10101101001011101000010011001011
w55 = 11000000011101100011000101011000
w56 = 10100011000110001010000000100001
w57 = 00111101111100000111101011100111
w58 = 11101010010000011101101001100000
w59 = 11001111111100000000100000100011
w60 = 10111011111010100100110100011010
w61 = 00010100100010100001100010001111
w62 = 00010000101101010110001110000111
w63 = 10001100001100010110000010100010
```

At this point, the message schedule is complete.


---

## Next Step

Now the **64 words** are ready.

They are passed into the **compression function**, which produces the final hash state.

```
┌───────┐    ┌─────────┐    ┌──────────────────┐    ┌──────────────┐    ┌──────┐
│ Input │ -> │ Padding │ -> │ Message Schedule │ -> │ Compression  │ -> │ Hash │
└───────┘    └─────────┘    └──────────────────┘    └──────────────┘    └──────┘
                 ↑                    ↑                     ↑
             Part 1                Part 2               Part 3 (next)
```
---

## Summary

Padding step ✔  
Message schedule ✔  
Next: Compression step

---

## Learn More

You can see the message schedule step animated here:

https://hashexplained.com

SHA-256 Explained: Message Schedule

# **SHA-256, Part 1: Padding**

SHA-256 is used everywhere in Bitcoin.

We usually think of hashing as:

```
Input → [ Black Box ] → Hash
```

---

## **Let’s peek inside the black box**

SHA-256 has three internal steps:

```
Input
  ↓
+----------------------+
|  Padding             |
|  Message schedule    |
|  Compression         |
+----------------------+
  ↓
Hash
```

Today we focus only on **Padding**.

---

## **Example input**

We’ll hash the string:

```
"bitcoin"
```

---

## **Step 1: Convert characters to ASCII**

```
'b' → 98  → 01100010
'i' → 105 → 01101001
't' → 116 → 01110100
'c' → 99  → 01100011
'o' → 111 → 01101111
'i' → 105 → 01101001
'n' → 110 → 01101110
```

Concatenate all bytes:

```
01100010011010010111010001100011
011011110110100101101110
```

Total: `7 bytes = 56 bits`

---

## **Step 2: Append a `1` bit**

This marks the end of the message:

```
01100010011010010111010001100011
0110111101101001011011101
```

(`…1` bit added at the end)

---

## **Step 3: Add length**

Compute original message length:

```
Message: "bitcoin"
Chars: 7
Bits/char: 8
Total bits = 7 × 8 = 56
```

Convert `56` to a 64-bit big-endian binary:

```
0000000000000000000000000000000000000000000000000000000000111000
```

Append it (big-endian):

```
[message]1 [zeros 😴] [64-bit length]
```

---

## **But we’re not done yet…**

SHA-256 works in **512-bit blocks**

Currently we have:

```
Message: 56 bits
"1" marker: 1 bit
Length: 64 bits
----------------------
Total: 121 bits
```

We need `512` bits total:

```
512 − 121 = 391 zero bits
```

So we add **391 zeros** between the marker and the length.

---

## **Final padded block**

Structure:

```
[ 56-bit message ]
[ 1-bit "1" marker ]
[ 391 zeros ]
[ 64-bit length ]
```

This forms **one full 512-bit block**

---

## **Next step: Message schedule**

Now we take the padded block and pass it through the **message schedule**, which expands it into `W[0..63]` for compression.

You can watch this padding step live at:

➡ https://hashexplainer.com



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

Repo: https://github.com/bitcoin-dev-project/hashes-visualizer

SHA-256 explained: Padding

SHA-256 is everywhere: bitcoin, TLS, Git, proofs, ...

Yet most explanations skip the internal mechanics and jump straight from:

> `Input → black box → hash`

Which is fine for beginners, but it leaves out the interesting part: how the message is padded, how W[0..63] is generated, and how all 64 rounds update the internal state.

We built a tool that shows those steps in real time.

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

**Live Demo:** https://hashexplained.com/  
**Source (MIT):** https://github.com/bitcoin-dev-project/hashes-visualizer

**What it shows:**
• message preprocessing & padding  
• the 64-word schedule (W[0..63])  
• round constants & bitwise functions  
• (a..h) updating each round  
• final digest construction

---

*Reference: [NIST FIPS 180-4: Secure Hash Standard](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf)*

🎉 Interactive SHA-256 visualizer

**Only ~24 hours left to apply for the 2026 ₿OSS Challenge 🚨**

Applications close on December 31st, and once you’ve applied, you’ll have until January 12th to complete the Saving Satoshi challenge.

---

Get funded by Spiral, BTrust, Blockstream, Brink and others to contribute to something meaningful.

Apply for the BOSS Challenge today http://bosschallenge.xyz

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




~24 hrs left - Apply for the 2026 ₿OSS Challenge 🚨

bitdevs

₿OSS Challenge 2026 | Start Your Career in Bitcoin Open Source Software

ajonas

I think you might be referring to the old bitcoin/Lightning seminars that Chaincode used to run.

The BOSS Challenge is a different program, you can read more about it here: https://bosschallenge.xyz


> i guess 25-40 on the discord in my cohort last year

Last year the program definitely had way more than 25–40 people on Discord

# The Quadratic Sighash Problem 

Before SegWit, there was a serious scalability issue in Bitcoin called the **Quadratic Sighash problem**.

It made signature validation slow, especially for transactions with many inputs, and opened the door to denial-of-service attacks.

---

## What Happened?

In 2015, F2Pool mined a block containing one huge [“mega-transaction”](https://mempool.space/tx/bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08) (≈1 MB, 522 inputs). 

It took about **25 seconds** for a full node to validate just *that* transaction.

Slow validation means fewer people can run full nodes  
→ which increases the risk of centralization.

---

## Why Does It Happen?

Imagine a transaction with **2 inputs**.

To verify each signature, Bitcoin must hash a *modified* version of the transaction.

So for 2 inputs, we hash **2 different messages**:

    Input #1 → message #1  
    Input #2 → message #2  

So far, this looks linear:  
2 inputs → 2 messages

---

## The Trick: Each Message Contains *All* Inputs

When signing input *i*:

- include **every input**
- but remove `scriptSig` from all other inputs  
  (so they can't change the message being signed)

That means each input needs its own *version* of the transaction to hash.

So with 2 inputs:

    2 inputs × 2 messages = 4 hashing operations

---

## Scaling Up

Now imagine **3 inputs**:

Each message now contains 3 inputs:

    3 inputs × 3 messages = 9 units of work

In general:

    n inputs  →  n × n  =  n²  hashing work

That’s why it’s called **Quadratic Sighash** -> cost grows as n².

---

### Example Table

| Inputs | Messages | Total Work |
|--------|----------|------------|
| 1 | 1 | 1 |
| 2 | 2 | 4 |
| 3 | 3 | 9 |
| 10 | 10 | 100 |
| 100 | 100 | 10,000 |

---

## Why This Was Dangerous

A miner could include a single huge multi-input tx that takes seconds/minutes to validate.

- Slow full nodes can’t keep up
- They fall behind the chain tip
- They aren’t participating in consensus
- Network centralizes to only fast validators

---

## Why "just limit transaction size" failed

Proposed fix: cap tx size to 100 KB.
Rejected because:
❌ Doesn't fix root cause
❌ Just delays the attack
❌ Breaks legitimate large-input transactions (eg batching)

---

## SegWit Fixed This

SegWit changed how transactions are serialized and hashed. It reduced sighash cost back to **O(n)** (we’ll explain it in the next posts)

Follow [@Bitcoin_Devs](https://stacker.news/bitcoin_devs) for more technical explainers.


Quadratic  Sighash problem O(n²) explained

# MuSig2 Explained 

> Schnorr multisignatures in 2 rounds instead of 3 -> no malleability, DoS-resistant, and secure against rogue-key attacks.
> 
> If you missed the previous post about the 3-round MuSig Schnorr signature, check it out here: https://stacker.news/items/1253021

---

##  Reminder: MuSig1
MuSig1 required **3 rounds of communication** between signers:  
1. Share public keys  
2. Exchange nonce commitments  
3. Exchange partial signatures  


➡️ MuSig2 reduces this to **only 2 rounds**

---

##  MuSig2 Flow

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

### ROUND 1  
Each participant generates:  
- Private key `p`  
- Two nonces `r', r''`  
- Nonce commitments `R', R''`  

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

They exchange:
- Public keys  
- Nonce commitments

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

At the end of Round 1, both compute:  

```
P = a₁P₁ + a₂P₂
```
Where `a₁` and `a₂` prevent rogue-key attacks (see previous post: https://stacker.news/items/1251429)


---

## 🔐 ROUND 2: Signing

The signers compute the aggregated nonce:

```
R₁ = R₁′ + b·R₁″
R₂ = R₂′ + b·R₂″
R = R₁ + R₂
```
Where the coefficient `b` is:
`b = H(P || R′ || R″ || m)`

---

### ❓ Why do we use **b** and **two nonces**?

**Answer:**  
The hash coefficient `b` prevents a signer from cheating by changing their nonce after seeing others’.  
Because `b` depends on all public nonces + the message, any modification breaks the final signature.

In short:  
- 2 nonces = protection against nonce tampering  
- `b` = binds all signers to their nonce choice (via hashing)

---


Now each signer creates their partial signature:

```
s₁ = r₁′ + b·r₁″ + H·a₁p₁
s₂ = r₂′ + b·r₂″ + H·a₂p₂
```

Final sig:
`(R, s = s₁ + s₂)`


---

## ✅ Verification
`sG = R + H*P`

If this holds → signature valid.

---

## TLDR
MuSig2 keeps security of MuSig1, but reduces interaction from 3 rounds → 2 rounds.

---



MuSig 2 Explained

📝 **Bitcoin Core Dev Tech Meeting (Oct 2025) — Transcripts Now Live**

Last week, many Bitcoin Core developers met in Frankfurt for the bi-annual in-person Dev Tech meetup.  
18 unconference-style sessions were held, covering topics like:

- ASMap  
- Secp256k1 & quantum  
- CISA  
- Cluster mempool  
- Libsha  
- Multiprocess & mining interface  
- Silent Payments  
- MuSig2  
- Fuzz testing  
- Mempool & relay policy  
- Consensus cleanup  
...and more.

Notes are now fully published on **btctranscripts.com**:
👉 https://btctranscripts.com/bitcoin-core-dev-tech/2025-10/  
*(18 transcripts, all searchable & linkable)*

---
**Related PR**
Schmidty opened the PR to include these in the archive:  
https://github.com/bitcointranscripts/bitcointranscripts/pull/593 *(merged ✅)*

---

*Bitcoin Transcripts unlocks the wisdom, knowledge, and history from Bitcoin tech podcasts, presentations, and other audio-visual media. We make technical Bitcoin knowledge more accessible to learners, builders, and educators.*

📝 Transcripts - Bitcoin Core Dev meetup (Oct 2025)

### Bitcoin Dev, Weekly Digest (Oct 27 – Nov 3, 2025)

**Subscribe at [tldr.bitcoinsearch.xyz](https://tldr.bitcoinsearch.xyz)**  
Stay up to date on the latest in Bitcoin Dev, Lightning Dev, and DelvingBitcoin discussions — weekly briefings for Bitcoin builders, educators, and contributors.

---

### 🧾 Summary of Threads Started This Week

The **segOP proposal** by Defenwycke introduces a dedicated, full-fee data lane for structured on-chain data storage, similar to SegWit but focused on data rather than signatures, via `OP_SUCCESS184` and TLV encoding — designed as a soft fork ([source](https://gnusha.org/pi/bitcoindev/c38d00f7-a42b-4f7b-899e-11e823a43d7dn@googlegroups.com/T/#mf683b1ff5f6ba3f101591147e5535e348a8cc3f6)).

**Juan Alemán** recommends separating consensus rules from policy code in Bitcoin Core to decentralize influence and avoid repo-level policy friction — sparked by changes included in v30 ([source](https://gnusha.org/pi/bitcoindev/73a08ea3-b9be-424b-a1cb-beac3206723cn@googlegroups.com/T/#m0c13517852b39de3778fe8ccac5e065179fdbca8)).

**Jakob Widmann** proposes Anticipation Transactions (ATX), a miner-validated transaction forwarding scheme intended to scale Bitcoin without Lightning Network complexity — includes timelocks and miner incentive changes ([source](https://gnusha.org/pi/bitcoindev/55e36b59-76c2-4ffc-8f36-9a9a0c2fc02bn@googlegroups.com/T/#u#m8c41fc694d5cdefdc319b2a39da7c8ea44321896)).

Bitcoin Core **v31.0** celebrates 10 years of `libsecp256k1`, now significantly outperforming OpenSSL for ECDSA on `secp256k1`. Continuous optimizations demonstrate the value of specialized cryptography libraries in Bitcoin ([source](https://delvingbitcoin.org/t/comparing-the-performance-of-ecdsa-signature-validation-in-openssl-vs-libsecp256k1-over-the-last-decade/2087)).

---

### 🧵 New Threads This Week

- **[segOP potential BIP discussion](https://gnusha.org/pi/bitcoindev/c38d00f7-a42b-4f7b-899e-11e823a43d7dn@googlegroups.com/T/#mf683b1ff5f6ba3f101591147e5535e348a8cc3f6)** — defenwycke  
  - Full-fee, structured data in Bitcoin via soft-forked "segOP" path.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/mf683b1ff5f6ba3f101591147e5535e348a8cc3f6_segOP-potential-BIP-discussion)

- **[[Pre-BIP] Bitcoin Node Repository Consensus-Policy Separation](https://gnusha.org/pi/bitcoindev/73a08ea3-b9be-424b-a1cb-beac3206723cn@googlegroups.com/T/#m0c13517852b39de3778fe8ccac5e065179fdbca8)** — Juan Alemán  
  - Repo split proposed to isolate consensus from policy and avoid forks.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/m0c13517852b39de3778fe8ccac5e065179fdbca8_-Pre-BIP-Discussion-Bitcoin-Node-Repository-Consensus-Policy-Separation)

- **[[Concept] Anticipation Pool](https://gnusha.org/pi/bitcoindev/55e36b59-76c2-4ffc-8f36-9a9a0c2fc02bn@googlegroups.com/T/#u#m8c41fc694d5cdefdc319b2a39da7c8ea44321896)** — Jakob Widmann  
  - Miner-approved pre-confirmed TXs to reduce chain load.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/m8c41fc694d5cdefdc319b2a39da7c8ea44321896_-Concept-Anticipation-Pool-Off-chain-scaling-using-miner-validated-transaction-forwarding)

- **[[BIP] Soft Fork Compromise on `op_return`](https://gnusha.org/pi/bitcoindev/CAKaEYhKdhJ1vP5BBYNAMF7557M9dSoQx8_uqjdAzRM3DgA6ajg@mail.gmail.com/T/#md78dd9ec79c646a2c494c36ca936f7b6cb55a1ec)** — Majorian  
  - Cap `op_return` usage to resolve post-Core-30 tensions.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/md78dd9ec79c646a2c494c36ca936f7b6cb55a1ec_-BIP-Proposal-Soft-Fork-Compromise-on-op-return-to-Resolve-Current-Bitcoin-Controversies)

- **[OP_CIV — Post-Quantum Signature Aggregation](https://gnusha.org/pi/bitcoindev/CAKEeUhhagHCBCd+dgddq8xG4285u_2Li0vKLxvVsdQkGH3gL-w@mail.gmail.com/T/#m0f0100c6667d73adc287c55c749f7b5546afcd9b)** — Tadge Dryja  
  - Post-quantum signature aggregation to reduce chain bloat.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Nov_2025/m0f0100c6667d73adc287c55c749f7b5546afcd9b_OP-CIV-Post-Quantum-Signature-Aggregation)

- **[Comparing OpenSSL vs libsecp256k1 ECDSA validation speeds](https://delvingbitcoin.org/t/comparing-the-performance-of-ecdsa-signature-validation-in-openssl-vs-libsecp256k1-over-the-last-decade/2087)** — theStack  
  - 10-year milestone of `libsecp256k1` confirms its dominance.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/delvingbitcoin/Nov_2025/6180_Comparing-the-performance-of-ECDSA-signature-validation-in-OpenSSL-vs-libsecp256k1-over-the-last-decade)

- **[Public Disclosure: HTLC-based DoS in Cashu](https://delvingbitcoin.org/t/public-disclosure-denial-of-service-using-htlc-in-cashu/2090)** — 1440000bytes  
  - Vulnerability fixed via preimage validation in nutshell v0.18.0.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/delvingbitcoin/Nov_2025/6185_Public-Disclosure-Denial-of-Service-using-HTLC-in-Cashu)

---

### 🔥 Active Discussions

- **[[BIP] Limit ScriptPubkey Size ≥ 520 Bytes](https://gnusha.org/pi/bitcoindev/CALeFGL0PDjtRt2rfbY4gTkoc+5oNQ0mn_obraE7PrtHuNYFpQw@mail.gmail.com/T/#m38e50bcfa5ec9f4dffe214d8cd63e9bfdd8a4919)** — Michael Tidwell  
  - Debates on scalability, UTXO bloat, and reindex feasibility.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/m38e50bcfa5ec9f4dffe214d8cd63e9bfdd8a4919_-BIP-Proposal-Limit-ScriptPubkey-Size-520-Bytes-Consensus-)

- **[Embedding data into Schnorr](https://gnusha.org/pi/bitcoindev/31d18bd9-62e0-4035-b04f-f70ff4253257n@googlegroups.com/T/#m0d703f6fb14b82e13a88b5dffbe17b82e6dd1a37)** — Tim Ruffing  
  - Is data embedding compatible with security proofs in prime-order groups?

- **[[BIP] Reduced Data Temporary Softfork](https://gnusha.org/pi/bitcoindev/CALiT-ZrT+R7ApsQJOtKM5h5xTThGL-WMyCRDwt29sXmt4AA+Rg@mail.gmail.com/T/#m6368287f3ba447f5ec165d8552368170f4faab30)** — Jal Toorey  
  - Temporary compromise to reduce block data rates.

- **[Stats on compact block reconstructions](https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/44)** — 0xB10C  
  - Block relay efficiency with updated `minrelayfee` policies.

- **[Bitcoin Embracing MimbleWimble](https://delvingbitcoin.org/t/bitcoin-embracing-mimblewimble/2081/3)** — REDBaron  
  - Grin's data-less design and its fungibility benefits.

---

📚 Full summaries and sources:  
👉 [tldr.bitcoinsearch.xyz](https://tldr.bitcoinsearch.xyz)


This Week in Bitcoin Development (Oct, Week 4)

# Final reminder, applications close today!

The Bitcoin Scholarship covers **100% of university tuition** for students who want to contribute to Bitcoin open-source development.

- Full tuition for up to 4 years  
- Open to students worldwide  
- Any university, any country  

👉 Apply now: https://bitcoinscholarship.xyz/

---
💸 **Referral reward:**
Help us find the next great Bitcoin dev.
Refer someone who gets accepted and receive **1,000,000 sats**.

If you know a student who should apply, send this their way 🙏


🚨 Last day to apply for the Bitcoin Scholarship!

BIP 158: Compact Block Filters

Golomb-Rice encoding

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

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

## **BIP 158: Compact Block Filters**

Before BIP 158, Bitcoin light clients used **Bloom filters (BIP 37)** to detect relevant transactions.  
However, Bloom filters had **privacy and trust issues**
-  they revealed transaction info to full nodes 
- and increased the server workload, since each node had to process filters individually.

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

---

**Compact Block Filters (BIP 158)**  
Fix both issues by letting full nodes compute **deterministic filters** once per block and share them with light clients.  
Light clients can now check if a block contains relevant transactions *without revealing what they’re looking for.*

✅ Reduced server workload  
✅ Increased privacy

---

### How it works

Each full node constructs a deterministic filter for every block, containing all **scriptPubKeys** of inputs and outputs.

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




Light clients download these filters to check if any transaction matches their own addresses or scripts.

---

If a light client requests a filter for *block 20*,  
the node just sends it, no extra computation needed.

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

The client then checks:
- If **match →** request the full block  
- If **no match →** skip it

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

Efficient and private.

---

**Steps to create a filter:**

1. Collect all `scriptPubKeys` from inputs and outputs.  
2. Convert them to uniform numbers.  
3. Sort numbers.  
4. Calculate differences between successive numbers.  
5. Compress using **Golomb-Rice coding**.  
6. Combine into a compact filter for the block.

---

**Example:**

Suppose a block has 3 transactions:  

```
Tx1: A → 1      BTC      to → B
Tx2: C → 0.5    BTC      to → D
Tx3: E → 2.    BTC       to → F
```


For each transaction, we collect all `scriptPubKeys`:  
`{1A, 1B, 0C, 0D, 2E, 2F}`

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


Then:

- Map objects to numbers (e.g., [3, 7, 15, 19, 28, 34])  
We'll map each object to a number uniformly distributed in a range, e.g., [0, 35].

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

- Store the differences between numbers ([3, 4, 8, 4, 9, 6])  
Instead of storing the numbers, we store the differences between successive numbers

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

- Compress with **Golomb-Rice encoding** using M=4  
To compress further. 
For each number in the list of differences, we calculates the quotient (number // M) and remainder (number % M).

Let's assume M = 4:

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

- Encode quotients (unary) + remainders (binary)  

- Concatenate to create the final encoded filter

Resulting in something like:  
`"011 1000 11000 1000 11001 1010"`

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

---

Light clients can now verify if any of their addresses match entries in this filter.  
If a match exists → request full block → verify and process the relevant transaction.


---

*Follow for more bitcoin technical explainers like this one.*


⚠️ CVE-2012-2459 explained

> This is really helpful! I love these explainers of CVEs.

will make some explainers for the CVEs disclosed today 

https://bitcoincore.org/en/2025/10/24/disclose-cve-2025-46598/

> how is it possible that in Block B it has the same transaction twice? I would have thought this was something that violated validation rules 

That’s exactly what the fix for CVE-2012-2459 addressed. After Bitcoin 0.6.1, core rejects blocks with duplicate txs.

commit for the fix in Core

https://github.com/bitcoin/bitcoin/commit/be8651dde7b59e50e8c443da71c706667803d06d

# CVE-2012-2459: Duplicate Transaction Merkle Root Collision

This vulnerability allowed **two different Bitcoin blocks** to produce the **same Merkle root**, which could cause a node to drop out of consensus.

---
## - Block A

Let’s imagine we have **Block A** with three transactions:  [`Tx1`, `Tx2`, `Tx3`]

---

The Merkle tree for this block is constructed as:

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

---

Since we have an **odd number of txs (leaves)**,  
the **last element is duplicated** to make an even count.

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


---
The Merkle root for this block is calculated as:

Merkle root = `H(Node1 || Node2)`  
where  
- `Node1 = H(H(Tx1) || H(Tx2))`  
- `Node2 = H(H(Tx3) || H(Tx3))`

---

### - Block B

Now let’s take another **Block B** with four transactions:  [`Tx1, Tx2, Tx3, Tx3`]

We calculate it's merkle root

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

---

The Merkle root for this new block is the same as the previous one

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

That means **TWO DIFFERENT BLOCKS** produce the same Merkle root.

---


This can cause a node to **drop out of consensus**.  
Here’s how:

1. If a node receives the **invalid Block B** first, it will reject it  and **mark the block hash as invalid**.
2. Bitcoin Core caches invalid blocks by their hash.


---


Later, if that node receives the **valid Block A**,  
it will **refuse to accept it**,  
because it already marked that block hash as invalid.

---

Bitcoin Core fixed this by:
- Rejecting blocks with **duplicate transaction IDs**
- Without caching the block as permanently invalid

---

### 📢 Coming Next

In our next posts, we’ll explain the **4 new vulnerabilities** disclosed this week by the Bitcoin Core 👇

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

*Follow @bitcoin_devs so you don’t miss it!*


Discreet Log Contracts (DLC)

Math behind DLC

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

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

# 🎲 Discreet Log Contracts (DLC)

DLCs allow parties to place *bets* directly on Bitcoin.

---

### Let's say there are three people involved:

- **Alice** & **Bob** → Contract Makers  
- **Olivia** → Oracle  

> **Oracle** = a trusted party who provides data from the outside world.

---

### 🪙 Game Setup

Alice & Bob bet on the outcome of a coin toss:

- Alice chooses **“Heads”**  
- Bob chooses **“Tails”**

---

### 1. Contract Creation

They place their bet money in a **2-of-2 multisig (Funding Tx)**:


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

Each party sends 1 BTC.  
The winner receives 2 BTC.

---

### 2. Contract Execution Transactions (CETs)

They also create **two commitment transactions**, each representing a different outcome:

- **CET 1:** 2 BTC → “Heads” PubKey  
- **CET 2:** 2 BTC → “Tails” PubKey

---

### ⚙️ Execution

Both CET 1 & 2 spend from the same Funding Tx.  

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


The oracle determines that the result is **“Heads.”**

> The oracle *publishes* the corresponding **“Heads” signature.**

Since the result is Heads:  
- **CET 1** is the valid transaction.  
- **2 BTC** go to the “Heads” PubKey.


`Head_Pk = PubAlice + sheads * G`


Because Alice chose “Heads,” she receives the 2 BTC.

---

### 🌐 Settlement

CET 1 is broadcast to the network,  
and the winner (Alice) receives the 2 BTC.

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

---


Follow @bitcoin_devs for more *Bitcoin technical explainers*

