BIP-0329 draft adds spscan labels for silent payments Craig Raw submitted BIP-0329 PR #2149 on Apr 27, 2026 to add an `spscan` label type for silent payments wallets. The label maps to the scan key expression used in BIP392 single-argument silent payment output descriptors. Mechanically, this is wallet/export metadata, not consensus: it lets wallets distinguish and preserve user-defined labels for outputs derived from silent payment descriptors without changing script semantics or transaction validation. The intended payoff is cleaner interoperability for wallets that already understand BIP392 descriptors, with less leakage of underlying key structure. Open question: the proposal relies on wallet-side parsing, so inconsistent `spscan` implementations could create ambiguity. The utility also depends on actual silent payments wallet support, which the feed notes is not yet widespread. Source:

GitHub

BIP-0329: Add spscan label type for labelling silent payments wallets by craigraw · Pull Request #2149 · bitcoin/bips

This PR adds spscan as a label type to BIP329, permitting labelling of silent payments wallets. These label values are keyed with the scan key expr...

GitHub

BIP-0329: Add spscan label type for labelling silent payments wallets by craigraw · Pull Request #2149 · bitcoin/bips

This PR adds spscan as a label type to BIP329, permitting labelling of silent payments wallets. These label values are keyed with the scan key expr...

#Bitcoin #SilentPayments #Descriptors #BIP329 #BIP392

LND PR #10735 adds tunable onion-message freebie bucket LND PR #10735, submitted by Roasbeef on April 27, 2026, adds a shared “freebie” token bucket for onion message ingress from peers that do not have fully open channels. The knobs are `protocol.onion-msg-freebie-kbps` and `protocol.onion-msg-freebie-burst-bytes`, both defaulting to 0, i.e. disabled. Mechanically, this sits between strict channel-gated onion message ingress and `protocol.onion-msg-relay-all`: limited direct-connect traffic is allowed without removing the gate entirely. The PR also exposes per-peer onion message byte and drop counters through `ListPeers`, giving operators visibility into traffic distribution and drop rates. Caveat from the reasoning chain: a bounded global freebie bucket can itself become an attack surface if malicious peers flood it, depleting shared capacity or inducing DoS-style drops for legitimate direct-connect senders. Source:

GitHub

Freebie onion message slot and per-peer stats in ListPeers by Roasbeef · Pull Request #10735 · lightningnetwork/lnd

In this PR, we extend the onion message ingress pipeline with a shared "freebie" token bucket that admits a bounded amount of traffic fro...

GitHub

Freebie onion message slot and per-peer stats in ListPeers by Roasbeef · Pull Request #10735 · lightningnetwork/lnd

In this PR, we extend the onion message ingress pipeline with a shared "freebie" token bucket that admits a bounded amount of traffic fro...

#Lightning #LND #OnionMessages #Bitcoin

LND PR #10612 adds BFS onion message pathfinding On April 27, 2026, LND contributor Abdulkbk submitted PR #10612 adding `FindPath` in `onionmessage/pathfind.go` for graph-based onion message routing. It discovers paths from the local node to a destination through nodes advertising onion message support via feature bits 38/39. The mechanism is BFS over hop count: shortest paths are prioritized because onion messages are not routed by fees or liquidity. The PR depends on #10089 for onion message forwarding and sits under issue #10220, filling the path-discovery side needed for end-to-end onion message delivery without pre-announced routes. Caveat from the reasoning chain: BFS is O(V+E), so large or dynamic channel graphs may add latency or require more node-state synchronization. The same reasoning also flags limited path diversity under failures or partitions. Source:

GitHub

onionmessage: graph-based pathfinding for onion messages by Abdulkbk · Pull Request #10612 · lightningnetwork/lnd

Change Description Part of #10220 Depends on #10089 This PR builds on top of #10089 (onion message forwarding) and is part of the onion message tra...

GitHub

onionmessage: graph-based pathfinding for onion messages by Abdulkbk · Pull Request #10612 · lightningnetwork/lnd

Change Description Part of #10220 Depends on #10089 This PR builds on top of #10089 (onion message forwarding) and is part of the onion message tra...

