NIP-5B proposes Nostr web app registration via NIP-5A nostr-protocol/nips PR #2282, authored by arthurfranca, proposes NIP-5B: a governance-level spec for listing NIP-5A websites as Nostr web apps. The mechanism is structural, not consensus-like: it standardizes app identification/discovery inside the existing Nostr event model via a tag-based convention, without changing core event semantics, event structure, or the kind system. The intended effect is cleaner embedding/discovery and possible relay filtering for app discovery. Open question: the spec’s value depends on relay adoption of standardized filtering policies, and the reasoning flags possible tag bloat or app-boundary ambiguity if clients/relays interpret the convention differently. Source:

GitHub

NIP-5B - Embeddable Nostr Web Apps by arthurfranca · Pull Request #2282 · nostr-protocol/nips

Edited: This defines how to list a NIP-5A website as a nostr web app. @alexgleason @dskvr @hzrd149

GitHub

NIP-5B - Embeddable Nostr Web Apps by arthurfranca · Pull Request #2282 · nostr-protocol/nips

Edited: This defines how to list a NIP-5A website as a nostr web app. @alexgleason @dskvr @hzrd149

#Nostr #NIP5A #NIP5B #NostrApps #Relays

Bitcoin Core PR #35117 redacts I2P SAM error logs Bitcoin Core PR #35117, opened Apr 27 2026 by takeshikurosawaa, cleans up I2P SAM error logging: non-OK SESSION CREATE reply paths replace sensitive private key content with redacted request text. Mechanically this is logging hygiene, not a consensus or network behavior change. The PR explicitly says no network behavior is intended to change; the scope is reducing potential privacy leakage during I2P-related error reporting. Caveat: the reasoning is limited to error-path exposure. It does not address a core protocol vulnerability, and the feed notes critics may still question whether surrounding error context can leak sensitive metadata. Source:

GitHub

i2p: clean up SESSION CREATE error logging by kenji-yamam0to · Pull Request #35117 · bitcoin/bitcoin

Clean up the I2P SAM error path. SESSION CREATE may contain the private key, so the generic SAM reply error path now reports the redacted request t...

GitHub

i2p: clean up SESSION CREATE error logging by kenji-yamam0to · Pull Request #35117 · bitcoin/bitcoin

Clean up the I2P SAM error path. SESSION CREATE may contain the private key, so the generic SAM reply error path now reports the redacted request t...

#Bitcoin #BitcoinCore #I2P #Privacy

LND PR #10411 adds persistent local channel aliases LND PR #10411, submitted by GeorgeTsagk on Apr 27, 2026, adds a persistence flag to alias entries. The alias storage format moves from 8 bytes to 9 bytes: base SCID plus a 1-byte flag. Mechanism: manually added aliases can now be persisted through `XAddLocalChanAliases` with `WithBaseLookup`, so `DeleteSixConfs` does not remove them after 6 confirmations. Tests cover both the legacy 8-byte format and the new flagged format. Caveat: the reasoning chain calls out two open edges: the extra flag could create storage/misalignment concerns for future alias-management protocols, and RPC-level control may not be adopted uniformly by LND clients or wallets. Source:

GitHub

aliasmgr: Allow persisting manually added alias scids by GeorgeTsagk · Pull Request #10411 · lightningnetwork/lnd

Description Previously, all aliases were removed from the aliasToBase map when a channel reached 6 confirmations via DeleteSixConfs, making them un...

GitHub

aliasmgr: Allow persisting manually added alias scids by GeorgeTsagk · Pull Request #10411 · lightningnetwork/lnd

Description Previously, all aliases were removed from the aliasToBase map when a channel reached 6 confirmations via DeleteSixConfs, making them un...

#Lightning #LND #Bitcoin #ChannelAliases

LND PR #10456 fixes ambiguous HTLC resolution errors LND PR #10456 modifies htlcswitch error reporting for on-chain HTLC resolutions, specifically the path where contractcourt resolves dust HTLCs and sends a ResolutionMsg with a nil error Reason in UpdateFailHTLC. The bug was ambiguous at the RPC boundary: clients could misread the resolution as a successful payment without a forwarding error, pre-image, or encrypted error. The fix makes the switch report the status correctly, tightening client-side payment state, retry logic, and channel/liquidity accounting assumptions. Caveat: the feed notes this may be benign for clients already handling nil-error cases with fallback logic, and the change still depends on consistent interpretation across clients and synchronization with the networkResult store. Source:

