bitcoin_devs

bitcoin

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 

---


#  Rogue Key Attack in Multi-Signatures

Alice and Bob want to create a multi-signature together.  
They use the **Schnorr signature scheme**.

---

### Reminder
Schnorr signature equation:
`s = r + H(X, R, m)x`  
Verification: `sG = R + H(X, R, m)X`

---

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

---

Everything seems fine so far… but consider if **Bob claims his key is X₂′ = X₂ − X₁** 🤔  
Then the aggregate key becomes 
`X₁ + X₂′ = X₂` 

which means **Bob can sign alone!**

➡️ That’s the **rogue key attack**.

---

(Follow-up: key aggregation schemes like MuSig fix this.)

---

*Follow @Bitcoin_De for more Bitcoin technical explainers.*


Rogue Key Attack Explained Simply

Selfish Mining Explained Simply

You can also read the math behind α in Warren’s reply on X

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


https://x.com/AchimWar/status/1975600429871603971

## Selfish Mining Explained

Selfish mining is a strategy used by miners to gain more profits  
by **not immediately broadcasting newly found blocks** and keeping them secret.

---

### ⚙️ Scenario
Imagine two miners — Alice and Bob — competing to extend the same blockchain.

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

---

### 🧩 How It Works
**Round 1:** Alice finds a block but doesn’t broadcast it (keeps it secret).  
**Round 2:** Bob mines a block and broadcasts it.  
**Round 3:** Alice mines another secret block and then publishes both, creating a longer chain.

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

---

### 💰 Outcome
The network adopts Alice’s chain since it’s longer,  
and she earns a greater reward for both blocks.

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

Selfish mining becomes profitable when **α > 33%**,  
where α is the miner’s share of the total computational power.

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

*From: https://eprint.iacr.org/2014/007.pdf*

---

🧡 *Follow for more Bitcoin visual explainers.*


### 🧠 Bitcoin Dev Mailing List TLDR — Week of Oct 1st, 2025

Here’s a summary of new and active Bitcoin Dev and DelvingBitcoin discussions this week.  

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

---

#### 🧾 Summary of Threads Started This Week

