bitcoin_devs

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

bitcoin

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



🧠 Bitcoin Dev Mailing List TLDR, Week of Oct 20

📬 **Subscribe at [tldr.bitcoinsearch.xyz](https://tldr.bitcoinsearch.xyz)**  
Stay up to date on the latest in Bitcoin Dev, Lightning Dev, and DelvingBitcoin discussions

---

### 🧾 Summary of Threads Started This Week


A developer experiment on compact block relay in Bitcoin Knots showed a 90% success rate in block reconstruction, suggesting efficient synchronization and improved scalability. More details on [Uncensored Tech Substack](https://uncensoredtech.substack.com/p/compact-block-relay-with-extra-pool).

Bitcoin Core **v29.2** introduces bug fixes, performance enhancements, and updated translations across networking, mempool, RPC, and documentation. Read more on [Bitcoin Core’s official site](https://gnusha.org/pi/bitcoindev/14ad52ca-915a-4cdd-94b1-cf9afce0a4a5n@googlegroups.com/T/#u#m40b78e294b83b48f76a7ffc33cf13b450f0e0068).

Abdel proposes `OP_STARK_VERIFY` for on-chain verification of STARK proofs, enabling scalability, post-quantum signatures, and privacy-enhanced transactions. Community feedback invited [here](https://delvingbitcoin.org/t/proposal-op-stark-verify-native-stark-proof-verification-in-bitcoin-script/2056).

Updated simulations of a new reputation algorithm show strong resistance to network attacks, maintaining transaction reliability while minimizing false positives. Details in [this analysis](https://delvingbitcoin.org/t/outgoing-reputation-simulation-results-and-updates/2069).


---

### 🧵 New Threads This Week

- **[Compact block relay in knots using the extra pool](https://gnusha.org/pi/bitcoindev/CALiT-ZoZFZskPhA6HHguOFyD4=4uEXO-mvXq+FxURO8ELDueZA@mail.gmail.com/T/#u#mf3cfb162cf81d34c9a1b555d9a669e844c5c0e00)** — UTC | newest  
  - 90% success rate in block reconstruction using compact block relay in Bitcoin Knots.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/mf3cfb162cf81d34c9a1b555d9a669e844c5c0e00_Compact-block-relay-in-knots-using-the-extra-pool)

- **[Bitcoin Core v29.2 Released](https://gnusha.org/pi/bitcoindev/14ad52ca-915a-4cdd-94b1-cf9afce0a4a5n@googlegroups.com/T/#u#m40b78e294b83b48f76a7ffc33cf13b450f0e0068)** — UTC | newest  
  - Introduces bug fixes, new translations, and performance improvements.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/m40b78e294b83b48f76a7ffc33cf13b450f0e0068_Bitcoin-Core-v29-2-Released)

- **[Proposal: OP_STARK_VERIFY - Native STARK Proof Verification in Bitcoin Script](https://delvingbitcoin.org/t/proposal-op-stark-verify-native-stark-proof-verification-in-bitcoin-script/2056)** — Abdel  
  - On-chain STARK proof verification proposal for post-quantum and scalable Bitcoin.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/delvingbitcoin/Oct_2025/6071_Proposal-OP-STARK-VERIFY-Native-STARK-Proof-Verification-in-Bitcoin-Script)

- **[Outgoing Reputation: Simulation Results and Updates](https://delvingbitcoin.org/t/outgoing-reputation-simulation-results-and-updates/2069)** — Carla  
  - Updated reputation algorithm improves network robustness against resource attacks.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/delvingbitcoin/Oct_2025/6105_Outgoing-Reputation-Simulation-Results-and-Updates)

---

### 🔥 Active Discussions This Week

- **[[BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus](https://gnusha.org/pi/bitcoindev/CALeFGL0PDjtRt2rfbY4gTkoc+5oNQ0mn_obraE7PrtHuNYFpQw@mail.gmail.com/T/#mf7828a141fb44dc1265d1451ae341806df6b63ad)** — Casey Rodarmor  
  - Ongoing debate between Luke Dashjr and Greg Maxwell on script pubkey changes.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/mf7828a141fb44dc1265d1451ae341806df6b63ad_-BIP-Proposal-Limit-ScriptPubkey-Size-520-Bytes-Consensus-)

- **[Stats on compact block reconstructions](https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/42)** — 1440000bytes  
  - Data on compact block relay performance and efficiency.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/delvingbitcoin/Oct_2025/6081_Stats-on-compact-block-reconstructions)

- **[Sharing block templates](https://delvingbitcoin.org/t/sharing-block-templates/1906/24)** — ajtowns  
  - Discussion on template sharing for improved RBF and block accuracy.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/delvingbitcoin/Oct_2025/6099_Sharing-block-templates)

- **[Eclipsing Bitcoin Nodes with BGP Interception Attacks](https://delvingbitcoin.org/t/eclipsing-bitcoin-nodes-with-bgp-interception-attacks/1965/9)** — cedarctic  
  - Research into fingerprinting and BGP interception attack mitigation.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/delvingbitcoin/Oct_2025/6083_Eclipsing-Bitcoin-Nodes-with-BGP-Interc)

---

📚 Full summaries and sources:

👉 https://tldr.bitcoinsearch.xyz

This Week in Bitcoin Development (Oct 2025, Week 2)

🎓 Bitcoin Scholarship, Apply Now!

FAQs:   https://bitcoinscholarship.xyz/#faq

# 🎓 Bitcoin Scholarship, Apply Now!

**100% of college tuition covered** to support the brightest minds contributing to **Bitcoin open-source development**.

---

### Global • 4 Years • 100% Tuition Covered

- **Global**: open to students from any university, anywhere in the world.  
- **4 Years**: One-year scholarships renewable for up to three additional years.
- **100% Tuition Covered**

---

### Why Apply?
- Full tuition coverage at any university  
- Opportunity to work full-time on Bitcoin open-source projects during summer  
- Renewable funding for up to four years  
- Open to students everywhere, regardless of location  

---

### Past Winner: *Ishaana Misra (2025)*
> “I'm usually the youngest at Bitcoin developer meetups, but I don't think about it much anymore. Your work really speaks for itself. If you're interested, people will take you seriously.”

Ishaana taught herself C++ in high school, ran her own Bitcoin node, and became one of the youngest contributors to **Bitcoin Core**.  
Now a freshman at **MIT** and president of the **MIT Bitcoin Club**.

---

🕓 **Deadline:** November 1, 2025  
🔗 **Apply here:** [bitcoinscholarship.xyz](https://bitcoinscholarship.xyz)

📢 Share this opportunity with aspiring Bitcoin developers around the world.


The Y2038 problem explained

# Year 2038 Problem (Y2K38)

The **Year 2038 Problem** is caused by how some software systems store dates.  
Most software that uses a signed 32-bit integer for time will **overflow** after this exact moment:

> **03:14:07 on 19 January 2038**

One second later, many systems will wrap around to:

> **20:45:52 on 13 December 1901**

---

## Bitcoin and the Timestamp Field

Bitcoin stores the **timestamp** in the **block header**.

> `timestamp = number of seconds since 01 January 1970 (UTC)`

If we store this date using **31 bits**, we run out of space precisely at:  
**2038-01-19 03:14:07**

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



## One Second Later…


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



Luckily, Bitcoin stores timestamps as **32-bit unsigned integers**,  
giving us time until **the year 2106**.

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

---

Fixing this isn’t a small update, it will likely require a **hard fork**.

The **timestamp** is part of the **block header**,  which means any change affects the **block hash itself**.

---

👉 *Follow @bitcoin_devs for more Bitcoin technical*


## Nonce Reuse Attack

_Imagine you want to sign this transaction:_

    tx

_The Schnorr signature equation is:_

    S = k - h(R, P, tx) * x

> Don't worry, we'll explain it step by step!

---

### Step 1: Breaking down the equation

    S = k - h(R, P, tx) * x

- **P** → Your public key  
- **x** → Your private key  
- **tx** → The transaction you are signing  
- **h(...)** → A hash function  
- **k** → The nonce you choose randomly

---

### Step 2: Signing the transaction

Now we have all parameters needed to sign the transaction:

    S = k - h(R, P, tx) * x

When you sign a tx, you choose `k` randomly, that’s your **nonce**.

But let’s say you have a new transaction `tx2`, and you accidentally reuse the same nonce `k`:

    S2 = k - h(R, P, tx2) * x

---

### Step 3: What happens next?

An attacker (or anyone observing both signatures) can compute:

    S - S2 = h(R, P, tx) * x - h(R, P, tx2) * x

Rearrange to recover your **private key**:

    x = (S - S2) / ( h(R, P, tx2) - h(R, P, tx) )

> ⚠️ All of the ingredients on the right-hand side are public:
> - `S`, `S2` are published in the signatures  
> - `h(...)` values can be computed from `R`, `P`, `tx`, `tx2`  
> So your private key `x` is leaked if the same `k` is reused.

---

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

---

# ❌ DON'T REUSE NONCE

Even reusing a single nonce across two signatures leaks your private key. Use a fresh random nonce (or deterministic nonces derived correctly) for every signature.

---

Read more about Nonce Reuse Attack https://bitcoindevs.xyz/decoding/nonce-reuse-attack

Nonce Reuse Attack explained simply

MuSig Explained Simply

You can read more about MuSig here 
https://bitcoindevs.xyz/decoding/musig

# MuSig explained Simply

MuSig is a protocol for aggregating public keys and Schnorr signatures.  
It allows multiple participants (A and B) to jointly sign a transaction as if it came from a single key.

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

---

If we want to spend funds locked in **P_AB**,  
we sign the transaction by aggregating `S_A` and `S_B`:
`S_AB = S_A + S_B`

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

---

**✅ Pros**
- Saves block space  
- Improves privacy  
- Faster verification  

**❌ Cons**
- Requires multiple rounds of interaction between signers

---

Let’s dive deeper into the issue of interactivity

Creating a MuSig signature `S_AB` requires **3 rounds** of communication between A and B:

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

---

## Before explaining the 3 rounds of communication

let me first show you the Schnorr signature equation.

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


where:
- `x` = private key  
- `k` = nonce (you pick it randomly)
- `h = H(R || P || m)`  


---
Each signer computes:
`s_i = k_i + H(X, R, m) * x_i`

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


---

## 🧩 After aggregation

Now the aggregated signature becomes:

`s = (k1 + k2) + H(X, R, m)(x1 + x2)`

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

---

To create the aggregated signature `S_AB`,  
each participant needs the **nonce k** from the other participants.

---

### 🔄 Round 1  
**Exchange nonce commitment**

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


---

### 🔄 Round 2  
**Exchange nonces**


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



---

### 🔄 Round 3  
**Exchange partial signatures**


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


---
After this, each participant can compute the final Schnorr signature:

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

---

## 🧠 MuSig2 Fixes This

It requires **only two rounds** of communication 🎯

We’ll take a deep dive into **MuSig2** in the next post.

---

Follow **@bitcoin_devs** for more Bitcoin technical content with illustrations 

---
