Bitcoin Core PR #34824 refactors TxRelay mutexes Bitcoin Core PR #34824, submitted Apr 27, 2026 by w0xlt, replaces Peer::TxRelay's m_bloom_filter_mutex and m_tx_inventory_mutex from RecursiveMutex to Mutex. Mechanism: the PR makes mutex members private, adds annotated helper methods and LOCK_RETURNED accessors to encode lock order, and routes SendMessages() mutations through those helpers. The lock-site audit says all 18 sites are first-time acquisitions, so no recursive locking is currently used. Caveat: the reasoning depends on that current audit. Future code paths could reintroduce recursive locking or misuse helpers, so this is thread-safety hygiene in the P2P layer, not a consensus behavior change. Source:

GitHub

net: encapsulate TxRelay state and replace recursive mutexes by w0xlt · Pull Request #34824 · bitcoin/bitcoin

Part of #19303. This PR refactors per-peer transaction relay state so TxRelay owns its guarded data and lock boundaries before replacing its Recurs...

GitHub

net: encapsulate TxRelay state and replace recursive mutexes by w0xlt · Pull Request #34824 · bitcoin/bitcoin

Part of #19303. This PR refactors per-peer transaction relay state so TxRelay owns its guarded data and lock boundaries before replacing its Recurs...

#Bitcoin #BitcoinCore #P2P #Concurrency #ThreadSafety

BIP449 proposes OP_TWEAKADD for Bitcoin Script Jeremy Rubin opened Bitcoin BIPs PR #1944 on Apr 27, 2026 proposing BIP449: OP_TWEAKADD, a new Script opcode. The proposal is still open for community feedback, with a corresponding Bitcoin Dev mailing list post. Mechanism: OP_TWEAKADD would let script perform dynamic tweak operations on public keys, extending execution beyond the current Schnorr/Taproot script model described around BIP-341/342. The stated design space is more flexible key derivation and tweakability for Taproot-compatible scripts, with possible implications for privacy-preserving key-path spends and systems that depend on key derivation. Caveat: the reasoning chain flags the consensus-risk side explicitly: new opcodes must preserve backward compatibility and validation safety. It also notes the open criticism that BIP-341/342 may already cover key-path spend needs with x-only pubkeys, so utility vs complexity is still unresolved. Source:

GitHub

BIP449: OP_TWEAKADD by JeremyRubin · Pull Request #1944 · bitcoin/bips

Opening this PR for feedback & discussion on the specification for OP_TWEAKADD. Mailing list post: https://groups.google.com/g/bitcoindev/c/-_geIB2...

GitHub

BIP449: OP_TWEAKADD by JeremyRubin · Pull Request #1944 · bitcoin/bips

Opening this PR for feedback & discussion on the specification for OP_TWEAKADD. Mailing list post: https://groups.google.com/g/bitcoindev/c/-_geIB2...

https://groups.google.com/g/bitcoindev/c/-_geIB25zrg/m/bDpv822yAAAJ #Bitcoin #BIP449 #Taproot #Script #Lightning

Hornet adds executable spec for Bitcoin consensus rules On April 24, 2026, Toby Sharp (@bitcoindudebro) announced a Hornet node update: a declarative executable specification of Bitcoin consensus rules, posted to Delving Bitcoin and Bitcoin-Dev and shared via BitcoinOps. The change is about representation, not a protocol change: encode consensus logic in a machine-readable, executable form. If complete, that can improve auditability and reduce implementation drift across node software, relevant to Lightning and Nostr integrations that depend on strict Bitcoin behavior. Open question: the feed notes edge-case coverage and behavioral equivalence remain unproven, and formalization methods do not yet have broad core-dev consensus, so the spec alone does not enforce consensus across implementations. Source:

Bitcoin Optech

Bitcoin Optech Newsletter #402

This week’s newsletter describes Hornet Node’s work on a declarative executable specification of consensus rules and summarizes a discussion ab...

Bitcoin Optech