AdamISZ, under the pseudonym waxwing, explores the complexities of embedding data within Schnorr signatures, specifically within the tuple format outlined by BIP340. He concludes that such embedding compromises the security of the unspent transaction outputs (UTXOs) by potentially revealing the private key, challenging previous notions that alternative methods might avoid such security breaches. This analysis not only addresses technical concerns but also raises broader questions about the implications for blockchain privacy and security, inviting further discussion and critique on these findings through his work available on [GitHub](https://github.com/AdamISZ/schnorr-unembeddability).

Coperbyte Solutions introduces an innovative proposal for "Emoji Seed Mnemonics for Deterministic Keys," aiming to simplify the interaction with cryptographic keys through a visual mnemonic system. This system, designed to be backwards-compatible with the BIP-39 wordlist, facilitates a more intuitive and language-independent method for managing keys, enhancing user accessibility without altering the existing security infrastructure. Detailed documentation and invitation for community feedback highlight the collaborative effort to refine this proposal, available for review at [https://emojiseed.comreadme](https://emojiseed.comreadme) and [https://github.com/emojiseed/bip-emojiseed](https://github.com/emojiseed/bip-emojiseed).

Blocktraveler addresses the challenges associated with importing private keys into Bitcoin Core descriptor wallets, proposing a Python-based tool and an 'importprivkeys' RPC call to streamline this process. This initiative reflects a broader effort within the Bitcoin development community to enhance the usability and accessibility of digital asset management, with further details and the technical proposal accessible on [Gist](https://gist.github.com/blocktraveler/3e6198c698a272bd8b13b16e0f13d390).

Sindurasaraswathi's research into threshold signatures for Bitcoin transactions after the Taproot upgrade offers a nuanced analysis of setting optimal thresholds to balance security benefits against the risk of self-lockout. Through dynamic models, this work provides a conceptual framework for managing threshold signatures and suggests evolving strategies to adapt to changing security conditions. This significant contribution to the Bitcoin ecosystem's understanding of threshold signatures is detailed further in the [GitHub repository](https://github.com/sindurasaraswathi/Optimal_Threshold_Signatures).

---

#### 🧵 New Threads This Week

- **[On (in)ability to embed data into Schnorr](https://gnusha.org/pi/bitcoindev/aN21KbXTORgXAVH0@mail.wpsoftware.net/T/#m27239f8a634b8db07be258948dba65795f3af9ef)** — by waxwing / AdamISZ  
  - Embedding data risks revealing private keys and compromising UTXO security.  
  - Contributors: Greg Maxwell, Andrew Poelstra, Peter Todd  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/m27239f8a634b8db07be258948dba65795f3af9ef_On-in-ability-to-embed-data-into-Schnorr)

- **[[BIP Draft] Emoji Seed Mnemonics for Deterministic Keys](https://gnusha.org/pi/bitcoindev/66bd5da8-9114-4ddc-b926-c9349c57e8c3n@googlegroups.com/T/#ma46bae528a1c0c4307afe213467fd9fce22dbc1d)** — by Coperbyte Solutions  
  - Introduces emoji mnemonics for deterministic keys, backward-compatible with BIP-39.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/ma46bae528a1c0c4307afe213467fd9fce22dbc1d_-BIP-Draft-Emoji-Seed-Mnemonics-for-Deterministic-Keys)

- **[Add importprivkeys RPC](https://gnusha.org/pi/bitcoindev/ad14b140-9e02-466c-8226-304ec651f4ben@googlegroups.com/T/#u#m4475f37e62eba1160bd9018f1f0fe19649a78290)** — by Blocktraveler  
  - Proposes new RPC call for importing private keys into Bitcoin Core descriptor wallets.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/m4475f37e62eba1160bd9018f1f0fe19649a78290_Add-importprivkeys-RPC)

- **[Bitcoin Inquisition 29.1](https://delvingbitcoin.org/t/bitcoin-inquisition-29-1/2019)** — by ajtowns  
  - Adds support for consensus changes and template sharing.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/delvingbitcoin/Sept_2025/5987_Bitcoin-Inquisition-29-1)

- **[Optimal Threshold Signatures in Bitcoin](https://delvingbitcoin.org/t/optimal-threshold-signatures-in-bitcoin/2023)** — by sindurasaraswathi  
  - Explores dynamic threshold management after Taproot.  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/delvingbitcoin/Oct_2025/5996_Optimal-Threshold-Signatures-in-Bitcoin)

---

#### 🔥 Active Discussions This Week

- **[[BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts](https://gnusha.org/pi/bitcoindev/1A33D206-444A-49E7-B1F1-E9FE5F4E32FB@drbonez.dev/T/#m1f3244d2d165cdd59c084b6c99690d51d2e4788c)** — Aiden McClelland  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Sept_2025/m1f3244d2d165cdd59c084b6c99690d51d2e4788c_-BIP-Proposal-Mempool-Validation-and-Relay-Policies-via-User-Defined-Scripts)

- **[[BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus](https://gnusha.org/pi/bitcoindev/CALiT-Zo8wiZGCFeMwfd92zptw_cKz7ajMOjFWW=rdS9by3zYHQ@mail.gmail.com/T/#m3e2bdc7ae5f63854c971fd6feef54ca644d135fb)** — Brandon Black  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/m3e2bdc7ae5f63854c971fd6feef54ca644d135fb_-BIP-Proposal-Limit-ScriptPubkey-Size-520-Bytes-Consensus-)

- **[Changes to BIP-360 - Pay to Quantum Resistant Hash (P2QRH)](https://delvingbitcoin.org/t/changes-to-bip-360-pay-to-quantum-resistant-hash-p2qrh/1811/31)** — moonsettler  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/delvingbitcoin/Oct_2025/5995_Changes-to-BIP-360-Pay-to-Quantum-Resistant-Hash-P2QRH-)

- **[OP_CHECKUTXOSETHASH idea](https://gnusha.org/pi/bitcoindev/CAJowKgLpix4KjzJGKNzR3JpiKLDJKSiuuOdcebCyGJnDuw0wJw@mail.gmail.com/T/#m8e157812cddf8459bcb15f5467092dc0a5e8b682)** — Peter Todd  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/Oct_2025/m8e157812cddf8459bcb15f5467092dc0a5e8b682_OP-CHECKUTXOSETHASH-idea)

- **[Stealth addresses using nostr](https://delvingbitcoin.org/t/stealth-addresses-using-nostr/1816/9)** — setavenger  
  - [Summary link](https://tldr.bitcoinsearch.xyz/summary/delvingbitcoin/Sept_2025/5986_Stealth-addresses-using-nostr)

---

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

---

*(Bitcoin Dev Project - TLDR product)*


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

## Introducing Bitcoin TLDR v2

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

Did you know the **bitcoin-dev mailing list** has over **20,000 posts** going back to *June 2011*?  

If each post takes ~30 minutes to read, that’s **over 400 days of nonstop reading**! 😅  

To be fair:  

1️⃣ Posts aren't easily searchable  
2️⃣ Threads that span multiple months can be broken  
3️⃣ Your inbox probably has enough emails competing for your attention  

Things can easily go ignored & unread.  
Few, if any, can say they have read it all.  

For the rest of us, we started working on a way to download the mailing list straight to your brain.  
While we haven’t quite figured that out (yet), we've built the next best thing…  

---

## 📚 Meet Bitcoin TLDR v2 📚  
A collection of summaries for:  
- **bitcoin-dev**  
- **lightning-dev**  
- **Delving Bitcoin**  

➡️ [tldr.bitcoinsearch.xyz](https://tldr.bitcoinsearch.xyz)


📢 Introducing Bitcoin TLDR v2

#  How Mining Pools Delegate Work to Miners



Here’s a simple visual explanation of how it works 👇

---

### 1️⃣ Pool Prepares Work
- The pool selects transactions from the mempool and builds a **block header** (incomplete).
- This incomplete header is the "work" miners will hash.
- The pool tweaks the **nonce** or **extranonce** so each miner gets a unique piece of work.



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

---

### 2️⃣ Miners Hash & Submit Shares
- Each miner receives a unique **nonce range** and starts hashing.
- When miners exhaust their nonce ranges, the pool tweaks the extranonce to give them more work.
- Miners submit a **share** when their hash is below the **share target** (much easier than bitcoin’s real network target)


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

---

###  Remember
- **Network Target:** Hash must be below this to mine a valid block. (Rare, what actually “wins” a block reward.)
- **Share Target:** Easier target set by the pool. Miners find shares every few seconds to prove they’re hashing and to measure their contribution.

![Share target vs network target](upload://fa1313a1-9ee2-4434-bdf5-f153b6b6a11a.png)

---

### What Happens Next?
When a share is also below the **network target**, the pool broadcasts the block to the bitcoin network and everyone in the pool shares the reward, based on how many shares they submitted.

---

### 👀 Coming Up Next
In our next post, we’ll look at **how pools calculate payouts**  
PPS, PPLNS, FPPS, and other reward algorithms that decide how miners get paid.

Follow @bitcoin_devs so you don’t miss it!