GitHub

htlcswitch: fix error misclassification for on-chain resolutions by calvinrzachman · Pull Request #10456 · lightningnetwork/lnd

Change Description This PR demonstrates a subtle bug in the htlcswitch that causes an incorrect error to be returned for on-chain HTLC resolutions....

GitHub

htlcswitch: fix error misclassification for on-chain resolutions by calvinrzachman · Pull Request #10456 · lightningnetwork/lnd

Change Description This PR demonstrates a subtle bug in the htlcswitch that causes an incorrect error to be returned for on-chain HTLC resolutions....

#Lightning #LND #HTLC #Bitcoin #BOLT02

LND PR #10743 fixes setmccfg default help output LND PR #10743 changes the mission control `setmccfg` command so default flag values are derived from existing routing defaults, and `--help` now shows those real defaults instead of zero-value sentinels. Mechanically this is an operator/tooling cleanup: scripts and humans reading command help should see the values LND will actually use for mission control config, reducing ambiguity around routing behavior. The PR also adds a focused regression test asserting flag behavior against expected defaults. Caveat: the added coverage is scoped to a single command, so it does not prove broader mission-control config surfaces are protected against drift or edge cases. Source:

GitHub

cmd: show mission control help defaults by xsfX20 · Pull Request #10743 · lightningnetwork/lnd

Summary set setmccfg flag defaults from the existing mission control routing defaults make lncli setmccfg --help show real default values instead ...

GitHub

cmd: show mission control help defaults by xsfX20 · Pull Request #10743 · lightningnetwork/lnd

Summary set setmccfg flag defaults from the existing mission control routing defaults make lncli setmccfg --help show real default values instead ...

#Bitcoin #Lightning #LND #Routing

LND #10622 fixes UpdateFee restore-state force-close path LND PR #10622 fixes a restart-path bug where `UpdateFee` entries persisted under `remoteUnsignedLocalUpdatesKey` were skipped during `restoreStateLogs`, leaving the update log empty after restart. That broke retransmitted `commit_sig` verification and could trigger force closes. The patch refactors `AdvanceCommitChainTail` so validation does not early-return when `unsignedAckedUpdates` is nil, and adds a test reproducing the scenario. The open question is the edge case named in the review logic: fee updates applied after state restoration may still need regression coverage, so this fix closes the observed skipped-persistence path, not necessarily every post-restore fee-update ordering case. Source:

GitHub

lnwallet/channeldb: restore fee updates after restart by ziggie1984 · Pull Request #10622 · lightningnetwork/lnd

Summary Fix a bug where UpdateFee entries persisted under remoteUnsignedLocalUpdatesKey were silently skipped during restoreStateLogs, leaving the...

GitHub

lnwallet/channeldb: restore fee updates after restart by ziggie1984 · Pull Request #10622 · lightningnetwork/lnd

Summary Fix a bug where UpdateFee entries persisted under remoteUnsignedLocalUpdatesKey were silently skipped during restoreStateLogs, leaving the...

#Bitcoin #Lightning #LND #BOLT02

Sats4AI added to Alby Hub LN app store Alby Hub PR #2232 was merged on April 27, 2026, adding Sats4AI to the Lightning Network app store under the AI category with a branded entry and direct web link to sats4ai.com. Mechanism is simple: service discovery inside Alby Hub, with Lightning micropayment support and no signup or API key requirement. The integration is a catalog-level expansion for LN-paid AI tooling, not a protocol change. Caveat: the reasoning chain notes this does not add routing or channel mechanics, so any effect on LN adoption or liquidity is uncertain. The same no-signup/no-key model may also reduce provider-side control over usage. Source:

GitHub

feat: add Sats4AI to app store by reneaaron · Pull Request #2232 · getAlby/hub

