Socratic Seminar 58

November 11, 2026

View on Luma

Event Time: November 11, 2026 at 06:00 PM EST

We will start with introductions, cover some basic ground rules, and then jump into technical discussions.

Please note the meeting location is at 100 New Millennium Way, Durham, NC 27709, USA.

Announcements

• no pictures or recordings
• follow the chatham house rule
  • discuss what was said, not who said it
• don't be a jerk
• thank you to our sponsor Fidelity Investments
• introductions

Tracing the Blink Theft

• The September 19 attack: the facts, the full story, and the 50% bounty

  • a flaw in the admin tools' permission checks let an ordinary account grant itself admin; it drained 6.61 BTC from 24 of 35 accounts in two hours, partly on chain and partly over Lightning
  • every drained account restored to its exact balance on September 24, funded by shareholders; the hot wallet only — multisig cold storage and non-custodial accounts untouched
  • the lesson Blink draws: two-factor authentication worked — nine 2FA accounts were logged into, all 18 attempts refused, zero loss
  what does this mean?

  The sequence began with a free account opened on September 17, followed by a two-day probe and an authorization flaw on the consent page. The attacker then changed email and phone data on 35 accounts, raised withdrawal limits on 14, and completed the drain across 24 accounts in two hours. The same access read details for 3,817 further accounts: phone and email at most, with no names, documents, or seed phrases.

  Blink shut the custodial service fully off within fifteen minutes of the first call, merged three fixes the same day, re-ran the full attack against the pre-fix code, and published an hour-by-hour timeline. It traced about 5 BTC through a cross-chain swap and a little to Binance, filed criminal complaints in El Salvador and Próspera, expected no money back, and set the bounty at half of anything recovered for Bitcoin Beach, Bitcoin Ekasi and Afribit Kibera's picks, plus a quarter for the finder.

• Phase two: following the coins in public

  • October 8, five days after the postmortem: a page listing every address, transaction and channel tied to the attacker, each checkable against the chain
  what does this mean?

  Blink separates the incident into an internal record and a funds-flow record. The postmortem covered what happened inside Blink, while this follow-up covers where the money went by tying addresses, transactions, and Lightning channels to the attacker and making each link checkable against the public blockchain.

  Blink frames the publication as a privacy boundary. The company builds privacy tooling, and stolen coins moving through the same tools everyone else uses have no settled community answer. Its chosen limit is chain-visible information about the attacker's coins only: no named people, no personal data, and public corrections when the chain proves the page wrong.

• bounty.blink.sv: the attacker's coins, address by address

  • the attacker spent ten days preparing: a Lightning node up and running a week and a half before the theft, about 14 BTC under his control nine days before it
  • still active as of early October: channels opened and closed, a second node appeared, and on October 5 he attacked Second's Ark server for 0.75 BTC of Second's own funds, funded at least partly with the Blink loot
  what does this mean?

  The site works as public chain analysis: deposits, hops, channel opens, and channel closes are attributed to one actor and laid out for verification. Its Lightning evidence shows the thief using liquidity to stage and split stolen funds, not just to make payments, so the channels become part of the custody trail.

  The Second episode turns the response from one company record into a repeated pattern: the same actor probed a second implementation within two weeks and used the first theft's coins to do it. The bounty keeps the promised split, with a quarter to the finder and a quarter to the circular economies, and pays only after recovered funds return to a Blink wallet. That structure makes the community the recovery layer.

• discussion: when does tracing a theft in public become surveillance of the one who stole?

Mining

• ArkPool

  • a mining pool for Bitaxes that pays out hourly over Ark, with a 1-sat minimum and a Tor-only stratum endpoint
  • mainnet alpha, with a public dashboard whose totals carry a timestamped snapshot
  what does this mean?

  ArkPool keeps the familiar pool workflow of a stratum endpoint and a public dashboard while moving the reward leg into an Ark account. Rewards accrue there, pay hourly as Ark notes in whole satoshis, and roll any fractional remainder forward. The surrounding docs target small home hashpower with Bitaxe firmware pointers, setup material, and a Tor connection recipe for miners behind NAT.

  That payout rail explains the one-satoshi floor. An offchain Ark transfer does not impose the pool-side cost profile of an on-chain transaction, so the cadence can be set by policy rather than miner fee pressure. The cost is a new dependency: the pool's Ark server sits on the reward path, and the service remains mainnet alpha.

