Glad that @giacomozucco was sufficiently ambivalent (as he always is) about BIP-110. Kinda supporting - but not. As always, kinda with RGB. Sitting on all chairs. Playing words of imaginary units of consistency. That was a fun how this involved more and more of dumb plebs into the tenets of shitfork. Thank you, my favorite reverse shitcoiner. You did a great job!

We compiled @ethereum privacy discussions and designs into one living map — so anyone can see the privacy blueprint clearly: what’s being designed, why it matters, and who is behind it. Not an official roadmap. Continuously updated. 🖼 📂 ——— Core design 1) EIP-8182 — shared private UTXO pool Problem: app-level pools split liquidity — private funds stay fragmented. Vision: one protocol-owned shared pool that wallets and apps deposit into and spend from together. How: shared note-commitment tree + nullifier set. → 2) EIP-8250 — Keyed Nonce Problem: privacy flows often share one public sender / sponsor; a single linear nonce bottlenecks throughput — one inclusion can stall every other pending private spend. Vision: concurrent, independent private spends without a shared-sender queue. How: (nonce_keys, nonce_seq); non-overlapping keys are replay-independent (e.g. nullifier-derived keys). → 3) EIP-8141 — Frame Transactions Problem: bad UX for EOA users Vision: support arbitrary user-defined definitions of validation and gas payment. How: ordered frames — verify frame · approve frame · execution frame. Example: verify client proof + one time signature · approve trustless gas payemnt + execute call to privacy pool contract → 4) ERC-8302 — pERC20 (private fungible tokens) Requirments: bank wants to launch a private-stablecoin, informed by @eth_systems's research. Vision: stablecoins, RWA, or other assets may need privacy from day one. How: a private fungible token standard with an ERC-20-shaped surface (transfer / approve / allowance / transferFrom). → → 5) Kohaku (EF) — privacy wallet & SDK Goal: make it easy for any wallet to integrate privacy. → GitHub: → Roadmap: 6) leanVM — post-quantum proving & signatures Problem: ECDSA, BLS, and pairing SNARKs eventually break. Vision: hash-based signatures + PQ proof systems. How: leanXMSS + signature aggregation + recursive STARKs. → 7) Privacy Core Vision: value and addresses stay shielded in private transactions. How: UTXO notes + client ZKPs; IVK scanning + one-time receive addresses. → @zcash Protocol Spec: 8) Compliance • Privacy Pools / @0xbowio — deposit association sets at withdraw (ASP) → • @RAILGUN_Project — Proof of Innocence at shield vs List Provider bad-lists → • @_PLabs — cmx association sets when spending → 9) ETH & ERC-20 · DeFi Interaction • ETH & ERC-20 shield — @RAILGUN_Project · @0xbowio. • DeFi interaction — @RAILGUN_Project(unshield →contract call →shield ); → 10) Offical Scope • @VitalikButerin — simple L1 privacy roadmap → • @VitalikButerin — the Ethereum long-term trajectory → ——— Corrections and new links welcome.

I did my own investigation because I obviously don't trust them. What I found is that the external dependency of the firmware with the critical vulnerability hidden in it was written by CoinKite's CTO @DocHex pretending to be someone else. All of the following can be verified:

RGB LIGHTNING NODE V0.04发布后，我做第一阶段测试，先将总体测试情况汇报一下： 1. 基本功能测试 （1）程序安装：✅ （2）Loacal Node 创建：✅ ▪️需要提前安装Docker ▪️在Node创建的时候运行Container （3）Regtest Faucet使用：✅ （4）On-Chain BTC转移：✅ （5）LN BTC转移：✅ （6）管理UTXO，包含创建UTXO和增加UTXO：✅ （7）Node导入RGB资产：✅ ▪️需要Bitlight钱包配合 ▪️实质看起来是RGB资产从钱包“跨到”Node （8）RGB资产Exprot到钱包：✅ ▪️需要Bitlight钱包配合 ▪️实质看起来是RGB资产从Node“跨回”钱包 ▪️目前限定Bitlight钱包，未来可以是同RGB协议版本的其他钱包 2. Channel测试 （1）Node Connect：✅ ▪️Node之间建立P2P联系 （2）Channel创建：✅ ▪️需要Node Connet作为前置 ▪️需要理解通道创建的各个参数 ▪️UI界面有待优化 （3）Channel关闭：✅ ▪️UI界面有待优化 （4）RGB资产通过Channel转移：✅ ▪️转移正常，不过只来回测试了几次，未进行数量级别转移测试 ▪️资产展示页面需要优化，目前在LN通道内的RGB资产并不能直观看到 3. 其他功能测试 （1）备份钱包：✅ （2）恢复钱包：✅ （3）Node切换：✅ ---- 整体来说： ▪️主要功能测试均通过，无异常 ▪️部分界面的UI需要优化从而让体验更好 ▪️自建Node依然具有不小的门槛，引入Remote Node才能大幅度降低普通用户的使用门槛 ▪️部分环节的逻辑（比如open channel和close channel）细节我还需要仔细研究 #BTC# #RGB#

Bitlight Wallet v1.3.1 Released We are pleased to announce the release of Bitlight Wallet v1.3.1, introducing key enhancements to RGB asset interoperability and browser extension performance. What's New: • RGB Asset Consignment Import/Export — Bitlight Wallet now supports importing and exporting RGB asset consignments for RGB Lightning Nodes on Regtest, shipped alongside rgb-ldk-control-panel v0.0.4. This milestone enables developers to test end-to-end RGB asset transfers across Lightning channels in a controlled environment. • Chrome Extension Optimization — The Bitlight WASM library powering the Chrome extension has been optimized and upgraded. These updates reflect our continued commitment to advancing RGB protocol infrastructure and delivering a seamless developer experience. We encourage developers building on RGB Lightning to test consignment workflows and provide feedback. Make Bitcoin Smart.

Ethereum can already start preparing accounts for a post quantum world, without waiting for a hard fork. Today, it would be just 0.07$ . Further audits incoming. Though I squeezed in a review with Fable before Uncle Sam crashed my party. Verity formal proof included for my lean enjoyers