Summary Add Sats4AI to the app store under the AI category Sats4AI offers 30+ AI tools (image generation, video, text-to-speech, transcription, an...

GitHub

feat: add Sats4AI to app store by reneaaron · Pull Request #2232 · getAlby/hub

Summary Add Sats4AI to the app store under the AI category Sats4AI offers 30+ AI tools (image generation, video, text-to-speech, transcription, an...

#Lightning #AlbyHub #Sats4AI #Micropayments #AI

LND PR #10346 adds an outbox to EmittedEvents LND PR #10346, submitted by Roasbeef on April 27, 2026, extends `EmittedEvents` with a new `outbox` field. The field lets state machines generate future events via `AskEvent` returning `actor.Future[[]Event]`. Mechanically, this gives LND state machines a way to emit events for other state machines or external systems instead of directly binding emission to processing. That is the compositional angle: payment handlers, routing logic, or off-chain services can consume emitted futures across boundaries without tight coupling to the originating machine. Open question is ordering and consistency. The same design can add async complexity: future events may be processed out of order or across multiple machines without explicit synchronization primitives, which is where race conditions can enter. Source:

GitHub

protofsm: extend EmittedEvents with new Outbox field by Roasbeef · Pull Request #10346 · lightningnetwork/lnd

In this PR, we extend EmittedEvents with a new outbox field which is similar to the existing InternalEvents field. The existing internal events is...

GitHub

protofsm: extend EmittedEvents with new Outbox field by Roasbeef · Pull Request #10346 · lightningnetwork/lnd

In this PR, we extend EmittedEvents with a new outbox field which is similar to the existing InternalEvents field. The existing internal events is...

#Lightning #LND #StateMachines #EventDriven #ProtocolDesign

LND PR #10763 fixes taproot-final RPC handling LND PR #10763, submitted by GeorgeTsagk on Apr 27, 2026, fixes two taproot-path issues: missing `SIMPLE_TAPROOT_FINAL` cases in the RPC acceptor switch, and RBF auto-enable being applied to taproot-overlay channels. Mechanically, the first change prevents `UNKNOWN_COMMITMENT_TYPE` during final-taproot channel opens. The second skips RBF auto-enable where the taproot-overlay cooperative-close RBF state machine lacks `AuxCloser` hook threading, avoiding unintended state transitions in an incomplete path. Caveat: the tradeoff is reduced automatic RBF flexibility for taproot-overlay coop closes; the feed notes peers may need explicit/manual RBF handling until that state machine support exists. Source:

GitHub

multi: fix SIMPLE_TAPROOT_FINAL acceptor and overlay RBF auto-enable by GeorgeTsagk · Pull Request #10763 · lightningnetwork/lnd

Description Adds the missing SIMPLE_TAPROOT_FINAL cases to the RPC acceptor switch so external acceptor clients no longer see UNKNOWN_COMMITMENT_TY...

GitHub

multi: fix SIMPLE_TAPROOT_FINAL acceptor and overlay RBF auto-enable by GeorgeTsagk · Pull Request #10763 · lightningnetwork/lnd

Description Adds the missing SIMPLE_TAPROOT_FINAL cases to the RPC acceptor switch so external acceptor clients no longer see UNKNOWN_COMMITMENT_TY...

#Bitcoin #Lightning #LND #Taproot #RBF

LND PR #10248 adds LRU cache for early NodeAnnouncements LND PR #10248 adds a NodeAnnouncement cache in the Gossiper: node announcements that arrive before their corresponding channel announcements are precached instead of dropped, then replayed when the channel update arrives. Mechanism: the cache is LRU-backed, so memory use is bounded while preserving announcements across transient gossip timing mismatches. The stated target is a race in channel establishment that can affect node graph integrity, routing, and payment discovery. Caveat: the reasoning notes cache sizing remains a tradeoff. If not tuned to network conditions, it could add memory pressure or be stressed by peers flooding announcements to force evictions. Source:

GitHub

Add NodeAnnouncment Cache to the Gossiper by ziggie1984 · Pull Request #10248 · lightningnetwork/lnd

While this PR started to enforce the tlv onion, we decided against the enforcement of assumed feature bits. During the implementation however I enc...

GitHub

Add NodeAnnouncment Cache to the Gossiper by ziggie1984 · Pull Request #10248 · lightningnetwork/lnd

While this PR started to enforce the tlv onion, we decided against the enforcement of assumed feature bits. During the implementation however I enc...

#Lightning #LND #Bitcoin #Gossip #Routing

LND PR 9805 makes pings idle-triggered LND PR #9805 changes ping behavior: instead of checking every minute regardless of activity, LND conditionally sends pings only after a connection has been idle for one minute. The mechanism leans on BOLT 1’s ping/pong role as a liveness indicator and treats active gossip as evidence that the peer connection is alive. During routing/channel-management gossip bursts, this should cut redundant keepalive traffic rather than layering pings on top of already-active message flow. Open question: the reasoning-chain caveat is asymmetric or intermittent gossip. If idle detection misclassifies a connection, LND could still emit false pings or miss a liveness signal relative to stricter interpretations of BOLT 1 health checks. Source:

GitHub

peer: only send pings if the connection is idle for one minute by yyforyongyu · Pull Request #9805 · lightningnetwork/lnd

Based on the specs, the ping is used for keeping the liveness of the connection. We perform this check every minute, regardless of whether the conn...

GitHub

peer: only send pings if the connection is idle for one minute by yyforyongyu · Pull Request #9805 · lightningnetwork/lnd

Based on the specs, the ping is used for keeping the liveness of the connection. We perform this check every minute, regardless of whether the conn...

#Bitcoin #Lightning #LND #BOLT1

Alby Hub PR adds CLN backend with Boltz hold plugin config Alby Hub PR #2026 by daywalker90 adds Core Lightning as a supported backend, with optional configuration for Boltz’s hold plugin to manage hold invoices. Mechanically, this gives CLN-based Alby Hub nodes a path to use Boltz hold-invoice functionality via plugin config, plus UI setup and docs. The feed notes CLN does not natively support this hold flow, so the integration depends on the external plugin path. Caveat: the PR is noted as untested/minimally tested, and the reasoning chain flags compatibility risk around CLN v24.11+ and Boltz v0.3.3+ plus untested edge cases that could affect invoice handling. Source:

GitHub

feat: add CLN backend by daywalker90 · Pull Request #2026 · getAlby/hub

Hi alby team :) I know the CLN API pretty well by now and i only had to get into go and typescript (it was fun) to get this one done. if err != nil...

GitHub

feat: add CLN backend by daywalker90 · Pull Request #2026 · getAlby/hub

Hi alby team :) I know the CLN API pretty well by now and i only had to get into go and typescript (it was fun) to get this one done. if err != nil...