• Silent Payments coinbase

  • pay the mining reward to a BIP 352 silent payment address: the coinbase output carries a tweak, the miner scans with his silent payment key, no address is reused and none is public
  • pool payout below the dust threshold accrues off-chain and is settled as an Ark arkoor, both tiers derived from one per-block ECDH
  • the tweak must not be reused across the two tiers, or the ark and spend keys become linkable
  what does this mean?

  SPc pushes the split into the reward construction. The pool sends amounts above a dust floor to a silent-payment output in the winning block, while smaller fractions accrue until a later Ark round. Those small earnings avoid appearing on-chain as individual dust outputs. A shared block-entropy tweak gives the miner one identity across the direct and Ark settlement paths.

  The wallet edge carries most of the complexity because a silent-payment coinbase is nonstandard. The receiver needs scanning code that extracts the sender key from the coinbase scriptSig rather than processing the transaction as ordinary BIP 352. The Ark side also needs a rotating mailbox, so one static identifier does not let the server link every payout. Pool accounting stays unchanged; the miner client changes.

• average-gary/silent-pool: the SPc + Ark payout scheme, implemented

  • BIP 352 silent-payment coinbase outputs above dust, bark arkoors below, one per-block ECDH deriving both
  • validated on regtest against an unmodified bark server: the server co-signed the arkoor, a modified miner client claimed the VTXO and spent it back through the same server
  what does this mean?

  The implementation turns the SPc design into code with crates for the coinbase tweak, the blinded mailbox, and the miner-side client, plus a regtest harness that produced the validation. It also exposes a bark wallet constraint: each VTXO key currently attaches to a seed index, so tweaked keys need their own type and storage, and recovery must rescan pool blocks.

  The change set draws the boundary between components. The Ark server stays stock. The pool adds a modified miner client and a one-time blinding hint per block. The wallet adds a pluggable source of extra keys, sized at a couple hundred lines. Because the pool sees both payout tiers by construction, the privacy claim applies to on-chain observers rather than to the pool.

• discussion: what must a miner trust to accept a payout he did not compute?

Node Implementations

• Hornet: an executable specification of the consensus rules

  • consensus expressed twice over, in declarative C++ and in a purpose-built DSL, with a lightweight node doing full IBD on top
  • the UTXO engine is its own layer: lock-free, age-stratified LSM-style tiers, reorg-safe, out-of-order operation
  • hornetnode.org carries the design overview
  what does this mean?

  Consensus usually arrives embedded in a working implementation rather than as a separate artifact. That coupling gives a fork the original program's shape and hidden behavior, but not the review history that made those behaviors trusted. Hornet draws the boundary around a pure rule engine with explicit inputs and outputs, and keeps mempool policy, storage layout and networking outside it.

  A node can link that engine directly or generate code from the specification compiler. The design contrasts with libbitcoinkernel, which extracts Bitcoin Core validation while retaining its data structures, threading model and LevelDB storage assumptions. Hornet makes the ruleset from scratch and keeps the concurrent validation pipeline and custom UTXO store as replaceable components outside the consensus boundary.

