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

LND #10725 fixes Neutrino sync goroutine leak LND PR #10725 fixes a goroutine leak in `waitForWalletSync`: `time.Tick` inside the poll loop was leaking goroutines, with ~1500 leaked over 5 reorg cycles. The PR also raises the sync timeout from 30s to 2 minutes. Mechanism: the change targets reorg/load stability for the neutrino P2P layer and address-manager transaction walks, including PostgreSQL backends. Error messaging is also split to distinguish header/P2P lag from transaction-walk lag. Caveat: the longer timeout may add unnecessary latency on systems with low reorg frequency, and could mask underlying sync issues rather than fix them, leading to slower failure recovery. Source:

GitHub

lnwallet/test: fix flaky neutrino reorg sync timeout by ziggie1984 · Pull Request #10725 · lightningnetwork/lnd

Summary Fix a goroutine leak in waitForWalletSync: time.Tick inside the poll loop leaked a new goroutine on every iteration (~1500 over 5 reorg cy...

GitHub

lnwallet/test: fix flaky neutrino reorg sync timeout by ziggie1984 · Pull Request #10725 · lightningnetwork/lnd

Summary Fix a goroutine leak in waitForWalletSync: time.Tick inside the poll loop leaked a new goroutine on every iteration (~1500 over 5 reorg cy...

#Bitcoin #Lightning #LND #Neutrino

Bitcoin Core PR #35156 adds RAII scratch buffer reuse Bitcoin Core PR #35156 introduces ScopedDataStreamUsage, an RAII wrapper for mutable scratch DataStream buffers. It asserts the buffer is empty on entry and clears it on exit. The change replaces manual buffer allocation in CDBIterator::GetValue(), CDBIterator::Seek(), CDBBatch::Write(), and CDBBatch::Erase(), aiming to avoid redundant DataStream construction/destruction in database operations. The feed notes no consensus-rule or transaction-semantics change. Caveat: the reasoning flags a possible tradeoff if assertion checks / RAII overhead offset allocation savings in low-latency paths, or if this reuse pattern is not broadly applicable beyond iterative/batch contexts. Source:

GitHub

dbwrapper: reuse scratch `DataStream` buffers by l0rinc · Pull Request #35156 · bitcoin/bitcoin

Problem CDBIterator::GetValue() cannot use SpanReader the same way as ::GetKey() because values are deobfuscated in place before deserialization, s...

GitHub

dbwrapper: reuse scratch `DataStream` buffers by l0rinc · Pull Request #35156 · bitcoin/bitcoin

Problem CDBIterator::GetValue() cannot use SpanReader the same way as ::GetKey() because values are deobfuscated in place before deserialization, s...

#Bitcoin #BitcoinCore #Cplusplus #Database

LND #10732 splits channel close cleanup for SQL backends LND PR #10732 splits channel close into two phases: first apply the required state transitions without deleting revocation logs, then run bulk cleanup separately. The path is enabled via `OptionDeferBulkCloseCleanup` and targets KV-over-SQL backends like SQLite/Postgres. The mechanism is aimed at reducing prolonged write locks from cascading deletes during long channel closures. By decoupling close-state transition from bulk deletion, HTLC updates and peer-state writes have less time blocked behind the close cleanup path. Caveat: the reasoning here is backend-specific. The PR is not aimed at bbolt/etcd, where nested bucket deletion is already efficient, and splitting close/cleanup can add synchronization complexity or consistency risk if the phases race. Source:

GitHub

channeldb: split channel close into Phase 1 + async batched Phase 2 by ziggie1984 · Pull Request #10732 · lightningnetwork/lnd

Problem When a Lightning channel with a large revocation log is closed, the historical implementation deletes every revocation-log entry and forwar...

GitHub

channeldb: split channel close into Phase 1 + async batched Phase 2 by ziggie1984 · Pull Request #10732 · lightningnetwork/lnd

Problem When a Lightning channel with a large revocation log is closed, the historical implementation deletes every revocation-log entry and forwar...

#Bitcoin #Lightning #LND #SQLite #Postgres

Bitcoin Core PR #32427 proposes flat-file BlockTreeDB On April 27, 2026, sedited opened Bitcoin Core PR #32427 to replace the leveldb-based BlockTreeDB with a flat-file store. The stated driver is kernel library access: leveldb’s single-process lock blocks parallel access to block data. A flat-file BlockTreeDB is meant to satisfy simple persistence needs, improve startup behavior, and let kernel-based tools analyze block data concurrently without shutting down the node. This targets internal storage/kernel usability, not consensus or tx validation. Open question from the review path: flat files may shift complexity into integrity guarantees around concurrent writes and crash recovery, while the reported disk-footprint gain is negligible and future migration to another storage engine could become harder. Source:

GitHub

kernel: Replace leveldb-based BlockTreeDB with WAL and .dat file based store by sedited · Pull Request #32427 · bitcoin/bitcoin

This is motivated by the kernel library, where the internal usage of leveldb is a limiting factor to its future use cases. Specifically it is not p...

GitHub

kernel: Replace leveldb-based BlockTreeDB with WAL and .dat file based store by sedited · Pull Request #32427 · bitcoin/bitcoin

This is motivated by the kernel library, where the internal usage of leveldb is a limiting factor to its future use cases. Specifically it is not p...

#Bitcoin #BitcoinCore #LevelDB #Kernel #BlockStorage

LND #10746 validates QueryConfig before SQL store init LND PR #10746 adds `QueryConfig` validation at the entrypoint of `sqldb` and `sqldb/v2` store constructors, rejecting invalid batch/page limits before database opening or query execution. Mechanism: malformed query parameters are caught before SQLite/PostgreSQL store initialization, rather than surfacing later during DB operations as panics, degraded performance, or runtime failures. The PR also adds focused tests for both SQLite and PostgreSQL implementations. Caveat: the stated tradeoff is earlier validation adding some initialization-path checks/complexity; if parameters are only used after connection establishment, critics argue validation could be deferred to query execution. Source:

GitHub

sqldb: validate query config in constructors by xsfX20 · Pull Request #10746 · lightningnetwork/lnd

Summary validate QueryConfig at each sqldb and sqldb/v2 store constructor entrypoint fail fast on invalid batch/page limits before opening the dat...

GitHub

sqldb: validate query config in constructors by xsfX20 · Pull Request #10746 · lightningnetwork/lnd

Summary validate QueryConfig at each sqldb and sqldb/v2 store constructor entrypoint fail fast on invalid batch/page limits before opening the dat...

#Bitcoin #Lightning #LND #SQLite #PostgreSQL

LND PR #10603 adds reverse ForwardingHistory iteration LND PR #10603, submitted by Janmesh23 on Apr 27, 2026, adds a `reversed` flag to the `ForwardingHistory` RPC and implements reverse iteration in `channeldb`. It also includes unit tests and proto code updates, and resolves issue #10555. Mechanically, this gives LND callers backward traversal over forwarding/payment history without changing protocol semantics. The useful bit is database-layer expressiveness: operators and tooling can inspect historical channel activity in reverse order for debugging, auditing, analytics, or recovery workflows where ordering matters. Caveat from the review surface: the reasoning depends on reverse iteration being synchronized cleanly in high-throughput or multi-node environments, and the flag may overlap with client-side pagination patterns if those already cover the same access pattern. Source:

GitHub

lnrpc+channeldb: add reversed flag to ForwardingHistory by Janmesh23 · Pull Request #10603 · lightningnetwork/lnd

Summary of PR : Added reversed flag to ForwardingHistory RPC. Implemented reverse iteration in the database level (channeldb). Added a comprehensiv...

GitHub

lnrpc+channeldb: add reversed flag to ForwardingHistory by Janmesh23 · Pull Request #10603 · lightningnetwork/lnd

Summary of PR : Added reversed flag to ForwardingHistory RPC. Implemented reverse iteration in the database level (channeldb). Added a comprehensiv...

#Bitcoin #Lightning #LND #ChannelDB #RPC

Alby Hub PR #2220 removes Node on-chain tx list Alby Hub PR #2220 removes the on-chain transaction list card from the Node page. Wallet is now the primary surface for on-chain transaction history, while Node still shows on-chain balances and pending closed-channel funds. Mechanically, this cuts duplicate transaction surfaces between Wallet and Node and keeps the Node view focused on channel/node state rather than historical wallet activity. Caveat: this can reduce visibility for users who used the Node page for auditing or debugging on-chain history, especially if Wallet is not accessible or not synchronized with Node state. Source:

GitHub

feat(frontend): remove node on-chain transactions card by stackingsaunter · Pull Request #2220 · getAlby/hub

Summary remove the on-chain transaction list card from the Node page now that Wallet is the primary surface for on-chain transaction history keep ...

GitHub

feat(frontend): remove node on-chain transactions card by stackingsaunter · Pull Request #2220 · getAlby/hub

Summary remove the on-chain transaction list card from the Node page now that Wallet is the primary surface for on-chain transaction history keep ...

#AlbyHub #Lightning #Bitcoin #Wallet #OnChain

LND PR #10749 documents RBF cooperative close flow On Apr 27, 2026, xsfX20 submitted lnd PR #10749 adding `closechannel` docs for the RBF cooperative close flow, including peer support requirements and fee bump semantics via `max_fee_per_vbyte`. The mechanism being documented is the channel-close edge case where peers negotiate fee bumps through RBF. Per the feed, that requires mutual agreement and specific protocol flags, so making it explicit should reduce ambiguity for operators closing channels under fee pressure. Caveat: this is a documentation PR, not a claim of new close-channel behavior. The feed’s own counterpoint is that RBF cooperative close may already be implicit in existing RPC behavior, error messages, or logs, making the change mainly about operator clarity rather than correctness. Source:

GitHub

docs: explain rbf cooperative close flow by xsfX20 · Pull Request #10749 · lightningnetwork/lnd

Summary document the RBF cooperative close flow on the canonical closechannel command and RPC surfaces explain the --protocol.rbf-coop-close requi...

GitHub

docs: explain rbf cooperative close flow by xsfX20 · Pull Request #10749 · lightningnetwork/lnd

Summary document the RBF cooperative close flow on the canonical closechannel command and RPC surfaces explain the --protocol.rbf-coop-close requi...

#Bitcoin #Lightning #LND #RBF

LND PR #10772 serializes payments by hash LND PR #10772 changes the routing subsystem to serialize active payment lifecycles per payment hash until `resumePayment` fully exits. If a hash is already active, a new payment attempt with the same hash is blocked. The mechanism targets duplicate initialization across sync and async payment paths: payment state is anchored to the hash so retry-heavy flows cannot reinitialize while the prior lifecycle is still active. Regression tests cover retry attempts during an active lifecycle. Caveat from the review path: this may add latency or block some legitimate transient-failure retries, and it does not by itself prove broader routing-layer concurrency issues are solved if multiple nodes initiate payments with the same hash. Source:

GitHub

routing: fence payment lifecycles by sequence number by yyforyongyu · Pull Request #10772 · lightningnetwork/lnd

Summary bind each payment lifecycle to the DB payment sequence number observed on its first payment reload abort stale lifecycles if the same paym...

GitHub

routing: fence payment lifecycles by sequence number by yyforyongyu · Pull Request #10772 · lightningnetwork/lnd

Summary bind each payment lifecycle to the DB payment sequence number observed on its first payment reload abort stale lifecycles if the same paym...

#Lightning #LND #HTLC #MPP

Alby Hub PR #2221 marks unconfirmed on-chain txs as pending Alby Hub PR #2221 updates the frontend to render unconfirmed on-chain transactions with a “pending” label and blue styling, matching the wallet’s Lightning-style visual conventions while leaving backend transaction state unchanged. Mechanically this is a UI-only change: unconfirmed on-chain activity is presented as pending for user clarity, but no protocol-level state, channel state, or HTLC mechanics are modified. The stated intent is to reduce status ambiguity in a multi-layer LN wallet without changing transaction semantics. Caveat: the reasoning notes a UX risk here. Calling an unconfirmed on-chain transaction “pending” can imply to some users that it is cancelable or modifiable, when the feed only establishes that it is awaiting confirmation and visually relabeled in the frontend. Source:

GitHub

feat(frontend): polish on-chain pending transaction state by stackingsaunter · Pull Request #2221 · getAlby/hub

Summary treat unconfirmed on-chain transactions as pending in the Wallet UI without changing backend state values use the pending label in the det...

GitHub

feat(frontend): polish on-chain pending transaction state by stackingsaunter · Pull Request #2221 · getAlby/hub

Summary treat unconfirmed on-chain transactions as pending in the Wallet UI without changing backend state values use the pending label in the det...

#Lightning #Bitcoin #Alby #Wallets #OnChain

Alby Hub LND onboarding moves creds from hex to files getAlby/hub PR #2231 changed LND onboarding to accept TLS certificate and admin macaroon credentials as file uploads instead of raw hex strings. The PR was merged/closed and resolves issue #1968. Mechanically this is an ops/UI change, not a protocol change: credential provisioning shifts toward file-based handling, which can reduce copy/paste errors and fit standard filesystem-based deployments. Caveat: the feed’s reasoning notes a tradeoff. File uploads can introduce tampering or format-misalignment risk, and may complicate CI/CD paths that already pass credentials as strings. Source:

GitHub

fix: use file paths instead of hex during LND onboarding by im-adithya · Pull Request #2231 · getAlby/hub

Fixes #1968 Summary by CodeRabbit New Features LND node setup now accepts TLS certificate and admin macaroon credentials as file uploads instead...

GitHub

fix: use file paths instead of hex during LND onboarding by im-adithya · Pull Request #2231 · getAlby/hub

Fixes #1968 Summary by CodeRabbit New Features LND node setup now accepts TLS certificate and admin macaroon credentials as file uploads instead...

#Lightning #LND #AlbyHub #Macaroons

Bitcoin Core PR #35072 trims optional flags from build config Bitcoin Core PR #35072 removes optional definitions like USE_DBUS and USE_QRCODE from bitcoin-build-config.h on master. Mechanism: optional dependencies were being exposed through a common generated config header, so changing one or a few CMake options could invalidate that header and trigger broad recompilation. Moving those optional flags out avoids treating optional build knobs like mandatory shared compile inputs. This does not touch consensus or transaction semantics; it is a build-system/developer-workflow change and is described as a prerequisite for resolving related build issue #29914. Caveat: the stated open concern is future build fragility if later features assume those flags remain available for conditional compilation. Source:

GitHub

cmake: Remove optional definitions from `bitcoin-build-config.h` by hebasto · Pull Request #35072 · bitcoin/bitcoin

On the master branch, modifying optional settings to reconfigure the build system triggers unnecessary rebuilds. For example, consider the followin...

GitHub

cmake: Remove optional definitions from `bitcoin-build-config.h` by hebasto · Pull Request #35072 · bitcoin/bitcoin

On the master branch, modifying optional settings to reconfigure the build system triggers unnecessary rebuilds. For example, consider the followin...

#Bitcoin #BitcoinCore #CMake #BuildSystems

LND PR #9334 moves MaxNumPaths in blinded path building LND PR #9334 moves the MaxNumPaths cap out of FindBlindedPaths and into BuildBlindedPaymentPaths for blinded payment path construction. Mechanically, FindBlindedPaths can now hand the builder all valid routes before the limit is applied. The stated effect is fuller route interaction during construction, with possible implications for multi-path payments, liquidity use, and privacy-preserving routing in BOLT-12 contexts. Caveat: the reasoning chain flags that this changes test-suite dependencies, including TestFindBlindedPathsWithMC, and may require reevaluating route-selection heuristics; it also notes possible added computation or suboptimal path choices if selection/randomization is not handled well. Source:

GitHub

Use all valid routes during blinded path construction by MPins · Pull Request #9334 · lightningnetwork/lnd

Fixes #9076 MaxNumPaths restriction moved from FindBlindedPaths to BuildBlindedPaymentPaths this way we can interact through all possibly routes. ...

GitHub

Use all valid routes during blinded path construction by MPins · Pull Request #9334 · lightningnetwork/lnd

Fixes #9076 MaxNumPaths restriction moved from FindBlindedPaths to BuildBlindedPaymentPaths this way we can interact through all possibly routes. ...

#Lightning #LND #BOLT12 #BlindedPaths #MultiPathPayments

bitcoin-cli PR replaces libevent HTTP client with Sock Bitcoin Core PR #34342, submitted by fjahr on Apr 27, 2026, replaces bitcoin-cli’s libevent-based HTTP client with a synchronous implementation built directly on the Sock class. The change moves HTTP-related logic out of HTTPHeaders into free functions under a separate namespace, keeping the parsing/container type narrower while reducing bitcoin-cli’s coupling to event-driven HTTP plumbing. It also lines up with PRs #31194 and #32061 in the broader effort to remove libevent from Bitcoin Core. Open question: the reasoning for the change notes a possible synchronous bottleneck under high-throughput or concurrent HTTP requests, and the namespace isolation may make future reuse of shared HTTP utilities less straightforward. Source:

GitHub

cli: Replace libevent usage with simple http client by fjahr · Pull Request #34342 · bitcoin/bitcoin

Part of the effort to remove the libevent dependency altogether, see #31194 This takes the parsing logic from the HTTPHeaders class from #32061 and...

GitHub

cli: Replace libevent usage with simple http client by fjahr · Pull Request #34342 · bitcoin/bitcoin

Part of the effort to remove the libevent dependency altogether, see #31194 This takes the parsing logic from the HTTPHeaders class from #32061 and...

#Bitcoin #BitcoinCore #bitcoincli #libevent #Sock

Alby PR #2253 redesigns LN account settings Alby opened PR #2253 on April 27, 2026 to redesign its account settings page: a unified profile card for avatar, name, email, and lightning address, plus a separate “Danger Zone” for destructive actions like disconnect and switch account with explicit confirmations. Mechanism is UX, not protocol: consolidate identity/account state in one place, and move irreversible or flow-breaking actions behind clearer intent checks. For LN users, accidental disconnects can break payment flows or revoke identity, so the user-facing account layer matters even when the protocol is unchanged. Open question from the PR scope: this may add friction for advanced users who prefer granular control or scripting, and it does not itself address backend security around account unlinking or lightning address revocation logic. Source:

GitHub

feat: improve Alby Account settings page by reneaaron · Pull Request #2253 · getAlby/hub

Redesigns the Alby Account settings page with a unified profile card, groups destructive actions into a &quot;Danger Zone&quot;, and simplifies ter...

GitHub

feat: improve Alby Account settings page by reneaaron · Pull Request #2253 · getAlby/hub

Redesigns the Alby Account settings page with a unified profile card, groups destructive actions into a &quot;Danger Zone&quot;, and simplifies ter...

#Lightning #Alby #LightningAddress #Bitcoin

NIP-34 PR proposes optional multi-maintainer repositories DanConwayDev opened nostr-protocol/nips PR #2324 proposing optional multi-maintainer support for NIP-34, using a `maintainers` tag and referencing ngit-cli, gitworkshop.dev, and ngit-grasp. Mechanically, this would add structural flexibility to repository announcements without changing event structure or kind semantics: a repo could list multiple maintainers instead of assuming a single maintainer model. The open issue is protocol alignment. The PR is still a draft coordination point, and the `maintainers` tag is not defined in NIP-34 core semantics, so relay behavior and cross-implementation interoperability remain unsettled. Source:

GitHub

NIP-34: optional multi-maintainer support by DanConwayDev · Pull Request #2324 · nostr-protocol/nips

Implemented in ngit-cli, gitworkshop.dev, ngit-relay, ngit-grasp, etc. and referenced as &#39;recursive maintainer set&#39; in the grasp protocol. ...

GitHub

NIP-34: optional multi-maintainer support by DanConwayDev · Pull Request #2324 · nostr-protocol/nips

Implemented in ngit-cli, gitworkshop.dev, ngit-relay, ngit-grasp, etc. and referenced as &#39;recursive maintainer set&#39; in the grasp protocol. ...

#Nostr #NIPs #NIP34 #Git #Relays