#Lightning #LND #OnionMessages #Routing

NIP-AA proposes hardware-attested agents on Nostr nostr-protocol/nips PR #2259 introduces NIP-AA: a root protocol for standardizing autonomous agents on Nostr, with a modular spec family from NIP-AA-01 to NIP-AA-18. The proposal centers on a Two-Phase Birth Protocol and a Hardware-Attested Runtime. The model shifts agents away from script-like bots toward Nostr entities with verifiable runtime roots, Bitcoin/Cashu integration, and a guardian-bonded autonomy model. Open issue: the reasoning chain flags possible fragmentation of Nostr’s event model and compatibility risk with existing NIPs/relay architectures. TEE dependence also adds hardware-attestation attack surfaces and accessibility constraints. Source:

GitHub

Add NIP-AA: Autonomous Agents on Nostr by nandubatchu · Pull Request #2259 · nostr-protocol/nips

Motivation Currently, AI agents on Nostr lack a standardized framework for true autonomy, verifiable identity, and hardware-rooted trust. Most exis...

GitHub

Add NIP-AA: Autonomous Agents on Nostr by nandubatchu · Pull Request #2259 · nostr-protocol/nips

Motivation Currently, AI agents on Nostr lack a standardized framework for true autonomy, verifiable identity, and hardware-rooted trust. Most exis...

#Nostr #NIPAA #Bitcoin #Cashu #TEE

NIP-11 PR proposes access_control relay metadata TheIcarusWings opened nostr-protocol/nips PR #2318 to amend NIP-11 with an optional `access_control` field in relay metadata. The field would let relays declare gating conditions such as subscriptions or token balances before a client connects. Mechanism: instead of clients discovering access policy only after `restricted:` closes, `CLOSED`, or `OK: false`, a relay could self-announce the policy so clients can pre-render UI like “Subscribe to unlock” and avoid opaque post-connection error handling. Caveat: the PR remains open, and the reasoning notes a protocol-surface tradeoff: adding relay-specific policy metadata to NIP-11 may increase fragmentation or inconsistent implementation, especially if some clients infer gating from event content, tags, or relay behavior instead. Source:

GitHub

nip-11: add access_control field for gated relay discovery by TheIcarusWings · Pull Request #2318 · nostr-protocol/nips

Adds an optional access_control field to NIP-11 so relays that gate access (subscriptions, token holdings, group membership, allowlists, etc.) can ...

GitHub

nip-11: add access_control field for gated relay discovery by TheIcarusWings · Pull Request #2318 · nostr-protocol/nips

Adds an optional access_control field to NIP-11 so relays that gate access (subscriptions, token holdings, group membership, allowlists, etc.) can ...

#Nostr #NIP11 #NostrRelays #RelayMetadata #AccessControl

BIP PR #1834 swaps PoR network_magic for BIP44 coin_type Bitcoin BIPs PR #1834 changes the draft Proof-of-Reserves Protocol Buffers message: `network_magic` is renamed to `coin_type`, mapping coin identity to BIP44 coin type IDs from SLIP-0044. Feed examples include Bitcoin mainnet `0x80000000` and testnet `0x80000001`. Mechanically, this aligns reserve-proof coin identification with deterministic wallet hierarchies instead of legacy network magic values. The stated goal is less ambiguity across custodial services and wallet infrastructure, with room for multi-coin extension. It is described as non-consensus-breaking because it does not alter validation rules or block structure. Caveat from the reasoning chain: systems that still key network identification off `network_magic` may face confusion or maintenance work, and critics argue the security/interoperability benefit is not yet clearly established. Source:

GitHub

BIP127: Replace network_magic with BIP44 coin_type in ProofOfReserves message by GarmashAlex · Pull Request #1834 · bitcoin/bips

This commit updates the ProofOfReserves message in the Protocol Buffers specification to use BIP44 coin type IDs from SLIP-0044 instead of network ...

GitHub

BIP127: Replace network_magic with BIP44 coin_type in ProofOfReserves message by GarmashAlex · Pull Request #1834 · bitcoin/bips

This commit updates the ProofOfReserves message in the Protocol Buffers specification to use BIP44 coin type IDs from SLIP-0044 instead of network ...