• rbitcoin 0.9.0

  • a Bitcoin full node in Rust built on rust-bitcoin, with the UTXO set replaced by a relational archive; speaks BIP 324 exclusively and serves Electrum- and Esplora-style APIs
  • the consensus rules have been reviewed since 0.8: the code was used to add a rule and tighten others in Hornet's written rules, compared against Rob Hamilton's btc-lean description, and Matt Corallo attempted to prove the compiled code matches Bitcoin — the rules held up
  • easier to install: Linux musl x86_64 and aarch64 static binaries, a container image, and a 0.8 data directory that opens unchanged
  what does this mean?

  The release presents the consensus review as the main change. Since 0.8, reviewers used this codebase's rules to specify rules in Hornet, compared them with an independent Lean formalization, and tested them through a proof attempt against Bitcoin's actual behavior. The project still frames the result cautiously: a mainnet split from Bitcoin Core is very unlikely, while signed releases and a support window remain planned for 1.0.

  Operational behavior also changed. On mainnet, historical script checks now stop at block 966,143, matching Bitcoin Core 32.1, while --milestone 0 still forces a full-check sync. Signet and the new testnet4 always check everything. The RPC layer now matches Core's exact error codes, so LND's 0.1 fee cap on sendrawtransaction gets interpreted the same way and wallets can work against it.

• discussion:

  • is the protocol the code or the specification — and who reviews a patch to the spec?
  • when two implementations disagree, what breaks first: the chain or the spec?
  • what is the least a node must verify to deserve its users' trust?

Bitcoin Core

• Bitcoin Core 32.1

  • maintenance release, October 27, the current stable version
  • carries the memory-growth fixes below along with the usual batch of backports
  what does this mean?

  The 32.1 release makes the October security fixes available to users on the current stable branch. It fixes both disclosed memory-growth bugs, and the same patches went to maintained older branches as 29.5, 30.4 and 31.2. The TCP urgent-data issue mainly affects nodes on Windows, macOS and BSD, because Linux uses a different socket backend.

  The rest of the release has the shape of a conservative maintenance update. It does not change consensus-adjacent behavior or introduce new policy. It collects changes since 32.0 that maintainers judged safe to backport, so operators can treat the upgrade as a security and stability bump rather than a behavioral migration.

• CVE-2026-117350: unbounded memory growth through TCP urgent data

  • the select()-based socket backend, used everywhere except Linux, watched for exceptional conditions even when reads were paused
  • a peer sending TCP urgent data could bypass backpressure and queue without limit — a trivial crash for any Windows, macOS or BSD node
  • fixed in #36665; discovered by an automated LLM scan in Project Loupe at Spiral, validated by Gregory Sanders
  what does this mean?

  The failure is a backpressure bypass rather than a parsing error. Bitcoin Core pauses reads when a peer's send queue grows beyond its limit, but the select() path still responded to exceptional socket events. Each such event could perform another read and add more queued data, so urgent data gave an attacker a repeatable way around the pause.

  A single connected peer could drive memory use until the node crashed on the affected platforms. The platform split matters because the vulnerable behavior lived in the non-Linux socket path, making portability code part of the security boundary. The discovery path also changed the workflow: an LLM scan found the issue, and a human expert validated it before disclosure.

• CVE-2026-117349: slow unbounded memory growth on paused pre-BIP 31 peers

  • announcement queues keep growing for paused peers, and a pre-BIP 31 peer that never answers pings stays paused forever
  • medium severity, easily discoverable; fixed alongside the TCP bug in the same four releases
  what does this mean?

  This bug has the same backpressure pattern with a much slower failure mode. A peer can be marked paused-for-send after its outbound queue grows too large, but some announcements still get appended to that queue. That behavior stays bounded when the pause eventually clears, because the peer resumes normal processing and drains work.

  A pre-BIP 31 peer never sends pong messages, so it can remain paused indefinitely while small announcements continue to accumulate for the life of the connection. Compatibility with very old implementations keeps these paths reachable even when active use is assumed absent. The remediation shipped in the same maintained releases, so one upgrade addresses both memory-growth issues.

• net: always complete all initial private broadcast connections — merged

  • private broadcast contacts three peers for a wallet transaction; this guarantees all three connections are made before the transaction is considered sent
  • a resolved or mempool-conflicted transaction is now marked resolved rather than removed, and stale retry connections are tracked and granted explicitly
  • closes the theoretical timing attacks described in #34707 and #29415
  what does this mean?

  Private broadcast protects transaction origin by controlling which peers hear a wallet transaction first. That protection depends on the connection schedule matching the protocol's assumptions. The accounting bug allowed a transaction to be treated as delivered, or placed into retry handling, even when the intended outbound connections had not actually completed.

  That mismatch could expose timing patterns to an observer. The merged change tightens the state machine by marking resolved or mempool-conflicted transactions as resolved rather than deleting them, and by tracking stale retry connections with explicit grants. It follows the June disclosure about private-broadcast IP leaks, and nodes on 32.x already include the fix.