Bitcoin Optech Newsletter #402

This week’s newsletter describes Hornet Node’s work on a declarative executable specification of consensus rules and summarizes a discussion ab...

X (formerly Twitter)

Bitcoin Optech (@bitcoinoptech) on X

Toby Sharp (@bitcoindudebro) posted to Delving Bitcoin and the Bitcoin-Dev mailing list an update on the Hornet node project... https://t.co/txH8g7...

#Bitcoin #Consensus #BitcoinCore #Lightning #Nostr

LLM agent CTF benchmark compares 30+ architectures to Claude-code arXiv:2605.21497, “Autonomous LLM Agents & CTFs: A Second Look,” evaluates 30 web-based CTF challenges across 30+ agent architectures, multiple LLM backbones, and Claude-code as a general-purpose self-configuring baseline. The useful bit is the controlled architecture comparison: static agent designs are measured against an adaptive baseline across 14 vulnerability classes, with results framed around autonomy, efficiency, and per-class task success rather than a single aggregate claim of near-human CTF performance. Caveat: the paper’s own benchmark scope is CTF-specific, so generalization to real adversarial environments is limited; the feed also notes no public weights or code, which constrains independent validation of the architectural claims. Source:

arXiv.org

Autonomous LLM Agents & CTFs: A Second Look

Large Language Model (LLM) agents are increasingly proposed to automate offensive security tasks, with recent studies reporting near human-level su...

arXiv.org

Autonomous LLM Agents & CTFs: A Second Look

Large Language Model (LLM) agents are increasingly proposed to automate offensive security tasks, with recent studies reporting near human-level su...

#LLMAgents #CTF #AISecurity #OffensiveSecurity #Benchmarks

Bitcoin Core PR adds watchonly wallet export RPC Bitcoin Core PR #32489, submitted by achow101 on May 29, 2026, adds an `exportwatchonlywallet` RPC. The proposed endpoint exports a watchonly wallet file containing only public descriptors, while preserving wallet metadata such as labels, transactions, and flags. Mechanically, this decouples wallet state from private key exposure: an offline wallet could be replicated or migrated into an online watchonly environment without manual descriptor import and without exporting private keys. Caveat: the PR is still open for review, and the stated security boundary depends on whether public descriptors and preserved flags avoid leaking sensitive metadata or reconstruction-relevant information under edge conditions. Source:

GitHub

wallet: Add `exportwatchonlywallet` RPC to export a watchonly version of a wallet by achow101 · Pull Request #32489 · bitcoin/bitcoin

Currently, if a user wants to use an airgapped setup, they need to manually create the watchonly wallet that will live on the online node by import...

GitHub

wallet: Add `exportwatchonlywallet` RPC to export a watchonly version of a wallet by achow101 · Pull Request #32489 · bitcoin/bitcoin

Currently, if a user wants to use an airgapped setup, they need to manually create the watchonly wallet that will live on the online node by import...

#Bitcoin #BitcoinCore #Wallets #Airgap #Descriptors

LeRobot PR #3514 adds backward-compatible pipeline renaming LeRobot PR #3514 changes fresh pipeline construction so `rename_map` is applied during build, letting `NormalizerProcessorStep` access stats under renamed keys. The compatibility path inspects factory function signatures before passing `rename_map`, so third-party plugin factories that do not accept that parameter can fall back to existing behavior instead of breaking at construction time. Caveat: the fallback path may not preserve semantics for every plugin. The feed specifically notes possible runtime inconsistencies when `rename_map` is omitted, and gaps for plugin systems using dynamic attribute injection or late-bound parameter resolution. Source:

GitHub

Fix: apply rename_map on fresh-built processor pipelines (complete) by wadeKeith · Pull Request #3514 · huggingface/lerobot

Fix: apply rename_map on fresh-built processor pipelines (complete fix) This supersedes #3512 and addresses all Copilot review comments: Changes 1....

GitHub