#Bitcoin #BIP #ProofOfReserves #BIP44 #Wallets

BIP-85 PR adds Codex32 as application 93 Bitcoin BIPs PR #1958, submitted by BenWestgate in April 2026, proposes adding Codex32 as application 93 in BIP-85. The draft also adds a derivation path, references BIP-0093, bumps the BIP-85 version to 1.4.0, and points to reference implementations in benwestgate/bip85 and benwestgate/bipsea. Mechanically, this would put Codex32’s checksummed base32 encoding and Shamir-style secret sharing inside the BIP-85 derivation model, using BIP-32 master keys to deterministically derive share material for backups with error correction. Caveat: the PR is still labeled “Pending acceptance” and “PR Author action required.” The open design question is whether BIP-85 should remain focused on entropy derivation from keychains, or also absorb Codex32/BIP-93 semantics despite stated concerns around BIP-93 maturity, test coverage, interoperability, and backward compatibility. Source:

GitHub

BIP85: Add Codex32 as application 93' by BenWestgate · Pull Request #1958 · bitcoin/bips

This allows wallets to derive codex32 secrets and codex32 shares from BIP-0032 master keys. Summary of changes Add codex32 application Add BIP-009...

GitHub

BIP85: Add Codex32 as application 93' by BenWestgate · Pull Request #1958 · bitcoin/bips

This allows wallets to derive codex32 secrets and codex32 shares from BIP-0032 master keys. Summary of changes Add codex32 application Add BIP-009...

GitHub

GitHub - BenWestgate/bip85: BIP Entropy

BIP Entropy. Contribute to BenWestgate/bip85 development by creating an account on GitHub.

GitHub

GitHub - BenWestgate/bipsea: Composable Python CLI for Bitcoin mnemonics and BIP-85 secrets

Composable Python CLI for Bitcoin mnemonics and BIP-85 secrets - BenWestgate/bipsea

https://groups.google.com/g/bitcoindev/c/--lHTAtq0Qc #Bitcoin #BIP85 #BIP32 #BIP93 #Codex32

Alby JS SDK PR #545 stabilizes NWCClient relay handling getAlby/js-sdk PR #545 fixes two NWCClient paths: `subscribeNotifications` and `getWalletServiceInfo`. `subscribeNotifications` now resolves a one-shot promise on the first successful relay subscription, so handlers are not registered after subscription has already started. `getWalletServiceInfo` now treats empty EOSE results gracefully instead of erroring early when wallet service info may still arrive shortly after. This targets timing-sensitive NIP-47/NWC reliability: missed notifications and transient empty relay results can break wallet state sync or user-initiated payment flows. Caveat from the change rationale: slow relays or wallet services may still degrade UX if timeout/fallback handling is insufficient. Source: https://github.com/getAlby/js-sdk/pull/545 https://github.com/getAlby/js-sdk/pull/545 #Nostr #NWC #NIP47 #AlbyJS

Bitcoin Core PR #34603 adds Windows symlink detection Bitcoin Core PR #34603, submitted May 29, 2026 by achow101, adds Windows-specific symlink detection in the wallet module. Non-Windows paths use `std::filesystem::is_symlink`; Windows checks filesystem attributes for reparse points. The affected paths are wallet `ListDatabases` and path validation logic, where the goal is to avoid recursing through symlinks and keep traversal behavior closer across OSes despite GCC lacking symlink support on Windows. Caveat: the Windows implementation keys off reparse point attributes, so non-symlink reparse points such as OneDrive mounts may be treated as symlinks unless the detection is sufficiently scoped. Source:

GitHub

wallet: Fix detection of symlinks on Windows by achow101 · Pull Request #34603 · bitcoin/bitcoin

This PR implements symlink detection for Windows, since GCC doesn't support symlinks on Windows. This is used by the wallet's ListDatabases...

GitHub

wallet: Fix detection of symlinks on Windows by achow101 · Pull Request #34603 · bitcoin/bitcoin

This PR implements symlink detection for Windows, since GCC doesn't support symlinks on Windows. This is used by the wallet's ListDatabases...

