From 3740dac19725f910abac463149991d28e8c42295 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Fri, 12 Jun 2026 07:55:27 -0500 Subject: [PATCH 1/5] Newsletters: add 410 (2026-06-19) --- .../en/newsletters/2026-06-19-newsletter.md | 46 +++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 _posts/en/newsletters/2026-06-19-newsletter.md diff --git a/_posts/en/newsletters/2026-06-19-newsletter.md b/_posts/en/newsletters/2026-06-19-newsletter.md new file mode 100644 index 000000000..f951d2135 --- /dev/null +++ b/_posts/en/newsletters/2026-06-19-newsletter.md @@ -0,0 +1,46 @@ +--- +title: 'Bitcoin Optech Newsletter #410' +permalink: /en/newsletters/2026/06/19/ +name: 2026-06-19-newsletter +slug: 2026-06-19-newsletter +type: newsletter +layout: newsletter +lang: en +--- +FIXME:bitschmidty + +## News + +FIXME:bitschmidty + +## Changes to services and client software + +*In this monthly feature, we highlight interesting updates to Bitcoin +wallets and services.* + +FIXME:bitschmidty + +## Releases and release candidates + +_New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates._ + +FIXME:Gustavojfe + +## Notable code and documentation changes + +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo], and [BINANAs][binana repo]._ + +FIXME:Gustavojfe + +{% include snippets/recap-ad.md when="2026-06-23 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="" %} From e2ca046155a789a329a1d018f43425764c60013d Mon Sep 17 00:00:00 2001 From: TumaBitcoiner <119351965+TumaBitcoiner@users.noreply.github.com> Date: Thu, 18 Jun 2026 11:52:53 +0200 Subject: [PATCH 2/5] Added BIP125 singaling removal news item. --- .../en/newsletters/2026-06-19-newsletter.md | 28 ++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/_posts/en/newsletters/2026-06-19-newsletter.md b/_posts/en/newsletters/2026-06-19-newsletter.md index f951d2135..e9843a339 100644 --- a/_posts/en/newsletters/2026-06-19-newsletter.md +++ b/_posts/en/newsletters/2026-06-19-newsletter.md @@ -11,6 +11,28 @@ FIXME:bitschmidty ## News + +- **Removal of BIP 125 RBF signaling in wallet transactions**: Rkrux [posted][bip125 ml] + to the Bitcoin-Dev mailing list about the current effort to remove the [RBF][topic rbf] + signaling in transactions, as defined by [BIP125][]. That BIP specifies that a transaction + can opt-in to RBF, if the `nSequence` number is set to a value lower than + `0xffffffff - 1` (i.e. `nSequence = MAX-2`). Since the merging of `mempoolfullrbf`, + that signaling number have become redundant, and any transaction can be replaced using + that parameter. + + The author opened [Bitcoin Core #35405][], which aims to switch the default value for + the opt-in RBF to `false`, effectively setting `nSequence = MAX - 1`, and asked for + feedback from the wallet developers community to find a default input sequence number + which could get wide adoption. + + Feedback was provided by Murch and Electrum Wallet contributor SomberNight. + Murch pointed out that around 75% of transactions signal `nSequence = MAX - 2` + according to [Mainnet Observer][bip125 graph], and highlighted that the natural + convergence would be to follow this trend. SomberNight also explained that almost + all transactions from Electrum Wallet signal `nSequence = MAX - 2`, and that it + would be preferable not to change this behavior. Given the feedback, rkrux + decided to close the PR to take another approach. + FIXME:bitschmidty ## Changes to services and client software @@ -43,4 +65,8 @@ FIXME:Gustavojfe {% include snippets/recap-ad.md when="2026-06-23 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="" %} +{% include linkers/issues.md v=2 issues="35405" %} + +[bip125 ml]: https://groups.google.com/g/bitcoindev/c/C7zNIk8llew/m/YAdpwe33AgAJ +[bip125 comment]: https://github.com/bitcoin/bitcoin/pull/35405#issuecomment-4634469619 +[bip125 graph]: https://mainnet.observer/charts/transactions-signaling-explicit-rbf/ \ No newline at end of file From ea3b48438063859935f5d5364d5821a66482b413 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 18 Jun 2026 12:09:57 -0500 Subject: [PATCH 3/5] News410: fix build from news item --- _posts/en/newsletters/2026-06-19-newsletter.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/_posts/en/newsletters/2026-06-19-newsletter.md b/_posts/en/newsletters/2026-06-19-newsletter.md index e9843a339..35e25bfc4 100644 --- a/_posts/en/newsletters/2026-06-19-newsletter.md +++ b/_posts/en/newsletters/2026-06-19-newsletter.md @@ -11,15 +11,14 @@ FIXME:bitschmidty ## News - - **Removal of BIP 125 RBF signaling in wallet transactions**: Rkrux [posted][bip125 ml] to the Bitcoin-Dev mailing list about the current effort to remove the [RBF][topic rbf] - signaling in transactions, as defined by [BIP125][]. That BIP specifies that a transaction + signaling in transactions, as defined by [BIP125][]. That BIP specifies that a transaction can opt-in to RBF, if the `nSequence` number is set to a value lower than `0xffffffff - 1` (i.e. `nSequence = MAX-2`). Since the merging of `mempoolfullrbf`, - that signaling number have become redundant, and any transaction can be replaced using + that signaling number have become redundant, and any transaction can be replaced using that parameter. - + The author opened [Bitcoin Core #35405][], which aims to switch the default value for the opt-in RBF to `false`, effectively setting `nSequence = MAX - 1`, and asked for feedback from the wallet developers community to find a default input sequence number From 377dd1408f0a36a2cc9449b782a1555b15fa14c9 Mon Sep 17 00:00:00 2001 From: Mike Schmidt Date: Thu, 18 Jun 2026 13:16:18 -0500 Subject: [PATCH 4/5] News410: add client services --- .../en/newsletters/2026-06-19-newsletter.md | 43 ++++++++++++++++++- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/_posts/en/newsletters/2026-06-19-newsletter.md b/_posts/en/newsletters/2026-06-19-newsletter.md index 35e25bfc4..b79a99387 100644 --- a/_posts/en/newsletters/2026-06-19-newsletter.md +++ b/_posts/en/newsletters/2026-06-19-newsletter.md @@ -39,7 +39,38 @@ FIXME:bitschmidty *In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.* -FIXME:bitschmidty +- **Sparrow Wallet 2.5.0 adds silent payments receiving:** + Sparrow [2.5.0][sparrow 2.5.0] adds [silent payments][topic silent payments] + receiving wallets, including airgapped hardware wallet signers, building on + the send support added in 2.3.0 (see [Newsletter #377][news377 sparrow]). + +- **Bark live on Bitcoin mainnet:** + Second [announced][bark mainnet] that Bark, its [Ark][topic ark] protocol + implementation, is now running on Bitcoin mainnet, with a public Ark server + plus the Bark SDK and `barkd` daemon for developers. Bark previously launched + on signet (see [Newsletter #346][news346 bark]). + +- **Arké Ark wallet announced:** + [Arké][arke] is a native iOS wallet integrating the [Ark][topic ark] protocol + with onchain ([BDK][bdk repo]) and Lightning payments, displaying transactions + from all three layers in a single combined history. It currently runs on + signet with mainnet pending. + +- **Noah Ark wallet announced:** + [Noah][noah] is a cross-platform mobile wallet built on the [Ark][topic ark] + protocol with Lightning support and a trust-minimized design. It is currently + in beta. + +- **Alby Hub v1.23.0 released:** + Alby Hub [v1.23.0][alby hub v1.23.0] adds [just-in-time channels][topic jit + channels] that open automatically to accept incoming payments and an + experimental [Ark][topic ark] payment backend, among other improvements. + +- **JoinMarket-NG 0.32.0 released:** + JoinMarket-NG, a community-maintained fork of the [coinjoin][topic coinjoin] + implementation, [released][joinmarket 0.32.0] mempool support for the + [Neutrino][topic compact block filters] backend so takers can verify maker + broadcasts, among other fidelity bond and reliability improvements. ## Releases and release candidates @@ -68,4 +99,12 @@ FIXME:Gustavojfe [bip125 ml]: https://groups.google.com/g/bitcoindev/c/C7zNIk8llew/m/YAdpwe33AgAJ [bip125 comment]: https://github.com/bitcoin/bitcoin/pull/35405#issuecomment-4634469619 -[bip125 graph]: https://mainnet.observer/charts/transactions-signaling-explicit-rbf/ \ No newline at end of file +[bip125 graph]: https://mainnet.observer/charts/transactions-signaling-explicit-rbf/ +[sparrow 2.5.0]: https://github.com/sparrowwallet/sparrow/releases/tag/2.5.0 +[news377 sparrow]: /en/newsletters/2025/10/24/#sparrow-2-3-0-released +[bark mainnet]: https://blog.second.tech/bark-now-on-bitcoin-mainnet/ +[arke]: https://github.com/GBKS/arke +[noah]: https://github.com/smolcars/noah +[news346 bark]: /en/newsletters/2025/03/21/#bark-launches-on-signet +[alby hub v1.23.0]: https://github.com/getAlby/hub/releases/tag/v1.23.0 +[joinmarket 0.32.0]: https://github.com/joinmarket-ng/joinmarket-ng/releases/tag/0.32.0 From 18360806d907cbc85884665ae7957d0bbce6ebc9 Mon Sep 17 00:00:00 2001 From: Gustavo Flores Date: Thu, 18 Jun 2026 14:34:22 -0600 Subject: [PATCH 5/5] add merge summaries, no releases --- .../en/newsletters/2026-06-19-newsletter.md | 75 ++++++++++++++++--- 1 file changed, 65 insertions(+), 10 deletions(-) diff --git a/_posts/en/newsletters/2026-06-19-newsletter.md b/_posts/en/newsletters/2026-06-19-newsletter.md index b79a99387..dfaf540ab 100644 --- a/_posts/en/newsletters/2026-06-19-newsletter.md +++ b/_posts/en/newsletters/2026-06-19-newsletter.md @@ -72,14 +72,6 @@ wallets and services.* [Neutrino][topic compact block filters] backend so takers can verify maker broadcasts, among other fidelity bond and reliability improvements. -## Releases and release candidates - -_New releases and release candidates for popular Bitcoin infrastructure -projects. Please consider upgrading to new releases or helping to test -release candidates._ - -FIXME:Gustavojfe - ## Notable code and documentation changes _Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core @@ -91,11 +83,71 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], and [BINANAs][binana repo]._ -FIXME:Gustavojfe +- [Bitcoin Core #35221][] adds support for the [BIP434][] peer feature + negotiation framework (see Newsletters [#386][news386 bip434] and + [#390][news390 bip434]). It adds a `feature` P2P message that may be + exchanged between `version` and `verack` to advertise optional peer + features, and increases the P2P protocol version number to `70017`. Bitcoin + Core currently implements the negotiation mechanism, ignores unknown valid + feature IDs, and disconnects peers that send malformed `feature` messages, + send them after `verack`, or send them without negotiating a compatible + protocol version. It does not yet advertise any specific optional feature. + +- [Bitcoin Core #35254][] wipes additional key-derivation material from memory + after use. `CHMAC_SHA256` and `CHMAC_SHA512` now cleanse their temporary + `rkey` and inner-hash `temp` stack buffers, which may contain data derived + from [BIP32][topic bip32] chain codes or [BIP324][topic v2 p2p transport] + HKDF key material. The type of `ChainCode` has been changed from a `uint256` + typedef to a type with a `memory_cleanse()` destructor, wiping [BIP32][] + chain codes in extended keys and local variables when those objects are + destroyed. + +- [Bitcoin Core #35498][] fixes a race condition in the `FetchBlock` RPC path + when requesting a block from a peer that is disconnecting. `FetchBlock` could + obtain a valid peer reference before locking `cs_main`, but peer cleanup + could remove the peer's `CNodeState` before `BlockRequested()` recorded the + request, causing an assertion failure. The fix locks `cs_main` before looking + up the peer, ensuring that the peer's state cannot be removed while the block + request is registered. + +- [Eclair #3318][] fixes a [splicing][topic splicing] reconnection edge case + where Eclair could update its local state for a newly locked splice funding + transaction without sending `splice_locked`. This could happen after Eclair + sent `channel_reestablish` but before it received the peer's + `channel_reestablish`, leaving the peers out of sync about which funding + states require `commit_sig` messages and causing a force-close. Eclair now + handles funding lock events while reconnecting and sends `splice_locked` when + needed. + +- [LND #10789][] lays the groundwork for implementing [BOLT12 offers][topic + offers]: a daemon-independent `bolt12` codec package with an `Offer` message + type and supporting `lnwire` TLV infrastructure. The new codec validates + messages before encoding, keeps low-level decoding permissive for diagnostics + and fuzzing, and preserves unknown signed-range TLVs so `offer_id` remains + stable across decode and re-encode. + +- [Rust Bitcoin #6321][] hardens [segwit][topic segwit] witness decoding to + prevent attacker-controlled element counts from causing excessive memory + allocation. Previously, a few bytes of input could claim a large witness + stack and force an allocation of about 16 MB for witness index space. The new + decoder appends the received witness bytes to its content buffer and builds + the element index in `end()` after decoding the witness data, removing the + old batched allocation path. + +- [LDK #4685][] moves the nonce used for [BOLT12][topic offers] invoice + verification back into payer metadata of the invoice request or refund. The + nonce had previously been removed because it was also stored in the [blinded + reply-path][topic rv routing] `OffersContext`, but that made verifying an + invoice depend on state outside the invoice request or refund itself, which + is incompatible with upcoming [BOLT12][] [payment proofs][topic proof of + payment] (see [Newsletter #405][news405 proof]). Outbound offer and refund + reply-path contexts now only store the expected `PaymentId`, which is checked + against the payment ID recovered from the payer metadata of the received + invoice. {% include snippets/recap-ad.md when="2026-06-23 16:30" %} {% include references.md %} -{% include linkers/issues.md v=2 issues="35405" %} +{% include linkers/issues.md v=2 issues="35405,35221,35254,35498,3318,10789,6321,4685" %} [bip125 ml]: https://groups.google.com/g/bitcoindev/c/C7zNIk8llew/m/YAdpwe33AgAJ [bip125 comment]: https://github.com/bitcoin/bitcoin/pull/35405#issuecomment-4634469619 @@ -108,3 +160,6 @@ FIXME:Gustavojfe [news346 bark]: /en/newsletters/2025/03/21/#bark-launches-on-signet [alby hub v1.23.0]: https://github.com/getAlby/hub/releases/tag/v1.23.0 [joinmarket 0.32.0]: https://github.com/joinmarket-ng/joinmarket-ng/releases/tag/0.32.0 +[news386 bip434]: /en/newsletters/2026/01/02/#peer-feature-negotiation +[news390 bip434]: /en/newsletters/2026/01/30/#bips-2076 +[news405 proof]: /en/newsletters/2026/05/15/#core-lightning-9116