Fresh out: Satoshi Scoop brings this week's Bitcoin bits 🍴
- Rust library for descriptor encoding cuts size by ~40% @npub1awj9...5xp2
- Fee estimation library Augur open-sourced, 20–30% more efficient than Bitcoin Core
- The rich get richer: unintentional forks' impacts on Bitcoin mining fairness
- How secure is your Bitcoin wallet's mnemonic seed phrase?
- RGB releases consensus v0.12
- Cross-network de-anonymization via ADDR fingerprinting @danielabrozzoni
- CLINK: Nostr-native standards for Lightning Network interactions
- Fairgate breaks BitVM3 authenticity with minimal counterexamples
- Babylon's 2025 roadmap: BTCFi via BitVM
- StarkWare x Kakarot: ZK proofs on everyday devices @npub1wmwd...n7j4
- Rarimo launches wrapless BTC collateral protocol
and bonus reads:
- What would Stripe L1 look like?
- Control as a spectrum: tailoring the right model
Full scoop
EN: https://yakihonne.com/naddr1qvzqqqr4gupzq046tm6pkgrtr4y73vd7wfqa06k4mkrmwdexrknycw7quf637gawqq24vttevft5veej09cx7wzetam8vuphfge5sucfejn
CN: https://yakihonne.com/naddr1qvzqqqr4gupzq046tm6pkgrtr4y73vd7wfqa06k4mkrmwdexrknycw7quf637gawqq25khejf964gkzgx3p8jvzzwgcj6kr5fe6kj6xcfrg
Here's how it works:
2/ Protocol-Level Flexibility: Fork Without Split
CKB is built on the UTXO Cell model, where each user's assets are stored in the discrete Cells—each with its own versioned Lock Script.
After a hardfork, each Cell continues to use the VM version it was deployed with, where:
- Existing Cells remain on the old VM version.
- Users are not forced to upgrade the Scripts.
- They opt in new features — if and when they want to.
This is made possible by introducing multiple hash_type variants (type, data, data1, data2, ...), each pointing to a different version of the code.
🤝 Multiple versions of Scripts and VMs coexist on the same chain.
⛓️ Upgrades won't split the network.
🔐 Users keep full control over both the assets, and the rules that govern them as well.
3/ Why It Matters 💡
Most chains treat a hardfork as a reset — override old logic and force everyone to upgrade.
CKB avoids this.
Multiple versions run side by side on the same chain. This eliminates the tension between network evolution and asset preservation.
4/ Script-Level Upgrade Workflow: Type ID + Lock Script
CKB provides Type ID + Lock Script model for managing script upgrades:
1️⃣ Initial Deployment: A Script developer deploys Scripts with upgrade plans in mind: Using Type ID to assign a stable identity but allows future updates.
2️⃣ Iterative Upgrade: Fix bugs, add new features, and change rules—the deployed code may undergo several upgrades using Type ID.
3️⃣ Code Freezing: At any point, one can freeze the code by modifying the Lock Script to be immutable.
5/ Script Developer & dApp Developer: Separate Roles
CKB separates two responsibilities:
- Script Developers: Deploy the Script and decide if it is upgradeable, via Type ID + Lock Script.
- dApp Developers: Choose how to reference a Script in their applications—fixed or upgradable.
Their options:
🔹Reference by type hash → Auto-follow the latest upgrades
🔹Reference by data / data1 / data2 hash → Stay fixed to the trusted version, ignoring the new one
Either way, dApp devs don't need to fear upstream changes breaking their logic or being kicked out of the network.
6/
This separation enables:
- Reusable Scripts across multiple dApps
- Opt-in upgrades — no forced coordination
- Long-term stability where needed, flexibility where desired
7/ Example: UDT Script Upgrade
Suppose someone deployed a UDT (User-Defined Token) Script using Type ID and created two tokens:
- UDT A uses type as hash_type
- UDT B uses data2 as hash_type
Later, the UDT Script is upgraded from Version 1 to Version 2:
- UDT A automatically adopts Version 2
- UDT B keeps running on Version 1
8/
Even if Version 1 is no longer present in a live Cell, it's not lost.
You can retrieve it from chain history, redeploy it, and use it again.
Old logic remains accessible—by design.
9/ A Better Forking Philosophy
CKB doesn't follow the rigid "hard vs. soft forks" binary. Instead, it offers:
✅ User autonomy
✅ Developer control
Assets stay protected.
Scripts remain stable—or upgradeable.
No one is forced to choose between safety and progress.
It's a better way to fork. And it works.
10/ Reference Links
Rethinking Forks: The Philosophy Behind CKB's Network Upgrade Design: 