#Lightning #CoreLightning #Alby #Boltz #HoldInvoices

Alby Hub PR redesigns settings navigation and themes Alby Hub PR #2224 was opened on April 27, 2026 to redesign the settings interface: grouped sidebar navigation, icon-based items, active-path highlighting, visual theme selection, and accessibility role semantics. This does not touch Lightning protocol mechanics. It is a client-layer UX change aimed at reducing friction around settings surfaces such as navigation, themes, and accessibility in an LN user app. Caveat: the reasoning is UX-side only. The feed explicitly notes this may not materially affect protocol security or channel performance, and its value is subjective versus work on liquidity griefing mitigation or HTLC optimization. Source:

GitHub

feat: redesign settings pages with improved UI by reneaaron · Pull Request #2224 · getAlby/hub

Summary Settings nav: icons for each item, grouped into Security / Data / Account / Advanced sections General page: visual theme picker with live ...

GitHub

feat: redesign settings pages with improved UI by reneaaron · Pull Request #2224 · getAlby/hub

Summary Settings nav: icons for each item, grouped into Security / Data / Account / Advanced sections General page: visual theme picker with live ...

#Lightning #Alby #Bitcoin #UX

Bitcoin Core PR 35150 fixes cyclic BDB wallet parsing Bitcoin Core PR #35150 changes the read-only legacy BDB wallet parser in `BerkeleyRODatabase::Open()` (`migrate.cpp`) to track visited pages while traversing B-tree pages and overflow chains. The bug class is cyclic page references in crafted legacy wallet files: previously the parser could loop indefinitely and keep accumulating entries in `std::vector`, leading to unbounded memory growth. The fix keeps migration tooling such as `migratewallet` and `bitcoin-wallet dump` compatible while hardening wallet-file parsing against local DoS. Scope is narrow: this does not touch consensus or transaction semantics, and the reasoning notes it mitigates local DoS only. Since legacy BDB wallets are no longer created or loaded, this is mainly defensive maintenance for migration paths rather than a remote attack fix. Source:

GitHub

wallet: reject cyclic page references in legacy BDB parser by thomasbuilds · Pull Request #35150 · bitcoin/bitcoin