Signatures and Script

• BIP 458: Half-Aggregation of BIP 340 Signatures

  • non-interactive: any number of signatures collapse into one roughly half the total size
  • Ruffing, Nick and Jahr; merged into the repo November 2
  what does this mean?

  Half-aggregation treats existing BIP 340 signatures as inputs rather than changing the signing ceremony. It combines n signatures into an object about half their total length, so a verifier checking a large input bundle can move fewer signature bytes while each signer keeps the same device workflow. The tradeoff moves to verification: software needs the aggregate verification algorithm, and designers must decide where such an aggregate is allowed to appear.

  The BIP sits in layer Applications as an off-chain verification specification, so it does not by itself alter consensus. Its use cases are shaped by bandwidth pressure: block propagation, batched payment proofs, and light-client checks. If an aggregate is later placed inside script, the relevant boundary is whether signatures were combined after signing or produced through a full aggregation protocol.

• BIP 459: DahLIAS fully aggregated signatures for secp256k1

  • interactive: signers run a protocol and produce a single 64-byte signature over any number of key/message pairs
  • Jahr; the scheme is Nick, Ruffing and Seurin's DahLIAS, eprint 2025/692; merged November 3
  what does this mean?

  DahLIAS moves aggregation into the act of signing. Signers participate in a two-plus round protocol, and the result is one signature the size of a plain Schnorr signature across any number of key/message pairs. That gives the stronger primitive, but deployment has to happen during the signing session rather than after independent signatures already exist.

  Full aggregation and half-aggregation reach similar bandwidth goals through different adoption paths. A verifier can adopt half-aggregation unilaterally, while signers must jointly adopt full aggregation and accept its coordination requirements. The difference also affects trust assumptions. Neither construction changes consensus on its own, and each still needs a reason before it appears on-chain.

• Eltoo state channel on signet, third time: TEMPLATEHASH + CSFS + INTERNALKEY

  • the same two-party channel built three ways: once with APO+CTV, once with a CSFS rekey ladder, now with Inquisition 29's OP_TEMPLATEHASH per the draft eltoo_th BOLT
  • update path: TEMPLATEHASH INTERNALKEY CSFS VERIFY <CLTV>; settle path commits the hash
  • the settlement fee is now 35 bytes; a stale state was published on purpose and replaced
  what does this mean?

  Eltoo needs a later update transaction to spend an earlier settlement output even when the exact earlier transaction has not been finalized. The APO version handled that by signing any input. The TEMPLATEHASH version commits only to the spending transaction's shape, so a ten-byte update script can bind the internal key with OP_INTERNALKEY and let the counterparty provide the hash for the next hop.

  The third rebuild turns the same channel into a controlled comparison across consensus proposals from one author. Fee sizes, key handling, and signing order change in ways a comparison chart can hide. It also tests Inquisition behavior that appears only during a real settlement race, including an update signed before the output it spends exists.

• Multiplication in Tapscript today: 371 bytes, no soft fork

  • OP_MUL has been disabled since 2010; under BIP 342 every intermediate must fit a 4-byte CScriptNum, capping operands at 46,340
  • a 371-byte unrolled Horner product, witness-assisted on the low 16 bits of the multiplier, 13 active opcodes in the core round
  • ships with a 793-line Rocq proof, a Rust auditor, a Python reference and a regtest harness
  what does this mean?

  The construction shows that Tapscript can do multiplication now within the 4-byte CScriptNum ceiling. It unrolls shift-and-add across the multiplier bits and keeps operands on the altstack. The 46,340 limit comes from requiring each intermediate value to survive re-parsing by the next opcode, and witness-provided multiplier bits keep the script linear in hamming weight.

  That result frames the OP_MUL tradeoff. OP_MUL has appeared on wish lists since CTVMul, and a 371-byte core with machine-checked bounds can support a soft-fork opcode or support leaving the workaround in script. The Rocq proof carries the proof-specific claim: the bound proofs are checked rather than asserted.