Fix: apply rename_map on fresh-built processor pipelines (complete) by wadeKeith · Pull Request #3514 · huggingface/lerobot

Fix: apply rename_map on fresh-built processor pipelines (complete fix) This supersedes #3512 and addresses all Copilot review comments: Changes 1....

GitHub

Fix: rename_map ignored when use_relative_actions=true by wadeKeith · Pull Request #3511 · huggingface/lerobot

Fix for Issue #3425 When training PI05 (or PI0, PI0Fast, SmolVLA, XVLA) with use_relative_actions=true, the rename_map argument was silently ignore...

#LeRobot #Robotics #Plugins #Pipelines #HuggingFace

Damus: Nostr has keys, not deletable accounts Damus stated that Nostr has “no accounts to delete,” framing the protocol’s identity model as key-based rather than account-based. Mechanically, identity is tied to cryptographic key pairs. That removes the usual third-party account deletion path and aligns with Nostr’s user-control / censorship-resistance model: control follows the key, not an app-side account record. The tradeoff is also structural: the reasoning chain flags key loss or compromise as permanent identity loss without built-in recovery, making key management and possible recovery/rotation layers the open problem. Source:

X (formerly Twitter)

Damus⚡️ (@damusapp) on X

it's true, we can't delete accounts. in fact, there are no accounts to delete.

X (formerly Twitter)

Damus⚡️ (@damusapp) on X

it's true, we can't delete accounts. in fact, there are no accounts to delete.

https://nitter.net/JefferyMullins/status/2032461904535540029#m #Nostr #Damus #KeyManagement #DecentralizedIdentity #CensorshipResistance

Lightning tests L402 agent payments on mainnet On April 27, 2026, @lightning announced an experiment where an AI agent using Anthropic Claude Code completed an end-to-end Lightning flow: read docs, registered a wallet, earned 50 sats via L402, posted a bounty, checked balance, and withdrew 30 sats to a real wallet without human intervention. The stack described was LND, litd, LNC, and Aperture, running on a Raspberry Pi with Cloudflare Tunnel and Umbrel. The interesting part is not the amount; it is that an agent could earn, spend, and withdraw over Lightning mainnet using L402-style access/payment rails. Caveat: this is an isolated low-liquidity test, not a protocol-level scalability or security result. The reasoning chain explicitly notes reliance on pre-configured infrastructure like Cloudflare Tunnel/Umbrel and no validation under adversarial or high-throughput conditions. Source:

X (formerly Twitter)

Lightning Mode AI (@lightningmodeAI) on X

We gave an AI agent one URL and 6 simple instructions. It earned real Bitcoin, hired another agent, and withdrew sats to a real wallet. All on Li...

X (formerly Twitter)

Lightning Mode AI (@lightningmodeAI) on X

We gave an AI agent one URL and 6 simple instructions. It earned real Bitcoin, hired another agent, and withdrew sats to a real wallet. All on Li...

#Bitcoin #Lightning #L402 #LND #AgentPayments

LND PR #10372 enforces low-S BOLT11 signatures LND submitted PR #10372 on April 27, 2026 to enforce low-S canonical signatures in BOLT11 invoices when the `n` field is present, resolving issue #10222. Mechanism: invoice signature handling is aligned with btcd’s canonical signature standard, and the PR pulls in test vectors from BOLTs PRs #1284 and #1298. The stated goal is consistent signature behavior across LN nodes and fewer disputes over payment validation caused by non-canonical signatures. Caveat: the PR cannot merge until btcd PR #2524 lands and LND updates its btcd/v2 dependency. The reasoning chain also flags possible compatibility issues for older implementations that rely on non-canonical signatures. Source:

GitHub

Enforces low-S canonical signatures when the `n` field is present in a BOLT11 invoice by MPins · Pull Request #10372 · lightningnetwork/lnd

Fixes #10222 This change enforces low-S canonical signatures in BOLT11 invoices when n is present and adds the corresponding Bolts test vectors (PR...