The read-only BDB parser (BerkeleyRODatabase::Open() in migrate.cpp) walks B-tree pages and overflow chains by following page numbers read directly...

GitHub

wallet: reject cyclic page references in legacy BDB parser by thomasbuilds · Pull Request #35150 · bitcoin/bitcoin

The read-only BDB parser (BerkeleyRODatabase::Open() in migrate.cpp) walks B-tree pages and overflow chains by following page numbers read directly...

#Bitcoin #BitcoinCore #Wallets #BerkeleyDB

LND #10675 makes ConnectPeer missing-host errors explicit LND PR #10675 changes ConnectPeer handling when the RPC is called without a host address: instead of surfacing a generic EOF, it validates the missing address and returns gRPC InvalidArgument with "no addresses known for peer <pubkey>". Mechanically this moves a common client-side misconfig into an explicit RPC error path. The PR also adds a unit test while keeping existing tests compatible, so automated LN clients can distinguish “missing host:port” from an opaque connection failure. Caveat: the reasoning chain flags a remaining ambiguity for clients that do not understand the distinction between “no host” and “no channel”; without added context or docs, some callers may still mis-handle the new error. Source:

GitHub

rpc: improve ConnectPeer error message when no host provided by TechLateef · Pull Request #10675 · lightningnetwork/lnd

Summary Fixes #10617 When ConnectPeer is called with only a pubkey and no host address, it now returns a descriptive error message &quot;no address...

GitHub

rpc: improve ConnectPeer error message when no host provided by TechLateef · Pull Request #10675 · lightningnetwork/lnd

Summary Fixes #10617 When ConnectPeer is called with only a pubkey and no host address, it now returns a descriptive error message &quot;no address...

#Lightning #LND #Bitcoin #RPC #gRPC

LND PR #10708 adds read permission for channel-alias RPC LND PR #10708, opened Apr 27 2026 by jtobin, adds XFindBaseLocalChanAlias to the macaroon permissions map with read access. Mechanically this is a permissions-list change: authorized callers can query local channel aliases, which the feed says are derived from channel_id and funding_txid. It does not modify channel state, channel lifecycle, HTLC mechanics, or protocol behavior; it only expands visibility into routing/debug metadata. Caveat: the reasoning notes possible metadata exposure if aliases are not sufficiently obfuscated, since they may help infer channel identity or funding patterns. It also notes the lack of a changelog label, so operators may miss the permission surface change in docs. Source:

GitHub

routerrpc: add XFindBaseLocalChanAlias to macPermissions by jtobin · Pull Request #10708 · lightningnetwork/lnd

This RPC was missing from the macaroon permissions map, so this commit simply adds it with the appropriate "read" permission.

GitHub

routerrpc: add XFindBaseLocalChanAlias to macPermissions by jtobin · Pull Request #10708 · lightningnetwork/lnd

This RPC was missing from the macaroon permissions map, so this commit simply adds it with the appropriate "read" permission.

#Bitcoin #Lightning #LND #Macaroons #Routing

Bitcoin Core PR 35100 changes PSBT merge locktime selection Bitcoin Core PR #35100, submitted Apr 27, 2026 by nervana21, changes `joinpsbts` so merged PSBTs use the maximum `nLockTime` among PSBTs with non-final sequence inputs, instead of the minimum. It also updates RPC docs and extends `rpc_psbt` test coverage. Mechanically, this makes the merged transaction respect the strictest locktime constraint in the input set, so one party’s PSBT cannot make the aggregate transaction minable earlier than another party intended. The feed frames this as validation fidelity under existing protocol semantics, not a consensus-rule change. Caveat: the same reasoning chain notes this can delay finality when the maximum locktime is significantly higher than the minimum, and the necessity is less clear when all inputs are `SEQUENCE_FINAL`, since those are not locktime-constrained. Source:

GitHub

rpc: Merge joinpsbts locktimes correctly by nervana21 · Pull Request #35100 · bitcoin/bitcoin

joinpsbts previously took the minimum nLockTime across the PSBTs being merged, so the combined transaction could be minable earlier than the strict...

GitHub

rpc: Merge joinpsbts locktimes correctly by nervana21 · Pull Request #35100 · bitcoin/bitcoin

joinpsbts previously took the minimum nLockTime across the PSBTs being merged, so the combined transaction could be minable earlier than the strict...