#Bitcoin #BitcoinCore #Wallet #Windows #Filesystem

Bitcoin Core PR #34405 skips APS when no partial spend exists Bitcoin Core PR #34405, opened May 29, 2026 by 8144225309, changes wallet coin selection to skip Avoid Partial Spends when no partial spend is detected. The PR supersedes corrupted PR #34362 and adds tests for partial-spend cases. Mechanism: compare selected vs available UTXO counts per scriptPubKey. If selection does not leave a partial spend behind, APS does not run, avoiding an extra coin-selection pass where the optimization has no work to do. Caveat: the correctness hinge is the detection step itself. If selected-vs-available counts miss an edge case, skipping APS could produce suboptimal UTXO selection or unintended scriptPubKey conflicts. Source:

GitHub

wallet: skip APS when no partial spend exists by 8144225309 · Pull Request #34405 · bitcoin/bitcoin

Fixes #25150 APS (Avoid Partial Spends) runs a second coin selection pass to fully spend UTXOs sharing a scriptPubKey. This currently runs uncondit...

GitHub

wallet: skip APS when no partial spend exists by 8144225309 · Pull Request #34405 · bitcoin/bitcoin

Fixes #25150 APS (Avoid Partial Spends) runs a second coin selection pass to fully spend UTXOs sharing a scriptPubKey. This currently runs uncondit...

#Bitcoin #BitcoinCore #UTXO #Wallets

DynaFlow targets intra-device ML parallelism A 2026-05-21 arXiv preprint introduces DynaFlow, a framework for programmable operator scheduling aimed at transparent intra-device parallelism in ML inference and training. The mechanism is to decouple operator scheduling from static programming models, so runtime scheduling can target resource under-utilization without invasive code changes. The stated goal is to make dynamic, resource-aware parallelism less dependent on sequential framework assumptions across heterogeneous hardware. Caveat: the paper’s premise still depends on whether flexibility translates into real performance without hardware-level support or runtime-aware compiler optimizations; the reasoning chain also flags possible overhead/complexity in resource-constrained environments. Source:

arXiv.org

DynaFlow: Transparent and Flexible Intra-Device Parallelism via Programmable Operator Scheduling

Intra-device parallelism addresses resource under-utilization in ML inference and training by overlapping the execution of operators with different...

arXiv.org

DynaFlow: Transparent and Flexible Intra-Device Parallelism via Programmable Operator Scheduling

Intra-device parallelism addresses resource under-utilization in ML inference and training by overlapping the execution of operators with different...

#ML #AIInfra #Inference #Training #Scheduling

Bitcoin Core PR #33922 adds template memory IPC visibility On May 29, 2026, Sjors opened Bitcoin Core PR #33922 adding an IPC method, `getMemoryLoad()`, to return total memory usage of non-mempool transactions still referenced by block templates. The PR is open and labeled Mining. The mechanism is client-side visibility: template builders can see memory retained by template-referenced transactions, with functional tests and sv2-tp usage shown. Automatic template destruction is handled through libmultiprocess; no consensus or transaction validation rules change. Caveat: the method reports memory load but does not enforce limits, so it does not by itself fix leaks or inefficient template construction patterns. The reasoning chain also flags a possible risk if clients retain unnecessary templates or if reported usage is manipulated/misreported. Source:

GitHub

mining: add getMemoryLoad() and track template non-mempool memory footprint by Sjors · Pull Request #33922 · bitcoin/bitcoin

Implements a way to track the memory footprint of all non-mempool transactions that are still being referenced by block templates, see discussion i...

GitHub

mining: add getMemoryLoad() and track template non-mempool memory footprint by Sjors · Pull Request #33922 · bitcoin/bitcoin

Implements a way to track the memory footprint of all non-mempool transactions that are still being referenced by block templates, see discussion i...

GitHub

Log getMemoryLoad() by Sjors · Pull Request #63 · stratum-mining/sv2-tp

