In briefEphemeral Rollup: a new L1.5 architecture for Ethereum (Ethereum Research forum discussion)
SummaryThe post proposes an "L1.5" pattern in which users keep their state in their wallets, L1 holds shared state and verifies every transition, and the computation in between is done by parties that hold no state needed for the next job, with results settled directly on L1. It relies on proposals such as EIP-8141, EIP-8250 and EIP-8288 to argue the pattern is becoming practical, using private settlement as the main example. It also distinguishes the pattern from rollups.
In briefInformation hazards and safe redaction: a Bitcoin developer forum post on giving users a way to safely remove data they do not want to store or spread.
SummaryThe author argues that subjective information hazards can be written to the blockchain and that there is currently no general defence against this. They propose discussing ways for users to safely redact data they consider hazardous while keeping most functions of a full archival node, and ask for others working in this area. The discussion explicitly excludes restricting arbitrary data from being published in new blocks.
In briefThe Long Road to Bitcoin Payments: Why adoption lags and calls for bold ideas to change it
SummaryThis Delving Bitcoin community discussion examines why bitcoin payments have not taken off despite improved payment technology such as Lightning. It argues the main obstacle is weak demand, notes that major payment providers are choosing stablecoins, and points to price volatility as a barrier. The author invites readers to propose moonshot ideas that could shift bitcoin payments and calls on builders, payment providers, and funders to contribute.
In briefA readable mirror of the bitcoin-dev mailing list covering 15 years of posts
SummaryThe author built a daily-refreshed, readable mirror of the bitcoin-dev mailing list archive. Compared with public-inbox, it offers one page per thread with folded quotes, stable Message-ID permalinks, and indexes by topic, BIP, and author, with messages kept verbatim and linked to their originals. The author asks for feedback on how author names are merged and how threads are matched.
In briefProof of One: an open polling design using encrypted ballots and passport-based identity, seeking critical review
SummaryThe author, maintainer of the open-source non-commercial project Proof of One, posts on the Ethereum Research forum a polling design aiming for one unique human per participant, unlinkable answers, voter-verifiable ballots and public recounting. Enrolment uses a passport chip with zero-knowledge proofs, and ballots use threshold ElGamal encryption. The author discloses that most of the design and code was drafted with AI agents and has not been independently reviewed, so critical feedback is requested.
In briefInventory of Post-Quantum P2P Migration Challenges in Ethereum's Consensus Layer
SummaryThis Ethereum Research forum post takes stock of the challenges facing post-quantum migration for consensus-layer peer-to-peer networking, including Discovery v5, ENR, libp2p, and QUIC/TLS 1.3. It argues that replacing validator BLS signatures alone does not update networking identities or handshakes. The post notes structural limits such as the 300-byte ENR and 1,280-byte Discovery packet size. It maps the required changes without selecting an algorithm, encoding, or activation schedule.
In briefLean verification of EIP-7002: guaranteed system-call success and FIFO withdrawal requests
SummaryThis ethresear.ch post reports Lean 4 proofs about the deployed bytecode of EIP-7002, the execution-layer contract for validator exits and partial withdrawals. The proofs show the end-of-block system call always succeeds regardless of storage, using at most 210,000 gas. They also show requests are emitted exactly in arrival order. The results are stated against the Jaune EVM semantics and cover the Prague, Osaka, BPO1 and BPO2 forks.
In briefProposal for cost-backed Sybil resistance in self-issued identifiers
SummaryThis Delving Bitcoin discussion proposes a construction that makes bulk production of self-issued identifiers costly by requiring a memory-intensive process over a 256 MiB terrain, bound to consecutive Bitcoin headers. The produced object records this evidence, and an independent verifier can measure it against the specification and recompute a random sample of six legs. The author notes that whether the construction imposes a meaningful marginal physical cost under adversarial conditions remains an open question and invites critical review.
In briefOpen questions and next steps on zero-knowledge proofs (Ethereum Research forum thread)
SummaryThis is a technical discussion thread on the Ethereum Research forum, with a Japanese-language title about open questions in zero-knowledge proofs. The author deleted the topic, so no discussion content remains.
In briefFinalisCore update: deterministic BFT finality and confidential UTXOs from genesis, with open questions
SummaryThe author reports on FinalisCore, a Bitcoin-related blockchain project whose testnet-2 has run since 24 October 2026 with leader VRF moved to RFC 9381; mainnet has not launched. The author requests independent critique of core claims: at most one transition finalizes per height, confidential transactions cannot create value, and committee, checkpoint and reward derivation uses only finalized history. Reviewing guidance and security reporting instructions are provided in the repository.
In briefA hash-only rollup using Lamport-style hash chains for OP Stack L2 accounts, with no ECDSA inside the L2
SummaryThis forum post describes an OP Stack rollup on Ethereum mainnet where L2 transactions carry no signatures. Each account is the tip of a keccak-256 hash chain, and spending reveals the next preimage through a commit-reveal step that prevents front-running. The author lists known weaknesses, such as griefing via junk commits, and other trust assumptions, and invites critical feedback.
In briefCLN: Self-Referential Channel Announcement DoS Disclosure
SummaryCore Lightning v25.02 through v26.04 crash on a channel_announcement whose two node IDs are identical, and the node stays down across restarts until an operator manually removes the stored record. An attacker needs only an unspent 2-of-2 output, so the attack costs nothing beyond on-chain fees. The fix in v26.04.1 rejects announcements where node_id_1 is not lexicographically less than node_id_2.
In briefProposed quantum defense: “Proof-of-Decay” for dormant unmigrated coins
SummaryThis Delving Bitcoin post proposes a middle path for old, exposed-key outputs that remain unmigrated to post-quantum addresses after a deadline: their balances would slowly decay on a block-height schedule, with decayed satoshis burned or sent to the miner reward pool. The author argues this avoids both a hard freeze and leaving coins fully exposed. The post asks developers whether such decay can be enforced at the consensus script level and whether it offers better game-theoretic protection.
SummaryThis is a Delving Bitcoin discussion thread, a forum for Bitcoin protocol development, asking for the strongest critiques of BIP300 (drivechains). The post responds to several common objections, including whether hash power can forge signatures, whether miners could steal funds, the timescales involved, and how scaling and pruning of history would work.
In briefParanoid EIP-8288: heterogeneous recursion with an authenticated class bank
SummaryThe author describes a heterogeneous recursive aggregation scheme implemented in Parano1d, using a finite, authenticated bank of verifier classes so recursive steps can use several approved proof sizes. Small aggregates can use a smaller proving relation. The post explains how deferred matrix-evaluation claims are carried across classes and discusses how this could apply to the EIP-8288 aggregation backend, along with open questions.
In briefReveal optionality in encrypted mempools and a post-quantum way to remove it
SummaryThis forum post examines how much value a sender gains from controlling whether to reveal a transaction in an encrypted mempool, and why fees alone and forced opening do not fully remove this option. The author proposes Blind Simultaneous Release (BSR), which requires participants to commit before seeing new information and uses only hash functions, making it post-quantum. The accompanying paper has its theorems machine-checked in Lean 4, but the hardware speed assumption it relies on has not been measured.
In briefProjects to make merchant Bitcoin adoption easier and cheaper
SummaryThe author presents several projects built over two years to simplify merchant onboarding to Lightning. They include a CLINK plugin for Electrum that receives payments via nostr relays without opening ports, a plugin that automates obtaining inbound liquidity through submarine swaps, and a GUI for Electrum's swap server. The main project, BareBits, is merchant software that runs on simple web hosting or Windows desktops and is BTCPay-compatible. It charges a 1% fee and is described as open source and self-hosted.
In briefSEACAST: A Fast, Lean Broadcast Protocol for Ethereum With an Executable Spec and Formal Model
SummaryThe author proposes SEACAST, a protocol for quickly delivering large Ethereum messages. Nodes forward chunks as they arrive, and coding and sampling let each node receive only the parts it needs. The post reports that on 50 Mbps networks SEACAST is faster and uses fewer bytes than ECBroadcast and gossipsub, and it comes with an executable specification and a formal model.
In briefCost-bounded transaction filtering language for node policy
SummaryThe author designed a transaction filtering policy language and implemented it in satd, a Rust Bitcoin full node. It lets operators choose which transaction shapes to relay or include in block templates without affecting consensus correctness. Matching transactions are quarantined rather than rejected, keeping policy visible and tunable. If rules might catch important protocol transactions such as Lightning channel closures, the node refuses to load the filter by default.
In briefTesting deterministic BFT finality in a confidential UTXO blockchain
SummaryThe author presents FinalisCore, an open-source Layer-1 blockchain written from scratch in C++, and requests technical feedback on its state transition model. Blocks become final in 32-block epochs once a committee quorum signs them, and transaction amounts are hidden using Pedersen commitments from secp256k1-zkp. Open questions cover wallet handling during rapid committee changes and the CPU cost of batch range-proof verification, and the live testnet is explicitly non-commercial.
In briefbtc-verified October Update: Matching a Formal Model to Bitcoin Core's Real Behavior
SummaryThe btc-verified project builds a minimal formal model of Bitcoin consensus in Lean. This post describes using the libbitcoinkernel interface and differential fuzzing, in the style of bitcoinfuzz, to check whether the model matches Bitcoin Core on transaction parsing, serialization, and transaction-local checks. Nine kernel functions are currently backed by the Lean implementation.
In briefFaster, aggregatable, quantum-safe privacy pools (Tornado Cash-style)
SummaryThe authors port a Tornado Cash-style privacy pool to Flock, a post-quantum binary-field SNARK, using SHA-256 for the Merkle tree and nullifier hashing. They report proving a depth-32 withdrawal in under 30 ms and describe recursive aggregation of withdrawals. They also propose a recovery protocol in which wallets derive note secrets from a seed, so existing pools can survive a discrete logarithm break.
In briefVariable payout amounts for BABE, applied to Lichen
SummaryThis Delving Bitcoin discussion explains how the BABE scheme uses witness encryption so a Bitcoin contract unlocks only when someone holds a valid Groth16 proof. The author proposes a way to make the payout amount variable rather than fixed at contract setup. The example for Lichen shows how the verifier and prover exchange signatures on the withdrawal amount.
In briefSilent Payments protocol proposal for multiparty wallets
SummaryA Delving Bitcoin post proposing a protocol that lets multiparty wallets make secure Silent Payments. Each signer's ECDH contribution is combined as a weighted sum, and AggDLEQ aggregates their proofs into a single BIP-374 proof. The author states the security proofs are under internal review and not yet published.
In briefHow much screening buys a second: speed versus selection in maker spreads
SummaryThe paper examines how a liquidity provider with a stale quote can be picked off by informed traders, and compares two defenses: repricing faster and screening informed order flow. It derives a break-even screening rate at which a slower maker matches a faster unscreened venue. Using USDC-WETH pools against Binance ETH-USDT, it finds a twelve-second maker must screen at least 84.5% of informed flow to match one-second execution.
In briefFrom peer-to-peer cash to elite settlement: does Bitcoin's 21M cap create a new aristocracy?
SummaryThis forum post argues that Bitcoin, introduced as peer-to-peer electronic cash, is increasingly held as a reserve asset by governments, ETFs and corporations while everyday spending declines. The author questions whether the fixed 21 million supply could gradually price out ordinary people and concentrate holdings among the wealthy. It closes by proposing a conceptual alternative, "humanitycoin", whose limit is on value rather than units and which is powered by everyday activity.
In briefRapidblocks with split proofs: execution proofs that reusable across slots
SummaryThis is a technical discussion post on the Ethereum Research forum proposing that a block's execution proof be split into three parts. The transaction proof covers only inputs and outputs without naming a state root, while the input and output proofs tie them to state roots. The author suggests this lets proofs stay valid across slots as long as the block's inputs remain current. The post states it is an ideas piece and that none of the design is yet proven or measured.
In briefBitcoin Core 32.0rc4 release candidate announced
SummaryBitcoin Core has released v32.0rc4, a release candidate for the new major version 32.0, for testing. The post links to binaries, source code under a signed tag, draft release notes, and a testing guide. Testers are asked to report issues in a designated GitHub issue. If no critical problems are found, this candidate will be tagged as v32.0.
In briefPriority fees and transaction types at the front of Ethereum blocks, July 2025 to October 2026
SummaryThe author measured about 115,000 Ethereum blocks across sixteen sampled days using TEMBRI, an open-source tool, on Xatu execution data. Swaps in the first 10% of block gas paid roughly 8 to 17 times the priority fee of swaps at 30% to 60%. From August to October 2026, zero-tip swaps at the front fell sharply, with Titan accounting for much of the decline.
In briefOpen-source Bitcoin multisig coordinator with shared signing queue and signet demo
SummaryThe author has open-sourced btc-safe, a self-hosted, watch-only Bitcoin multisig coordinator. A proposer creates a transaction, which co-signers review in a shared queue and sign on their own devices; it is broadcast once M of N signatures are collected. The server stores only xpubs and descriptors, never keys or signatures. It supports Ledger, Trezor, Sparrow, Caravan and PSBT files, plus TOTP 2FA and role-based access. It can be tried on signet with no real funds.
In briefEthereum Research forum: a pipelined consensus for independent blocks, take two
SummaryThe post proposes a consensus design in which blocks do not depend on their immediate predecessor: each block executes on the state of its history and respects the filters of its referenced blocks, so a block can be voted out without a reorg. It describes the Hist rule, a per-slot window vote, and a safety sketch, simulation, model check, and a mainnet measurement in which 87% of transactions take the fast path.
In briefInformed Diffusion: Helping Home Builders Publish Payloads Quickly
SummaryThis post extends the EIP-8411 series with a four-tier design for payload diffusion. Tier 1 splits payloads into chunks that nodes can verify and forward before receiving the whole payload, which provides most of the latency reduction. Tier 4 lets each node act on what it knows about its neighbours, so that a builder on a home connection can deliver a payload within the roughly 3-second budget. The author reports that tier 4 met this budget in every stress scenario simulated.
In briefERC-8403: Account as a Single Root Hash, with Post-Quantum Keys
SummaryThis Ethereum Research post presents draft ERC-8403, in which an account commits to one root hash, and adding, rotating, or revoking keys means publishing a new root while the address stays the same. It then explores adding post-quantum (leansphincs) keys on top of EIP-8288. The author reports a local demo and lists the parts that remain unresolved.
In brief[BIP Draft] Standard Policy Format for Co-signer Spending Conditions
SummaryThis draft proposes a common format for the policies a co-signer enforces before signing, rather than specifying the co-signer itself. It covers open, blinded, and enclave verification, and allows conditions drawn from the transaction or external attestations, with co-signers required to accept DLC oracle attestations. The author seeks feedback on whether this is the right layer to standardize and on open questions such as serialization format and whether fallback paths must be timelocked.
In briefA proposal for a privacy-preserving stablecoin on Ethereum, backed by USDC/USDT
SummaryThis Ethereum Research forum post proposes a stablecoin protocol with built-in privacy, backed by USDC or USDT and leveraging Ethereum's programmability. It lists intended properties such as smart-contract-enforced minting and redemption, permissionless participation, composability with existing DeFi protocols, and confidential or unlinkable transactions. The author also outlines possible applications, including selective disclosure and private prediction markets.
In briefBRO-AMM: a bonded oracle market maker proposal to reduce liquidity provider losses
SummaryThe author released an early preprint, BRO-AMM, addressing how arbitrage steadily drains value from liquidity providers in DeFi pools. The design makes trade prices final only after a later reconciliation step, with traders posting bonds and excess gains returned to depositors. A simulation replaying six months of ETH/USDC trades on Ethereum and Arbitrum reports lower depositor losses to arbitrage. The approach still relies on a trusted source of signed market prices and is not a live product.
In briefCassis: a simple scheme for generic multi-layer, multi-hop HTLC routing
SummaryBitcoin payments are spread across many layers, such as Lightning, Fedimint, Cashu and Arkade, with no generic way to pay between them. Cassis proposes that any layer able to express an HTLC can act as a hop, so a payment becomes a chain of HTLCs across layers locked to the same SHA-256 hash. An experimental Rust implementation exists, but open problems remain, including node communication, router announcements, reputation, invoice format and offline receiving.
In briefDiscussion on exposing an instruction set architecture (ISA) for post-quantum proofs on Ethereum
SummaryThis Ethereum Research forum post discusses how EIP-8288 could let transactions depend on post-quantum proofs verified outside the EVM. It compares three candidate instruction sets Ethereum could expose: the EVM, RISC-V, and a proving-oriented eISA. The author also explains how the exposed ISA could evolve without breaking immutable smart contracts.
In briefCombining FCR and EEZ: faster cross-layer payments on Ethereum without a bridge
SummaryThis ethresear.ch post uses a checkout example to show how the Fast Confirmation Rule (FCR) and the Ethereum Economic Zone (EEZ) work together. FCR shortens the wait before a block can be trusted, while EEZ removes the separate crossing between a rollup and the base layer. Used together, the author says a payment can confirm in about two slots, roughly 25 seconds, without trusting a bridge.
In briefCost of Censorship Resistance Under Sybil Attacks in Multiple Proposer Protocols
SummaryThis forum post discusses a paper on the cost of censorship in multiple proposer protocols, which derives the price and bounds for effectively censoring transactions under different transaction fee mechanisms. The author examines how these bounds change when Sybil nodes are present. The post also considers what the altered conclusions imply for multiple concurrent proposer (MCP) protocols.
In briefEthereum PropAMMs today and tomorrow: how on-chain market makers compare across Ethereum and Solana
SummaryThis Ethereum Research forum post compares PropAMMs, on-chain venues where market makers update quoted prices directly, on Ethereum and Solana. It reports recent trading volume figures for both chains. The article examines how market makers handle latency races and adverse selection, and how slot timing differs between the two networks.
In briefWho cleans up the code? Dangling bytecode and design choices for SETCODEFROM
SummaryA discussion post on the Ethereum Research forum about bytecode that no account references anymore. It argues that the proposed SETCODEFROM and the partitioned binary tree turn this harmless leftover into a design decision. The post compares how clients handle the problem and why reference counting would be needed to delete shared code.
In briefAnchoring an SPV light client on another chain: trust checkpoints, difficulty retargeting and reorgs
SummaryThe author describes the Bitcoin-facing design of Writz Protocol, which holds BTC collateral in a P2WSH script and runs an on-chain SPV light client on a smart contract platform. The post asks for critique of checkpoint trust, confirmation depth, timelock type, fee bumping, header validation cost and the reorg bound. The code is on testnet only and has not been audited.
In briefAsynchronous pipeline consensus to break the serial verification loop
SummaryThis forum post proposes an Asynchronous Pipeline Consensus Architecture that decouples block production from full transaction verification. Nodes propagate a compact payload of 6-byte transaction identifiers to start the next block, while verification of block n is delayed to block n+k via a 1-bit header field. The author asks whether the serial bottleneck can be broken without compromising baseline security and whether the design could apply to Ethereum's account model.
In briefAccountability for encrypted mempools: tracing committee members who leak decryption shares
SummaryThis post examines how committee-based encrypted mempools can be protected against leaked decryption shares. The authors propose a candidate traceable threshold encryption construction that identifies committee members who help build a leaked partial decoder before transactions are revealed, without falsely accusing honest members. They note it is a first step rather than a deployment-ready solution, with setup and the tracing authority still open problems.
In briefProposal to add private hash preimage syntax to descriptors
SummaryThis Delving Bitcoin thread proposes adding a private form for miniscript hash fragments (sha256, hash256, ripemd160, hash160), such as sha256(preimage(HEX)), so preimages can be stored in descriptors like private keys. The author was motivated by the TABConf CTB challenge, where Bitcoin Core's wallet had no way to supply a preimage. The post includes a syntax draft, safety considerations, and open questions.
In briefProposal for a minimal, compute-anchored signal of purchasing power
SummaryThe author proposes a trust-minimized onchain signal approximating ETH purchasing power against computational cost. Reporters post a threshold and ETH liquidity, which others can attempt to break by finding a qualifying nonce. Surviving thresholds' implied work per unit liquidity is compared over time. The contract is about 200 lines and uses keccak256; feedback and attempts to break the design are invited.
In briefSix defects found in a signature verifier through six outside test rounds
SummaryThe author ran six rounds of predictions-first testing against a read-only MCP server (nsgoods) that verifies x402 catalogue signatures, finding six defects. These included rejecting genuine documents, accepting tampered bodies under the right service name, and refusals that could not be told apart. After asking about log handling, the operator disclosed and corrected a mismatch between stored logs and the privacy page. The author concludes that a check nobody has seen fail is not known to work.
In briefIs the pre-finality double-spend race inherent to single-owner coins?
SummaryThe author examines a race condition in which a payer broadcasts a spend of their own coin just before paying a payee, making the payment a double-spend. They want to avoid 2-of-2 channels and punitive Lightning-style models, and note that eltoo requires the unactivated BIP-118. The post asks whether this race is intrinsic to single-owner coins and whether anyone is working on a similar solution.
In briefDisclosure: DoS Flaws in Eclair v0.14.1 Fixed
SummaryTwo denial-of-service vulnerabilities in Eclair's channel opening flow were fixed in v0.14.1, and users are advised to upgrade. The first is an open_channel race condition that lets an attacker leak memory until the node crashes from out-of-memory or garbage-collection thrashing. The second is an unfunded channel flood that bypasses the pending-channel rate limiter, exhausting memory over a single connection at no on-chain cost.