• discussion: which of these four belongs on chain, and which is better left verifying off it?

Cryptography and Post-Quantum

• Machine-checked soundness of BIP 340 batch verification with 128-bit derived randomizers

  • sipa/bips #219 and #222 propose shrinking batch-verification randomizers from 256 to 128 bits, worth up to about 9% in libsecp256k1
  • the pen-and-paper argument treats randomizers as uniform and independent; in the secp256k1 implementation they are derived from the batch, where an attacker can choose later entries after seeing earlier randomizers
  • both derivation modes proven sound in Lean 4, random-oracle model, for up to q queries
  what does this mean?

  Batch verification depends on random weights to stop invalid signatures from canceling each other out. A proof that assumes fresh independent randomness does not directly cover deterministic weights computed from attacker-influenced input. The risk is that an adversary can search over batch contents and make the derived values line up with a forgery.

  The Lean development gives a machine-checked argument for that hashing-and-batching boundary, including the 128-bit setting behind the speedup. It is the third recent machine-checked entry in this area, after the codex32 and shrincs proofs. If the change reaches libsecp256k1, verifying nodes get the roughly 9% gain under an explicit proof rather than a hand argument.

• Compact Shielded CSV: post-quantum, private, lightweight client-side validation

  • a client-side-validation design where the per-user state stays small enough for lightweight clients, with post-quantum proofs
  • preprint posted September 25
  what does this mean?

  Client-side validation pushes coin validity checks to the spender. Each coin carries the proof chain needed to justify its history, while the shared system records history instead of maintaining a global UTXO set. That model can preserve privacy, but it makes the owner responsible for keeping and checking the data needed to spend.

  The paper focuses on making that owner-side burden small enough for phone-class use while replacing the signature and proof layer with post-quantum assumptions. CSV makes users verify chains directly; a zk metaprotocol instead relies on a published ordering plus checkable proofs. Both avoid consensus changes, and both remain research rather than shippable wallet designs.

Privacy

• Shielded Bitcoin: private transfers on the L1, no consensus changes — discussion

  • Shikhelman, Komarov and Moskvin; Bitcoin as a bulletin board for encrypted notes and zk proofs, with indexers applying the rules
  • no soft fork, no new chain, no trusted operator, no exit collateral; entering and exiting runs through security vaults via PIPEs, companion paper to come
  what does this mean?

  The construction uses the standard shielded-pool components: notes, nullifiers, and a single proof per transfer. Published data lets any participant re-derive the pool state, while indexers only apply rules to that data. Anyone can run an indexer, and an indexer has no authority beyond what the chain data supports.

  The remaining evaluation points are operational rather than semantic. Proof size on chain matters for L1 use, PIPE-based exits may inherit assumptions from the vaults they pass through, and an unpaid indexer set may be thin. The proof system's post-quantum posture also matters because the paper claims L1-compatible verification costs.

• Silent payments for multiparty wallets

  • BIP 352 sidesteps FROST and MuSig2 senders "due to lack of a security proof"; this supplies one
  • the wallet computes its ECDH share as a weighted sum of signer contributions, aggregated into a single BIP 374 proof
  what does this mean?

  A silent payment tweak depends on the aggregate key, while a multiparty wallet derives that value during a signing session among holders of key shares. The construction represents each signer's input as one term in a linear combination. An AggDLEQ proof binds those terms to correctness, so a malicious signer cannot steer the tweak without detection.

  The same algebra covers FROST, MuSig2 and nested MuSig2 by changing the weights assigned to the signer contributions. That gives wallet implementations a shared interface and a single code path across those key structures. The unresolved integration point is whether Core's silent-payment scanning accepts the resulting tweak unmodified.

Policy