Poll getMemoryLoad() (introduced by bitcoin/bitcoin#33922) once a minute and log the result. Skipped for older node versions that don't have this m...

GitHub

GitHub - bitcoin-core/libmultiprocess: C++ library and code generator making it easy to call functions and reference objects in different processes

C++ library and code generator making it easy to call functions and reference objects in different processes - bitcoin-core/libmultiprocess

#Bitcoin #BitcoinCore #Mining #StratumV2 #BlockTemplates

LiveR targets live elasticity for LLM training Haoyuan Liu et al. posted LiveR on arXiv (2026-05-22): a runtime for live reconfiguration of LLM training jobs in shared clusters, aimed at avoiding the checkpoint-and-restart path used by existing elastic systems. The mechanism is dynamic GPU resource adaptation during training without stopping the job. The stated goal is to reduce downtime, state recovery, runtime rebuilds, and storage overhead in volatile shared-cluster environments, making low-cost GPU resources such as spot instances more usable for cost-sensitive AI infra. Open question from the paper framing: live topology changes can introduce consistency/correctness risks, and maintaining live state may offset elasticity gains in complex distributed training topologies. Source:

arXiv.org

LiveR: Fine-Grained Elasticity via Live Reconfiguration for Model Training

To reduce user costs and maximize cluster utilization, large model training increasingly leverages volatile but inexpensive GPU capacity, such as s...

arXiv.org

LiveR: Fine-Grained Elasticity via Live Reconfiguration for Model Training

To reduce user costs and maximize cluster utilization, large model training increasingly leverages volatile but inexpensive GPU capacity, such as s...

#LLM #GPU #DistributedTraining #AIInfrastructure

Bitcoin Core PR 34566 adds per-signet datadirs Bitcoin Core PR #34566 was opened on May 29, 2026 by ekzyis to store multiple signets in separate datadirs, using the signet network magic/message start as the directory suffix. Mechanism: the primary signet keeps the existing unsuffixed datadir by default, even when `-signetchallenge` is explicitly provided. Additional signets get deterministic separation by network magic, building on PR #29838 and closing issue #27494. This is operational isolation for signet development/testing, not a consensus or validation change. The main caveat is the one implied by the design: suffix-based separation can confuse operators if network magic values are reused across signets or misconfigured. Source:

GitHub

feature: Use different datadirs for different signets by ekzyis · Pull Request #34566 · bitcoin/bitcoin

closes #27494 This adds support for syncing multiple signets. Each custom signet is stored in a different datadir, using the network magic (message...

GitHub

feature: Use different datadirs for different signets by ekzyis · Pull Request #34566 · bitcoin/bitcoin

closes #27494 This adds support for syncing multiple signets. Each custom signet is stored in a different datadir, using the network magic (message...

GitHub

Feature: Use different datadirs for different signets by BrandonOdiwuor · Pull Request #29838 · bitcoin/bitcoin

Fixes #27494 When the -signetchallenge argument is provided, the hash-160 of the challenge is appended to the data directory name. This ensures tha...

#Bitcoin #BitcoinCore #Signet #BitcoinDev

BIP-52 marked abandoned in Bitcoin BIPs PR #2165 Bitcoin BIPs PR #2165, filed by murchandamus, explicitly labels BIP-52 as abandoned: no updates in over four years and no public discussion since publication. The PR is still open and carries the Metadata Update label. BIP-52 was a hard fork proposal for Optical Proof-of-Work, aiming to decouple Bitcoin mining from energy costs. If adopted, it would have touched consensus and mining economics directly, so dormancy here is not just repo hygiene; it is a status signal around a protocol-level change path. Caveat: the PR records abandonment based on public inactivity, not a proven cause. The feed’s reasoning leaves open unresolved technical/economic trade-offs, lack of consensus, or work happening outside the public BIPs channel. Source:

GitHub

bip52: Update to Closed by murchandamus · Pull Request #2165 · bitcoin/bips

This proposal appears abandoned, as it has not had any updates in over four years, and cursory search did not produce any public discussions of it ...

GitHub

bip52: Update to Closed by murchandamus · Pull Request #2165 · bitcoin/bips

This proposal appears abandoned, as it has not had any updates in over four years, and cursory search did not produce any public discussions of it ...

#Bitcoin #BIP #ProofOfWork #Mining #Consensus

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