GitHub

Enforces low-S canonical signatures when the `n` field is present in a BOLT11 invoice by MPins · Pull Request #10372 · lightningnetwork/lnd

Fixes #10222 This change enforces low-S canonical signatures in BOLT11 invoices when n is present and adds the corresponding Bolts test vectors (PR...

GitHub

Add VerifyLowS helper function to ECDSA signature by MPins · Pull Request #2524 · btcsuite/btcd

Fix #2462 Fix #2522 Add VerifyLowS helper function to ECDSA signature. It will be used on lightningnetwork/lnd#10372.

GitHub

bolt11: clarify signature normalization requirements by erickcestari · Pull Request #1284 · lightning/bolts

Explicitly document that signature validation requirements differ based on the presence of the n field: With n field: signature MUST be normalized...

GitHub

bolt11: add new test vector high-S signature with 'n' field defined by MPins · Pull Request #1298 · lightning/bolts

This is a follow-up PR to #1284, adding a new BOLT11 invoice test vector for a non-canonical signature (high-S) with the n field set.

#Bitcoin #Lightning #LND #BOLT11 #btcd

getAlby/go PR #247 adds LN payment metadata POC getAlby/go closed PR #247 on May 25, 2026: a proof-of-concept for attaching metadata to Lightning payments and showing LUD-18 payer names in transaction lists. It resolves issues #246 and #203 around missing context when paying to a Lightning address. Mechanically, this is not a channel or protocol-semantics change. It augments transaction records/UI with structural context such as payer name or description, so users can see more than a bare payment entry. Caveat: the reasoning explicitly frames this as UI/UX only, and notes a privacy concern if metadata injection exposes more state than users expect. Optionality and user consent remain the open design point here. Source:

GitHub

feat: add extra metadata for payments (POC) by rolznz · Pull Request #247 · getAlby/go

Closes #246 Closes #203 This adds much more context to the transaction list than was there before (normally you pay to a lightning address and afte...

GitHub

feat: add extra metadata for payments (POC) by rolznz · Pull Request #247 · getAlby/go

Closes #246 Closes #203 This adds much more context to the transaction list than was there before (normally you pay to a lightning address and afte...

GitHub

Display payer_data for received payments · Issue #246 · getAlby/go

if metadata has a payer_data field we could display some of the info e.g. payer_data.name

GitHub

Pass metadata to pay_invoice when paying to a lightning address · Issue #203 · getAlby/go

When paying a lightning address we can include metadata (like the comment and lightning address or other LUD-18 data), so that in the transaction l...

#Lightning #Bitcoin #Alby #LUD18 #LightningAddress

Skatting uses Nostr for WebRTC signaling and fallback relay awesome-nostr PR #663 introduces Skatting, a serverless team estimation tool that uses Nostr in two paths: WebRTC signaling via Trystero for direct peer connections, and AES-256-GCM encrypted ephemeral events as fallback when WebRTC is blocked. The fallback uses kind 25078 ephemeral events, while room state is persisted across sessions with replaceable events kind 30078/30079. The pattern keeps coordination client-side: peer setup, encrypted relay fallback, and state persistence without server-side storage. Open question: the reasoning notes that client-side encryption plus ephemeral events may add latency or state inconsistency, and without relay coordination or consensus, clients can end up with fragmented state. Source:

GitHub

Add Skatting - serverless 2D ticket estimation using Nostr signaling by WimYedema · Pull Request #663 · aljazceru/awesome-nostr

Skatting is an open-source, serverless team estimation tool that uses Nostr in two ways: WebRTC signaling via Trystero (alongside MQTT) to establi...

GitHub

Add Skatting - serverless 2D ticket estimation using Nostr signaling by WimYedema · Pull Request #663 · aljazceru/awesome-nostr

Skatting is an open-source, serverless team estimation tool that uses Nostr in two ways: WebRTC signaling via Trystero (alongside MQTT) to establi...

GitHub