• SEC proposes custody rules for investment advisers and funds holding crypto

  • Federal Register, October 6: new custody rules under the Investment Advisers Act and the Investment Company Act
  • how a registered adviser must hold client crypto assets, and who qualifies as a custodian when the asset is a key, not an account
  what does this mean?

  The proposal makes definitions the hard problem. Custody rules assumed accounts held at intermediaries, while a self-custodied key pair is not an account anywhere. The text separates cases where the adviser itself holds keys from cases where a third party holds them, then assigns the related books and records obligations.

  Hardware wallets and multisig arrangements run by an adviser's own operations team fall into the same qualification analysis the proposal applies to a qualified custodian. The comment window controls the practical result because definitions set now will shape how ETFs, treasuries, and registered advisers may hold keys for years.

Economics

• The Long Road to Bitcoin Payments

  • a payments-state-of-the-union: the tech works, a million-plus US merchants can accept it, almost nobody does, and the gap is demand
  • the threat frame is stablecoins: Stripe, Shopify and Coinbase are building them in, and the first agent-payment rails are stablecoin-shaped
  • an explicit call for moonshots, with the report kept as a living document on GitHub
  what does this mean?

  Defaults shape payment networks before users make conscious choices. Developers build on the rails their tools support, wallets ship with their partners' networks, and AI agents, the cleanest use case for programmable money, get wired to stablecoins and cards when those are the SDK paths on offer. The paper does not argue that bitcoin payments are worse. It argues that early integration choices can become hard to reverse.

  The bitcoin-side case stays practical. Lightning works in production, self-custodial wallets can hide their complexity, and building a payments app has fallen from a year of engineering to a prompt. The paper asks for demand-side inventions instead of only better plumbing: shared rails, reasons to hold and spend, and payment shapes that are not checkout. The target audience often builds rails more than it uses them.

Miscellaneous

• Steal my Bitcoin: a honeypot that held for 19.28 hours

  • a real php vulnerability exposed on a real server with real bitcoin on it; 0.02511679 BTC ($2,021) gone by October 25, 15:47 UTC
  • the challenge is closed: no bitcoin on the server now, more may come
  what does this mean?

  The experiment fixed three pieces in public: a server with a deliberate flaw, a pot anyone could claim, and a clock that measured how long discovery took. Nineteen hours gives the compromise a concrete shape. The winner had enough time for reconnaissance, but the planted hole did not survive for days in front of the internet.

  The paired writeups show the same compromise from both sides. The attacker's account explains the path that worked, while the postmortem records the defender's view of the small compromise. At 0.025 BTC, the prize sat in bug-bounty territory, and the declared starting state made the exploit reproducible rather than anecdotal.

• the winner's proof of concept

  what does this mean?

  The PoC supplies the operational record: the vulnerability, the route to it, and the takeover as it appeared from a shell. It lines those steps up with the scoreboard timeline, so the result becomes more than a transfer; it becomes a documented path from exposed service to control.

  It reads best as archaeology of a php deployment, not as a bitcoin artifact. The bitcoin makes the timer honest and makes success visible, but the lesson sits in the exploit chain itself: what the attacker could infer, reach, execute, and finally use to move the prize.

• Bitcoin Poker: private dealing, on-chain settlement

  • cryptographic dealing with selective card openings, a settlement graph in Bitcoin scripts, and a playable table on MutinyNet signet
  • from Robin Linus; the dealing protocol and the poker evaluation live in separate crate trees, with Wasm bindings and an opaque-message relay
  • play it at poker.bitvm.org
  what does this mean?

  The deck carries the cryptographic work. Players commit to cards and deal them so hidden information stays hidden until reveal, and each selective opening proves one card's value without exposing the rest of a hand. The settlement graph then maps a complete set of game outcomes into Bitcoin scripts, so payout logic does not depend on a trusted dealer holding the pot.

  Running the table on signet keeps the stakes small while exercising the whole game path: state, reveal, dispute, and payout. That sequence pressures conditional payments in ways a payment channel never reaches. The repository also exposes enough of the implementation to show which script shapes still fit after the poker game tree constrains them.