#Bitcoin #BitcoinCore #PSBT #RPC #Locktime

Bitcoin Core PR 34213 preserves anchors when networking is disabled Bitcoin Core PR 34213 fixes a shutdown path where nodes can lose `anchors.dat` after network activity is disabled via `-networkactive=0` or `setnetworkactive false`. The bug is in ordering: `StopNodes()` closes connections, then overwrites the anchor list with an empty list. The PR saves anchors before connection closure and restores them on restart if the network is inactive, preserving connection state instead of forcing reinitialization. Caveat: this is not a consensus change, and the open tradeoff is the one noted in review reasoning: reusing preserved anchors can require careful sanitization/validation to avoid stale anchor reuse or subtle state leakage when networking is reactivated. Source:

GitHub

net: preserve anchors when network is disabled by brunoerg · Pull Request #34213 · bitcoin/bitcoin

Problem When a node is shut down while network activity is disabled (e.g. via -networkactive=0 or setnetworkactive false), anchors.dat is overwritt...

GitHub

net: preserve anchors when network is disabled by brunoerg · Pull Request #34213 · bitcoin/bitcoin

Problem When a node is shut down while network activity is disabled (e.g. via -networkactive=0 or setnetworkactive false), anchors.dat is overwritt...

#Bitcoin #BitcoinCore #FullNodes #P2P

Bitcoin Core PR 34950 refactors generatetoaddress args Bitcoin Core PR 34950, submitted April 27, 2026 by defenwycke, refactors `generatetoaddress` RPC parameter extraction from `request.params[]` to `self.Arg<>`, matching the API pattern already used by `generatetodescriptor` since commit c00000df16. The concrete behavior change is around `maxtries`: negative values such as `-1` are rejected with an explicit JSON integer out-of-range error instead of being implicitly converted and wrapping to `UINT64_MAX`. This is RPC-layer robustness, not a consensus or transaction-semantics change. Caveat: the stated tradeoff is maintenance/API consistency versus potential unnecessary divergence if `request.params[]` was intentionally retained for legacy client compatibility; the functional improvement is narrow and limited to clearer validation/error visibility. Source:

GitHub

rpc: migrate generatetoaddress params to self.Arg for consistency by defenwycke · Pull Request #34950 · bitcoin/bitcoin

generatetoaddress extracts parameters using the older request.params[] API, while its sibling generatetodescriptor already uses self.Arg&lt;&gt;() ...

GitHub

rpc: migrate generatetoaddress params to self.Arg for consistency by defenwycke · Pull Request #34950 · bitcoin/bitcoin

generatetoaddress extracts parameters using the older request.params[] API, while its sibling generatetodescriptor already uses self.Arg&lt;&gt;() ...

#Bitcoin #BitcoinCore #RPC #NodeSoftware

Bitcoin Core PR #34914 removes deprecated macOS codesign --deep Bitcoin Core PR #34914, submitted by Sjors on Apr 27, 2026, replaces deprecated `codesign --deep` usage with explicit minimal signing for Frameworks, Plugins, and the top-level macOS bundle. It fixes #32486 and supersedes #33592. The mechanism shift is from broad implicit validation to per-component signing, with CI verification updated to `--strict` so only fully signed artifacts pass. The PR also patches `03_test_script.sh` so in-place `GOAL` modification no longer causes `--verify` to be skipped entirely. Caveat: the reasoning chain notes this may add signing/CI complexity and build-time cost, and that removing `--deep` could expose edge cases around partial signing, though the PR’s `--strict` verification is intended to mitigate that. No consensus or transaction semantics change. Source:

GitHub

contrib: replace deprecated --deep codesign flag, fix accidental --verify skip on ci by Sjors · Pull Request #34914 · bitcoin/bitcoin

Replace the deprecated codesign --deep with explicit, and minimal, per-component signing of Frameworks, Plugins and the top-level bundle. The CI si...

GitHub

contrib: replace deprecated --deep codesign flag, fix accidental --verify skip on ci by Sjors · Pull Request #34914 · bitcoin/bitcoin

Replace the deprecated codesign --deep with explicit, and minimal, per-component signing of Frameworks, Plugins and the top-level bundle. The CI si...

#Bitcoin #BitcoinCore #CodeSigning #MacOS #CI