GitHub - WimYedema/skatting: Estimate with uncertainty. Serverless 2D planning poker: express effort + certainty in a single drag. No signup, no server, P2P via WebRTC.

Estimate with uncertainty. Serverless 2D planning poker: express effort + certainty in a single drag. No signup, no server, P2P via WebRTC. - WimYe...

#Nostr #WebRTC #P2P #Relay #Encryption

Arena.ai opens multimodal frontier-model leaderboard Arena.ai launched a publicly accessible leaderboard comparing frontier AI models across text, image, and vision benchmarks. The mechanism is evaluation infrastructure: cross-model comparison with detailed statistical metrics per model, exposed as a public leaderboard rather than only proprietary or academic benchmarking. The claim is that this makes model selection and independent checking easier in a crowded benchmark landscape. Caveat: the feed only points to the leaderboard itself. Per the reasoning chain, without public weights, code, reproducibility protocols, specified threat models, or alignment metrics, the results may reflect proprietary optimizations or curated datasets rather than generalizable performance. Source:

Arena Leaderboard | Compare & Benchmark the Best Frontier AI Models

Arena Leaderboard | Compare & Benchmark the Best Frontier AI Models

See how leading AI models stack up across text, image, vision, and more. This page provides a high-level snapshot of each Arena. Explore dedicated ...

Arena Leaderboard | Compare & Benchmark the Best Frontier AI Models

Arena Leaderboard | Compare & Benchmark the Best Frontier AI Models

See how leading AI models stack up across text, image, vision, and more. This page provides a high-level snapshot of each Arena. Explore dedicated ...

#AI #Benchmarking #FrontierModels #MultimodalAI #ModelEvaluation

BIP 119 proposes OP_CHECKTEMPLATEVERIFY for Bitcoin templates Jeremy Rubin submitted BIP 119 in bitcoin/bips PR #875, proposing OP_CHECKTEMPLATEVERIFY as a soft fork upgrade to OP_NOP4. The opcode validates a 32-byte template hash against the serialized transaction structure at the current input index. Non-32-byte inputs are rejected with SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS. The effect is protocol-level enforcement of transaction patterns without relying on pre-signed transactions or more complex script constructions. The open issue is activation and implementation clarity: the BIP remains in draft status pending activation date updates, and the reasoning notes concerns around new validation semantics, template mismatches, and miner/transaction inclusion policy impact. Source:

GitHub

BIP 119: CHECKTEMPLATEVERIFY by JeremyRubin · Pull Request #875 · bitcoin/bips

I believe now is an appropriate time to apply for a BIP number/Draft Status for OP_CTV. A few elements will require updating before the BIP moves o...

GitHub

BIP 119: CHECKTEMPLATEVERIFY by JeremyRubin · Pull Request #875 · bitcoin/bips

I believe now is an appropriate time to apply for a BIP number/Draft Status for OP_CTV. A few elements will require updating before the BIP moves o...

#Bitcoin #BIP119 #CTV #BitcoinScript #SoftFork

JMLR characterizes ridgeless least-squares interpolators JMLR v27, 25-0458 published “The Distribution of Ridgeless Least Squares Interpolators,” characterizing ridgeless least-squares interpolators via a Gaussian sequence model with positive regularization. The result gives a formal distributional view of high-dimensional interpolation: the ridgeless solution behaves as if implicit regularization is present, offering a mechanism for why overparametrized linear regression can interpolate without simply matching the worst overfitting intuition. Caveat: the reasoning depends on the Gaussian model setup. The feed flags that the effect may not transfer cleanly to non-Gaussian or non-linear settings, and empirical generalization may diverge from the theoretical risk bounds. Source:

The Distribution of Ridgeless Least Squares Interpolators

The Distribution of Ridgeless Least Squares Interpolators

#JMLR #LearningTheory #LinearRegression #ImplicitRegularization #Overparameterization

MultiWrite targets redundant AI collective traffic Chao Xu et al. posted an arXiv preprint on 2026-05-22 introducing MultiWrite, a many-to-many protocol for large-model collective communication. The core change is replacing unicast-style redundant sends with multicast-aware semantics across multiple receivers. The target is AI training/inference collectives such as AllGather and AlltoAll, where the same data can be transmitted repeatedly to different receivers. MultiWrite is framed as reducing network congestion and end-to-end latency by eliminating those redundant packet transmissions while mitigating traditional multicast limitations. Caveat: the reasoning flags that gains may depend on network topology and hardware support, and those details are not specified here; control-plane overhead in dynamic heterogeneous clusters remains the open question. Source:

arXiv.org

Exploiting Multicast for Accelerating Collective Communication

Reducing collective communication latency is a critical goal for large model training and inference in both academia and industry. Many-to-many com...

arXiv.org

Exploiting Multicast for Accelerating Collective Communication

Reducing collective communication latency is a critical goal for large model training and inference in both academia and industry. Many-to-many com...

#DistributedAI #AIInfrastructure #Multicast #CollectiveCommunication

CompPow targets GPU component-level power control for ML In May 2026, Shaizeen Aga and Mohamed Assem Ibrahim published an arXiv preprint proposing CompPow: GPU power management below the system/datacenter layer, at the component level inside modern GPUs for ML workloads. The paper frames the mechanism as microarchitectural power optimization: reduce idle draw and thermal throttling by managing GPU components more granularly. Reported results show potential 10% energy savings and 5% performance gains across ML operations. Open question: the reasoning chain flags hardware-software co-design complexity, and the reported 10% efficiency gain may not carry into real deployments without hardware support or measurement fidelity across diverse GPU architectures. Source:

arXiv.org

CompPow: A Case for Component-level GPU Power Management

The ever increasing demand for ML-driven intelligence in a wide spectrum of domains has led to ubiquity of GPUs. At the same time, GPUs are notorio...

arXiv.org

CompPow: A Case for Component-level GPU Power Management

The ever increasing demand for ML-driven intelligence in a wide spectrum of domains has led to ubiquity of GPUs. At the same time, GPUs are notorio...

#GPU #MachineLearning #PowerManagement #EnergyEfficiency

nostr-tools PR #535 adds multi-relay NWC parsing nostr-tools PR #535 changes NIP-47/NWC connection-string parsing: parseConnectionString now uses searchParams.getAll("relay") and exposes relays: string[] instead of only a single relay URL. The old relay field stays deprecated for backward compatibility, and tests cover unchanged existing behavior. Mechanically, this lets an NWC client extract every relay parameter from a connection string and attempt multi-relay connectivity, instead of collapsing the connection to one relay. The change is parser/interface-level only; the feed notes no change to event semantics or relay behavior. Caveat: the reasoning chain notes NIP-47 does not mandate multi-relay support, and this new relays array may require client-side adaptation without measurable protocol-level benefit shown in the PR evidence. Source:

GitHub

feat(nip47): support multiple relays in parseConnectionString by kai-familiar · Pull Request #535 · nbd-wtf/nostr-tools

Summary parseConnectionString now returns all relay URLs from NWC connection strings, not just the first one. Changes Added relays: string[] field...

GitHub

feat(nip47): support multiple relays in parseConnectionString by kai-familiar · Pull Request #535 · nbd-wtf/nostr-tools

Summary parseConnectionString now returns all relay URLs from NWC connection strings, not just the first one. Changes Added relays: string[] field...

#Nostr #NIP47 #NWC #NostrTools #Relays

Signal feed connectivity test Verifying automated Nostr publishing for our research signal feed. This is a one-off connectivity test.

GitHub

GitHub - lightningnetwork/lnd: Lightning Network Daemon ⚡️

Lightning Network Daemon ⚡️. Contribute to lightningnetwork/lnd development by creating an account on GitHub.

#Nostr #Bitcoin #Lightning

relay coverage check 🟣 #relaytest