Repository: bitcoinops/bitcoinops.github.io
Pull request #2313: Newsletters: add 354 (2025-05-16)
Author: login: harding
Created: 2025-05-14T08:54:46Z | Merged: 2025-05-16T10:45:57Z

- [ ] Finish Changing Consensus section @harding
- [ ] Lede, releases/RCs, topic entries @harding
- [ ] Notable commits @Gustavojfe 


Diff:
diff --git a/_includes/references.md b/_includes/references.md
index cb73815d8a..27ddb66b84 100644
--- a/_includes/references.md
+++ b/_includes/references.md
@@ -94,7 +94,7 @@ for details --> {% endcomment %}
 [BIP49]: https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki
 [BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
 [BIP52]: https://github.com/bitcoin/bips/blob/master/bip-0052.mediawiki
-[BIP54]: https://github.com/bitcoin/bips/blob/master/bip-0052.mediawiki
+[BIP54]: https://github.com/bitcoin/bips/blob/master/bip-0054.md
 [BIP61]: https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki
 [BIP62]: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
 [BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
@@ -150,8 +150,10 @@ for details --> {% endcomment %}
 [BIP157]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
 [BIP158]: https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki
 [BIP159]: https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki
+[BIP172]: https://github.com/bitcoin/bips/blob/master/bip-0172.mediawiki
 [BIP173]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
 [BIP174]: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
+[BIP177]: https://github.com/bitcoin/bips/blob/master/bip-0177.mediawiki
 [BIP179]: https://github.com/bitcoin/bips/blob/master/bip-0179.mediawiki
 [BIP199]: https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki
 [BIP300]: https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki
diff --git a/_posts/en/newsletters/2025-05-16-newsletter.md b/_posts/en/newsletters/2025-05-16-newsletter.md
new file mode 100644
index 0000000000..3704436e5a
--- /dev/null
+++ b/_posts/en/newsletters/2025-05-16-newsletter.md
@@ -0,0 +1,164 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter describes a fixed vulnerability affecting old
+versions of Bitcoin Core.  Also included are our regular sections
+summarizing recent discussions about changing Bitcoin's consensus rules,
+announcing new releases and release candidates, and describing notable
+changes to popular Bitcoin infrastructure software.
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, resulting in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was completely fixed by using 64-bit identifiers,
+  starting with last month's release of Bitcoin Core 29.0.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64-bit numeric values.  This follows his previous research
+  (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  earlier discussion, the new proposal uses numbers in the same
+  compactSize data format currently used in Bitcoin.  Additional related
+  [discussion][stewart inout] occurred on two [threads][stewart
+  overflow] on Delving Bitcoin.
+
+- **Proposed opcodes for enabling recursive covenants through quines:**
+  Bram Cohen [posted][cohen quine] to Delving Bitcoin to suggest a set
+  of simple opcodes that would enable the creation of recursive
+  [covenants][topic covenants] through self-reproducing scripts
+  ([quines][]).  Cohen describes how the opcodes could be used to create a
+  simple [vault][topic vaults] and mentions a more advanced system that
+  he's been working on.
+
+- **Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`:**
+  Robin Linus [posted][linus bitvm-sf] to Delving Bitcoin about several
+  of the improvements to [BitVM][topic acc] that would become possible if the
+  proposed [OP_CTV][topic op_checktemplateverify] and [OP_CSFS][topic
+  op_checksigfromstack] opcodes were added to Bitcoin in a soft fork.
+  The benefits he describes includes increasing the number of operators
+  without downsides, "reducing transaction sizes by approximately 10x"
+  (which reduces worst-case costs), and allowing non-interactive peg-ins
+  for certain contracts.
+
+## 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._
+
+- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN
+  node.  One of the major improvements that could probably use testing
+  is the new RBF-based fee bumping for cooperative closes.
+
+## 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]._
+
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the
+  [consensus cleanup][topic consensus cleanup] soft fork proposed in [BIP54][]. Timelocking coinbase
+  transactions solves the [duplicate transaction][topic duplicate transactions]
+  vulnerability, and would allow the costly [BIP30][] checks to be lifted.
+
+- [Bitcoin Core #28710][] removes the remaining legacy wallet code,
+  documentation, and related tests. This includes the legacy-only RPCs, such as
+  `importmulti`, `sethdseed`, `addmultisigaddress`, `importaddress`,
+  `importpubkey`, `dumpwallet`, `importwallet`, and `newkeypool`. As the final
+  step for legacy wallet removal, the BerkeleyDB dependency and related
+  functions are also removed. However, the bare minimum of legacy code and an
+  independent BDB parser (see Newsletter [#305][news305 bdb]) are retained in
+  order to perform wallet migration to [descriptor][topic descriptors] wallets.
+
+- [Core Lightning #8272][] disables the DNS seed lookup peer discovery fallback
+  from the connection daemon `connectd` to resolve call block issues caused by
+  offline DNS seeds.
+
+- [LND #8330][] adds a small constant (1/c) to the pathfinding bimodal
+  probability model to address numerical instability. In edge cases where the
+  calculation would otherwise fail due to rounding errors and produce a zero
+  probability, this regularization provides a fallback by causing the model to
+  revert to a uniform distribution. This resolves normalization bugs that occur
+  in scenarios involving very large channels or channels that don't fit a
+  bimodal distribution. Additionally, the model now skips unnecessary
+  probability calculations and automatically corrects outdated channel liquidity
+  observations and contradictory historical information.
+
+- [Rust Bitcoin #4458][] replaces the `MtpAndHeight` struct with an explicit
+  pair of the newly added `BlockMtp` and the already existing `BlockHeight`,
+  enabling better modeling of both block height and Median Time Past (MTP)
+  values in relative [timelocks][topic timelocks]. Unlike
+  `locktime::absolute::MedianTimePast`, which is constrained to values above 500 million
+  (roughly after 1985), `BlockMtp` can represent any 32-bit timestamp. This
+  makes it suitable for theoretical edge cases, such as chains with unusual
+  timestamps. This update also introduces `BlockMtpInterval`, and renames
+  `BlockInterval` to `BlockHeightInterval`.
+
+- [BIPs #1848][] updates the status of [BIP345][] to `Withdrawn`, as the author
+  [believes][obeirne vaultwithdraw] its proposed `OP_VAULT` opcode has been superseded by
+  [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), a more general [vault][topic vaults] design
+  and a new type of [covenant][topic covenants].
+
+- [BIPs #1841][] merges [BIP172][], which proposes formally defining Bitcoin’s
+  indivisible base unit as a “satoshi,” reflecting current widespread usage and
+  helping standardize terminology across applications and documentation.
+
+- [BIPs #1821][] merges [BIP177][], which proposes redefining “bitcoin” to
+  represent the smallest indivisible unit (commonly referred to as 1 satoshi),
+  rather than 100,000,000 units. The proposal argues that aligning terminology
+  with the actual base unit would reduce confusion caused by arbitrary decimal
+  conventions.
+
+{% include snippets/recap-ad.md when="2025-05-20 16:30" %}
+{% include references.md %}
+{% include linkers/issues.md v=2 issues="32155,28710,8272,8330,4458,1848,1841,1821" %}
+[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4
+[news314 excess addr]: /en/newsletters/2024/08/02/#remote-crash-by-sending-excessive-addr-messages
+[stewart bippost]: https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE
+[64bit bip]: https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki
+[news285 64bit]: /en/newsletters/2024/01/17/#proposal-for-64-bit-arithmetic-soft-fork
+[news290 64bit]: /en/newsletters/2024/02/21/#continued-discussion-about-64-bit-arithmetic-and-op-inout-amount-opcode
+[news306 64bit]: /en/newsletters/2024/06/07/#updates-to-proposed-soft-fork-for-64-bit-arithmetic
+[stewart inout]: https://delvingbitcoin.org/t/op-inout-amount/549/4
+[stewart overflow]: https://delvingbitcoin.org/t/overflow-handling-in-script/1549
+[poinsot addrvuln]: https://mailing-list.bitcoindevs.xyz/bitcoindev/EYvwAFPNEfsQ8cVwiK-8v6ovJU43Vy-ylARiDQ_1XBXAgg_ZqWIpB6m51fAIRtI-rfTmMGvGLrOe5Utl5y9uaHySELpya2ojC7yGsXnP90s=@protonmail.com/
+[cohen quine]: https://delvingbitcoin.org/t/a-simple-approach-to-allowing-recursive-covenants-by-enabling-quines/1655/
+[linus bitvm-sf]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591/
+[quines]: https://en.wikipedia.org/wiki/Quine_(computing)
+[news305 bdb]: /en/newsletters/2024/05/31/#bitcoin-core-26606
+[obeirne vaultwithdraw]: https://delvingbitcoin.org/t/withdrawing-op-vault-bip-345/1670/
diff --git a/_topics/en/acc.md b/_topics/en/acc.md
index 48872d8af4..4f2cc3c37d 100644
--- a/_topics/en/acc.md
+++ b/_topics/en/acc.md
@@ -61,6 +61,9 @@ optech_mentions:
   - title: "Summary and criticism of CTV + CSFS benefits for accountable computing contracts"
     url: /en/newsletters/2025/04/04/#accountable-computing-contracts
 
+  - title: "Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`"
+    url: /en/newsletters/2025/05/16/#description-of-benefits-to-bitvm-from-op-ctv-and-op-csfs
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: "Merklize All The Things (MATT)"
diff --git a/_topics/en/consensus-cleanup-soft-fork.md b/_topics/en/consensus-cleanup-soft-fork.md
index 09c1858da2..8f87542862 100644
--- a/_topics/en/consensus-cleanup-soft-fork.md
+++ b/_topics/en/consensus-cleanup-soft-fork.md
@@ -65,6 +65,9 @@ optech_mentions:
   - title: "BIPs #1800 merges BIP54, which specifies the consensus cleanup soft fork proposal"
     url: /en/newsletters/2025/05/09/#bips-1800
 
+  - title: "Bitcoin Core #32155 updates the internal miner to comply with consensus cleanup requirements"
+    url: /en/newsletters/2025/05/16/#bitcoin-core-32155
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
  - title: Soft fork activation
diff --git a/_topics/en/covenants.md b/_topics/en/covenants.md
index 59b7a3b6da..293c7e899c 100644
--- a/_topics/en/covenants.md
+++ b/_topics/en/covenants.md
@@ -124,6 +124,9 @@ optech_mentions:
   - title: "Request for a covenant to fairly distribute rewards in the Braidpool decentralized mining pool"
     url: /en/newsletters/2025/02/07/#request-for-a-covenant-design-supporting-braidpool
 
+  - title: "Suggestion for opcodes to enable recursive covenants through quines"
+    url: /en/newsletters/2025/05/16/#proposed-opcodes-for-enabling-recursive-covenants-through-quines
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: An early description of covenants in Bitcoin
diff --git a/_topics/en/matt.md b/_topics/en/matt.md
index e7ddff5b0b..d1d0bb0217 100644
--- a/_topics/en/matt.md
+++ b/_topics/en/matt.md
@@ -41,6 +41,9 @@ optech_mentions:
   - title: "Draft CCV BIP and details about amount semantic"
     url: /en/newsletters/2025/04/04/#op-checkcontractverify-semantics
 
+  - title: "OP_VAULT proposal withdrawn in favor of OP_CCV"
+    url: /en/newsletters/2025/05/16/#bips-1848
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: Covenants
diff --git a/_topics/en/op_checksigfromstack.md b/_topics/en/op_checksigfromstack.md
index 07b1d0d05c..4f0196ab8d 100644
--- a/_topics/en/op_checksigfromstack.md
+++ b/_topics/en/op_checksigfromstack.md
@@ -79,6 +79,9 @@ optech_mentions:
   - title: "Summary and criticism of CTV + CSFS benefits for Ark"
     url: /en/newsletters/2025/04/04/#ark
 
+  - title: "Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`"
+    url: /en/newsletters/2025/05/16/#description-of-benefits-to-bitvm-from-op-ctv-and-op-csfs
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: Covenants in Elements Alpha
diff --git a/_topics/en/op_checktemplateverify.md b/_topics/en/op_checktemplateverify.md
index 01a3f8e52e..aa91c28d59 100644
--- a/_topics/en/op_checktemplateverify.md
+++ b/_topics/en/op_checktemplateverify.md
@@ -160,6 +160,9 @@ optech_mentions:
   - title: "Details about how Ark could make use of CTV if activated"
     url: /en/newsletters/2025/04/04/#benefit-of-ctv-to-ark-users
 
+  - title: "Description of benefits to BitVM from `OP_CTV` and `OP_CSFS`"
+    url: /en/newsletters/2025/05/16/#description-of-benefits-to-bitvm-from-op-ctv-and-op-csfs
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: Covenants


Reviews:
user: login: LarryRuane
body: Minor suggestions; I'll check back tomorrow.
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-14T16:21:54Z
user: login: bitschmidty
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T14:33:48Z
user: login: LarryRuane
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-15T14:34:30Z
user: login: Gustavojfe
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T17:56:56Z
user: login: jirijakes
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T23:50:28Z
user: login: jirijakes
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-16T00:40:55Z
user: login: harding
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-16T02:30:43Z
user: login: harding
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-16T02:34:58Z
user: login: harding
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-16T02:37:51Z
user: login: jirijakes
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-16T03:24:01Z
user: login: jirijakes
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-16T03:38:29Z
user: login: azuchi
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-16T05:37:14Z
user: login: bitschmidty
body: ACK lede, topic, and news item additions.

Looks great, thank you @harding @Gustavojfe @azuchi @jirijakes @LarryRuane !
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-16T10:35:04Z

Review comments:
diff_hunk: @@ -0,0 +1,107 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: LarryRuane
body: ```suggestion
  overflow, resulting in a node crash.  This was partly
```
created_at: 2025-05-14T16:12:24Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,107 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: LarryRuane
body: ```suggestion
  operate on 64 numeric values.  This follows his previous research
  (see Newsletters [#285][news285 64bit], [#290][news290
```
created_at: 2025-05-14T16:14:38Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,107 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  previous discussion, the new proposal uses numbers in the same
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: LarryRuane
body: ```suggestion
  earlier discussion, the new proposal uses numbers in the same
```
created_at: 2025-05-14T16:15:32Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,150 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  previous discussion, the new proposal uses numbers in the same
+  compactSize data format currently used in Bitcoin.  Additional related
+  [discussion][stewart inout] occurred on two [threads][stewart
+  overflow] on Delving Bitcoin.
+
+<!-- FIXME:harding: ran out of time, will work on some of these topics
+
+- Bram Cohen quines
+- CTV+CSFS BitVM bridges
+- General computation with OP_CAT
+- Wager on OP_CAT activation
+- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
+- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
+- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
+- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
+
+-->
+
+## 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._
+
+- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN
+  node.  One of the major improvements that could probably use testing
+  is the new RBF-based fee bumping for cooperative closes.
+
+## 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]._
+
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the proposed [BIP54][]
+  [consensus cleanup]​​[topic consensus cleanup] soft fork. Timelocking coinbase
+  transactions solves the [duplicate transaction][topic duplicate transactions]
+  vulnerability, and would allow the costly [BIP30][] checks to be lifted.
+
+- [Bitcoin Core #28710][] removes the remaining legacy wallet code,
+  documentation, and related tests. This includes the legacy-only RPCs, such as
+  `importmulti`, `sethdseed`, `addmultisigaddress`, `importaddress`,
+  `importpubkey`, `dumpwallet`, `importwallet`, and `newkeypool`. As the final
+  step for legacy wallet removal, the BerkeleyDB dependency and related
+  functions are also removed. However, the bare minimum of legacy code and an
+  independent BDB parser (see Newsletter [#305][news305 bdb]) are retained in
+  order to perform wallet migration to [descriptor][topic descriptors] wallets.
+
+- [Core Lightning #8272][] disables the DNS seed lookup peer discovery fallback
+  from the connection daemon `connectd` to resolve call block issues caused by
+  offline DNS seeds.
+
+- [LND #8330][] adds a small constant (1/c) to the pathfinding bimodal
+  probability model to address numerical instability. In edge cases where the
+  calculation would otherwise fail due to rounding errors and produce a zero
+  probability, this regularization provides a fallback by causing the model to
+  revert to a uniform distribution. This resolves normalization bugs that occur
+  in scenarios involving very large channels or channels that don't fit a
+  bimodal distribution. Additionally, the model now skips unnecessary
+  probability calculations and automatically corrects outdated mission control
+  data and contradictory historical information.
+
+- [Rust Bitcoin #4458][] replaces the `MtpAndHeight` struct with an explicit
+  pair of the newly added `BlockMtp` and the already existing `BlockHeight`,
+  enabling better modeling of both block height and Median Time Past (MTP)
+  values in relative [timelocks][topic timelocks]. Unlike
+  `locktime::absolute::Mtp`, which is constrained to values above 500 million
+  (roughly after 1985), `BlockMtp` can represent any 32-bit timestamp. This
+  makes it suitable for theoretical edge cases, such as chains with unusual
+  timestamps. This update also introduces `BlockMtpInterval`, and renames
+  `BlockInterval` to `BlockHeightInterval`.
+
+- [BIPs #1848][] updates the status of [BIP345][] to `Withdrawn`, as the author
+  believes its proposed `OP_VAULT` opcode has been superseded by
+  [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), a more general vault design
+  and a new type of [covenant][topic covenants].
+
+- [BIPs #1841][] merges [BIP172][], which proposes formally defining Bitcoin’s
+  indivisible base unit as a “satoshi,” reflecting current widespread usage and
+  helping standardize terminology across applications and documentation.
+
+- [BIPs #1821][] merges [BIP177][], which proposes redefining “bitcoin” to
+  represent the smallest indivisible unit (commonly referred as 1 satoshi),
+  rather than 100,000,000 units. The proposal argues that aligning terminology
+  with the actual base unit would reduce confusion caused by arbitrary decimal
+  conventions.
+
+{% include snippets/recap-ad.md when="2025-05-20 16:30" %}
+{% include references.md %}
+{% include linkers/issues.md v=2 issues="32155,28710,8272,8330,4458,1848,1841,1821" %}
+[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4
+[news314 excess addr]: /en/newsletters/2024/08/02/#remote-crash-by-sending-excessive-addr-messages
+[stewart bippost]: https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE
+[64bit bip]: https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki
+[news285 64bit]: /en/newsletters/2024/01/17/#proposal-for-64-bit-arithmetic-soft-fork
+[news290 64bit]: /en/newsletters/2024/02/21/#continued-discussion-about-64-bit-arithmetic-and-op-inout-amount-opcode
+[news306 64bit]: /en/newsletters/2024/06/07/#updates-to-proposed-soft-fork-for-64-bit-arithmetic
+[stewart inout]: https://delvingbitcoin.org/t/op-inout-amount/549/4
+[stewart overflow]: https://delvingbitcoin.org/t/overflow-handling-in-script/1549
+[poinsot addrvuln]: https://mailing-list.bitcoindevs.xyz/bitcoindev/EYvwAFPNEfsQ8cVwiK-8v6ovJU43Vy-ylARiDQ_1XBXAgg_ZqWIpB6m51fAIRtI-rfTmMGvGLrOe5Utl5y9uaHySELpya2ojC7yGsXnP90s=@protonmail.com/
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: bitschmidty
body: we use bitcoindevs.xyz here for the ML but the google group link for [stewart bippost] 
created_at: 2025-05-15T14:15:59Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,150 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: bitschmidty
body: ```suggestion
  operate on 64-bit numeric values.  This follows his previous research into
```
created_at: 2025-05-15T14:16:38Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,150 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  previous discussion, the new proposal uses numbers in the same
+  compactSize data format currently used in Bitcoin.  Additional related
+  [discussion][stewart inout] occurred on two [threads][stewart
+  overflow] on Delving Bitcoin.
+
+<!-- FIXME:harding: ran out of time, will work on some of these topics
+
+- Bram Cohen quines
+- CTV+CSFS BitVM bridges
+- General computation with OP_CAT
+- Wager on OP_CAT activation
+- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
+- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
+- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
+- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
+
+-->
+
+## 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._
+
+- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN
+  node.  One of the major improvements that could probably use testing
+  is the new RBF-based fee bumping for cooperative closes.
+
+## 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]._
+
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the proposed [BIP54][]
+  [consensus cleanup]​​[topic consensus cleanup] soft fork. Timelocking coinbase
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: bitschmidty
body: ```suggestion
  [consensus cleanup]​[topic consensus cleanup] soft fork. Timelocking coinbase
```
created_at: 2025-05-15T14:24:21Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,150 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  previous discussion, the new proposal uses numbers in the same
+  compactSize data format currently used in Bitcoin.  Additional related
+  [discussion][stewart inout] occurred on two [threads][stewart
+  overflow] on Delving Bitcoin.
+
+<!-- FIXME:harding: ran out of time, will work on some of these topics
+
+- Bram Cohen quines
+- CTV+CSFS BitVM bridges
+- General computation with OP_CAT
+- Wager on OP_CAT activation
+- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
+- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
+- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
+- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
+
+-->
+
+## 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._
+
+- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN
+  node.  One of the major improvements that could probably use testing
+  is the new RBF-based fee bumping for cooperative closes.
+
+## 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]._
+
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the proposed [BIP54][]
+  [consensus cleanup]​​[topic consensus cleanup] soft fork. Timelocking coinbase
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: bitschmidty
body: Some hidden-ish character in there
created_at: 2025-05-15T14:25:05Z
author_association: CONTRIBUTOR
diff_hunk: @@ -94,7 +94,7 @@ for details --> {% endcomment %}
 [BIP49]: https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki
 [BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
 [BIP52]: https://github.com/bitcoin/bips/blob/master/bip-0052.mediawiki
-[BIP54]: https://github.com/bitcoin/bips/blob/master/bip-0052.mediawiki
+[BIP54]: https://github.com/bitcoin/bips/blob/master/bip-0054.mediawiki
path: _includes/references.md
user: login: bitschmidty
body: ```suggestion
[BIP54]: https://github.com/bitcoin/bips/blob/master/bip-0054.md
```
created_at: 2025-05-15T14:26:05Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,150 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  previous discussion, the new proposal uses numbers in the same
+  compactSize data format currently used in Bitcoin.  Additional related
+  [discussion][stewart inout] occurred on two [threads][stewart
+  overflow] on Delving Bitcoin.
+
+<!-- FIXME:harding: ran out of time, will work on some of these topics
+
+- Bram Cohen quines
+- CTV+CSFS BitVM bridges
+- General computation with OP_CAT
+- Wager on OP_CAT activation
+- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
+- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
+- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
+- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
+
+-->
+
+## 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._
+
+- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN
+  node.  One of the major improvements that could probably use testing
+  is the new RBF-based fee bumping for cooperative closes.
+
+## 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]._
+
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the proposed [BIP54][]
+  [consensus cleanup]​​[topic consensus cleanup] soft fork. Timelocking coinbase
+  transactions solves the [duplicate transaction][topic duplicate transactions]
+  vulnerability, and would allow the costly [BIP30][] checks to be lifted.
+
+- [Bitcoin Core #28710][] removes the remaining legacy wallet code,
+  documentation, and related tests. This includes the legacy-only RPCs, such as
+  `importmulti`, `sethdseed`, `addmultisigaddress`, `importaddress`,
+  `importpubkey`, `dumpwallet`, `importwallet`, and `newkeypool`. As the final
+  step for legacy wallet removal, the BerkeleyDB dependency and related
+  functions are also removed. However, the bare minimum of legacy code and an
+  independent BDB parser (see Newsletter [#305][news305 bdb]) are retained in
+  order to perform wallet migration to [descriptor][topic descriptors] wallets.
+
+- [Core Lightning #8272][] disables the DNS seed lookup peer discovery fallback
+  from the connection daemon `connectd` to resolve call block issues caused by
+  offline DNS seeds.
+
+- [LND #8330][] adds a small constant (1/c) to the pathfinding bimodal
+  probability model to address numerical instability. In edge cases where the
+  calculation would otherwise fail due to rounding errors and produce a zero
+  probability, this regularization provides a fallback by causing the model to
+  revert to a uniform distribution. This resolves normalization bugs that occur
+  in scenarios involving very large channels or channels that don't fit a
+  bimodal distribution. Additionally, the model now skips unnecessary
+  probability calculations and automatically corrects outdated mission control
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: bitschmidty
body: Is there a way to translate whatever mission control data is in LND for the reader? @Gustavojfe 
created_at: 2025-05-15T14:29:33Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,150 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  previous discussion, the new proposal uses numbers in the same
+  compactSize data format currently used in Bitcoin.  Additional related
+  [discussion][stewart inout] occurred on two [threads][stewart
+  overflow] on Delving Bitcoin.
+
+<!-- FIXME:harding: ran out of time, will work on some of these topics
+
+- Bram Cohen quines
+- CTV+CSFS BitVM bridges
+- General computation with OP_CAT
+- Wager on OP_CAT activation
+- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
+- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
+- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
+- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
+
+-->
+
+## 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._
+
+- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN
+  node.  One of the major improvements that could probably use testing
+  is the new RBF-based fee bumping for cooperative closes.
+
+## 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]._
+
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the proposed [BIP54][]
+  [consensus cleanup]​​[topic consensus cleanup] soft fork. Timelocking coinbase
+  transactions solves the [duplicate transaction][topic duplicate transactions]
+  vulnerability, and would allow the costly [BIP30][] checks to be lifted.
+
+- [Bitcoin Core #28710][] removes the remaining legacy wallet code,
+  documentation, and related tests. This includes the legacy-only RPCs, such as
+  `importmulti`, `sethdseed`, `addmultisigaddress`, `importaddress`,
+  `importpubkey`, `dumpwallet`, `importwallet`, and `newkeypool`. As the final
+  step for legacy wallet removal, the BerkeleyDB dependency and related
+  functions are also removed. However, the bare minimum of legacy code and an
+  independent BDB parser (see Newsletter [#305][news305 bdb]) are retained in
+  order to perform wallet migration to [descriptor][topic descriptors] wallets.
+
+- [Core Lightning #8272][] disables the DNS seed lookup peer discovery fallback
+  from the connection daemon `connectd` to resolve call block issues caused by
+  offline DNS seeds.
+
+- [LND #8330][] adds a small constant (1/c) to the pathfinding bimodal
+  probability model to address numerical instability. In edge cases where the
+  calculation would otherwise fail due to rounding errors and produce a zero
+  probability, this regularization provides a fallback by causing the model to
+  revert to a uniform distribution. This resolves normalization bugs that occur
+  in scenarios involving very large channels or channels that don't fit a
+  bimodal distribution. Additionally, the model now skips unnecessary
+  probability calculations and automatically corrects outdated mission control
+  data and contradictory historical information.
+
+- [Rust Bitcoin #4458][] replaces the `MtpAndHeight` struct with an explicit
+  pair of the newly added `BlockMtp` and the already existing `BlockHeight`,
+  enabling better modeling of both block height and Median Time Past (MTP)
+  values in relative [timelocks][topic timelocks]. Unlike
+  `locktime::absolute::Mtp`, which is constrained to values above 500 million
+  (roughly after 1985), `BlockMtp` can represent any 32-bit timestamp. This
+  makes it suitable for theoretical edge cases, such as chains with unusual
+  timestamps. This update also introduces `BlockMtpInterval`, and renames
+  `BlockInterval` to `BlockHeightInterval`.
+
+- [BIPs #1848][] updates the status of [BIP345][] to `Withdrawn`, as the author
+  believes its proposed `OP_VAULT` opcode has been superseded by
+  [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), a more general vault design
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: bitschmidty
body: ```suggestion
  [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), a more general [vault][topic vaults] design
```
created_at: 2025-05-15T14:31:10Z
author_association: CONTRIBUTOR
diff_hunk: @@ -76,21 +76,63 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo],
 [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition
 repo], and [BINANAs][binana repo]._
 
-- [Bitcoin Core #32155][] miner: timelock the coinbase to the mined block's height
-
-- [Bitcoin Core #28710][] Remove the legacy wallet and BDB dependency
-
-- [Core Lightning #8272][] connectd: remove DNS seed lookups.
-
-- [LND #8330][] bitromortac/2401-bimodal-improvements
-
-- [Rust Bitcoin #4458][] locktimes: replace `MtpAndHeight` type with pair of `BlockMtp` and `BlockHeight`
-
-- [BIPs #1848][] 'jamesob-25-05-withdraw-vault' - See also https://delvingbitcoin.org/t/withdrawing-op-vault-bip-345/1670
-
-- [BIPs #1841][] Adds BIP172: Define Bitcoin Subunits as Satoshis
-
-- [BIPs #1821][] BIP177: Redefine Bitcoin’s Base Unit
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the proposed [BIP54][]
+  [consensus cleanup]​​[topic consensus cleanup] soft fork. Timelocking coinbase
+  transactions solves the [duplicate transaction][topic duplicate transactions]
+  vulnerability, and would allow the costly [BIP30][] checks to be lifted.
+
+- [Bitcoin Core #28710][] removes the remaining legacy wallet code,
+  documentation, and related tests. This includes the legacy-only RPCs, such as
+  `importmulti`, `sethdseed`, `addmultisigaddress`, `importaddress`,
+  `importpubkey`, `dumpwallet`, `importwallet`, and `newkeypool`. As the final
+  step for legacy wallet removal, the BerkeleyDB dependency and related
+  functions are also removed. However, the bare minimum of legacy code and an
+  independent BDB parser (see Newsletter [#305][news305 bdb]) are retained in
+  order to perform wallet migration to [descriptor][topic descriptors] wallets.
+
+- [Core Lightning #8272][] disables the DNS seed lookup peer discovery fallback
+  from the connection daemon `connectd` to resolve call block issues caused by
+  offline DNS seeds.
+
+- [LND #8330][] adds a small constant (1/c) to the pathfinding bimodal
+  probability model to address numerical instability. In edge cases where the
+  calculation would otherwise fail due to rounding errors and produce a zero
+  probability, this regularization provides a fallback by causing the model to
+  revert to a uniform distribution. This resolves normalization bugs that occur
+  in scenarios involving very large channels or channels that don't fit a
+  bimodal distribution. Additionally, the model now skips unnecessary
+  probability calculations and automatically corrects outdated mission control
+  data and contradictory historical information.
+
+- [Rust Bitcoin #4458][] replaces the `MtpAndHeight` struct with an explicit
+  pair of the newly added `BlockMtp` and the already existing `BlockHeight`,
+  enabling better modeling of both block height and Median Time Past (MTP)
+  values in relative [timelocks][topic timelocks]. Unlike
+  `locktime::absolute::Mtp`, which is constrained to values above 500 million
+  (roughly after 1985), `BlockMtp` can represent any 32-bit timestamp. This
+  makes it suitable for theoretical edge cases, such as chains with unusual
+  timestamps. This update also introduces `BlockMtpInterval`, and renames
+  `BlockInterval` to `BlockHeightInterval`.
+
+- [BIPs #1848][] updates the status of [BIP345][] to `Withdrawn`, as the author
+  believes its proposed `OP_VAULT` opcode has been superseded by
+  [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), a more general vault design
+  and a new type of [covenant][topic covenants].
+
+- [BIPs #1841][] merges [BIP172][], which proposes formally defining Bitcoin’s
+  indivisible base unit as a “satoshi,” reflecting current widespread usage and
+  helping standardize terminology across applications and documentation.
+
+- [BIPs #1821][] merges [BIP177][], which proposes redefining “bitcoin” to
+  represent the smallest indivisible unit (commonly referred as 1 satoshi),
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: LarryRuane
body: ```suggestion
  represent the smallest indivisible unit (commonly referred to as 1 satoshi),
```
created_at: 2025-05-15T14:34:30Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,150 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  previous discussion, the new proposal uses numbers in the same
+  compactSize data format currently used in Bitcoin.  Additional related
+  [discussion][stewart inout] occurred on two [threads][stewart
+  overflow] on Delving Bitcoin.
+
+<!-- FIXME:harding: ran out of time, will work on some of these topics
+
+- Bram Cohen quines
+- CTV+CSFS BitVM bridges
+- General computation with OP_CAT
+- Wager on OP_CAT activation
+- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
+- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
+- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
+- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
+
+-->
+
+## 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._
+
+- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN
+  node.  One of the major improvements that could probably use testing
+  is the new RBF-based fee bumping for cooperative closes.
+
+## 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]._
+
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the proposed [BIP54][]
+  [consensus cleanup]​​[topic consensus cleanup] soft fork. Timelocking coinbase
+  transactions solves the [duplicate transaction][topic duplicate transactions]
+  vulnerability, and would allow the costly [BIP30][] checks to be lifted.
+
+- [Bitcoin Core #28710][] removes the remaining legacy wallet code,
+  documentation, and related tests. This includes the legacy-only RPCs, such as
+  `importmulti`, `sethdseed`, `addmultisigaddress`, `importaddress`,
+  `importpubkey`, `dumpwallet`, `importwallet`, and `newkeypool`. As the final
+  step for legacy wallet removal, the BerkeleyDB dependency and related
+  functions are also removed. However, the bare minimum of legacy code and an
+  independent BDB parser (see Newsletter [#305][news305 bdb]) are retained in
+  order to perform wallet migration to [descriptor][topic descriptors] wallets.
+
+- [Core Lightning #8272][] disables the DNS seed lookup peer discovery fallback
+  from the connection daemon `connectd` to resolve call block issues caused by
+  offline DNS seeds.
+
+- [LND #8330][] adds a small constant (1/c) to the pathfinding bimodal
+  probability model to address numerical instability. In edge cases where the
+  calculation would otherwise fail due to rounding errors and produce a zero
+  probability, this regularization provides a fallback by causing the model to
+  revert to a uniform distribution. This resolves normalization bugs that occur
+  in scenarios involving very large channels or channels that don't fit a
+  bimodal distribution. Additionally, the model now skips unnecessary
+  probability calculations and automatically corrects outdated mission control
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: Gustavojfe
body: renamed it to "channel liquidity observations"
created_at: 2025-05-15T17:56:56Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,150 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  previous discussion, the new proposal uses numbers in the same
+  compactSize data format currently used in Bitcoin.  Additional related
+  [discussion][stewart inout] occurred on two [threads][stewart
+  overflow] on Delving Bitcoin.
+
+<!-- FIXME:harding: ran out of time, will work on some of these topics
+
+- Bram Cohen quines
+- CTV+CSFS BitVM bridges
+- General computation with OP_CAT
+- Wager on OP_CAT activation
+- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
+- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
+- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
+- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
+
+-->
+
+## 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._
+
+- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN
+  node.  One of the major improvements that could probably use testing
+  is the new RBF-based fee bumping for cooperative closes.
+
+## 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]._
+
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the proposed [BIP54][]
+  [consensus cleanup]​[topic consensus cleanup] soft fork. Timelocking coinbase
+  transactions solves the [duplicate transaction][topic duplicate transactions]
+  vulnerability, and would allow the costly [BIP30][] checks to be lifted.
+
+- [Bitcoin Core #28710][] removes the remaining legacy wallet code,
+  documentation, and related tests. This includes the legacy-only RPCs, such as
+  `importmulti`, `sethdseed`, `addmultisigaddress`, `importaddress`,
+  `importpubkey`, `dumpwallet`, `importwallet`, and `newkeypool`. As the final
+  step for legacy wallet removal, the BerkeleyDB dependency and related
+  functions are also removed. However, the bare minimum of legacy code and an
+  independent BDB parser (see Newsletter [#305][news305 bdb]) are retained in
+  order to perform wallet migration to [descriptor][topic descriptors] wallets.
+
+- [Core Lightning #8272][] disables the DNS seed lookup peer discovery fallback
+  from the connection daemon `connectd` to resolve call block issues caused by
+  offline DNS seeds.
+
+- [LND #8330][] adds a small constant (1/c) to the pathfinding bimodal
+  probability model to address numerical instability. In edge cases where the
+  calculation would otherwise fail due to rounding errors and produce a zero
+  probability, this regularization provides a fallback by causing the model to
+  revert to a uniform distribution. This resolves normalization bugs that occur
+  in scenarios involving very large channels or channels that don't fit a
+  bimodal distribution. Additionally, the model now skips unnecessary
+  probability calculations and automatically corrects outdated channel liquidity
+  observations and contradictory historical information.
+
+- [Rust Bitcoin #4458][] replaces the `MtpAndHeight` struct with an explicit
+  pair of the newly added `BlockMtp` and the already existing `BlockHeight`,
+  enabling better modeling of both block height and Median Time Past (MTP)
+  values in relative [timelocks][topic timelocks]. Unlike
+  `locktime::absolute::Mtp`, which is constrained to values above 500 million
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: jirijakes
body: ```suggestion
  `locktime::absolute::MedianTimePast`, which is constrained to values above 500 million
```

It was later [renamed](https://github.com/rust-bitcoin/rust-bitcoin/pull/4462/files#diff-4cd8e9b2bdc17689f9bf7e9d43908beb4c8d2c87c4752903f23e783915af9806).
created_at: 2025-05-15T23:50:27Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,150 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  previous discussion, the new proposal uses numbers in the same
+  compactSize data format currently used in Bitcoin.  Additional related
+  [discussion][stewart inout] occurred on two [threads][stewart
+  overflow] on Delving Bitcoin.
+
+<!-- FIXME:harding: ran out of time, will work on some of these topics
+
+- Bram Cohen quines
+- CTV+CSFS BitVM bridges
+- General computation with OP_CAT
+- Wager on OP_CAT activation
+- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
+- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
+- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
+- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
+
+-->
+
+## 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._
+
+- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN
+  node.  One of the major improvements that could probably use testing
+  is the new RBF-based fee bumping for cooperative closes.
+
+## 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]._
+
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the proposed [BIP54][]
+  [consensus cleanup]​[topic consensus cleanup] soft fork. Timelocking coinbase
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: jirijakes
body: There is a zero-width space between `][` which prevents link from forming. Suggestion does not work, must be cleaned up manually.
created_at: 2025-05-16T00:40:55Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,150 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  previous discussion, the new proposal uses numbers in the same
+  compactSize data format currently used in Bitcoin.  Additional related
+  [discussion][stewart inout] occurred on two [threads][stewart
+  overflow] on Delving Bitcoin.
+
+<!-- FIXME:harding: ran out of time, will work on some of these topics
+
+- Bram Cohen quines
+- CTV+CSFS BitVM bridges
+- General computation with OP_CAT
+- Wager on OP_CAT activation
+- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
+- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
+- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
+- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
+
+-->
+
+## 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._
+
+- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN
+  node.  One of the major improvements that could probably use testing
+  is the new RBF-based fee bumping for cooperative closes.
+
+## 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]._
+
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the proposed [BIP54][]
+  [consensus cleanup]​​[topic consensus cleanup] soft fork. Timelocking coinbase
+  transactions solves the [duplicate transaction][topic duplicate transactions]
+  vulnerability, and would allow the costly [BIP30][] checks to be lifted.
+
+- [Bitcoin Core #28710][] removes the remaining legacy wallet code,
+  documentation, and related tests. This includes the legacy-only RPCs, such as
+  `importmulti`, `sethdseed`, `addmultisigaddress`, `importaddress`,
+  `importpubkey`, `dumpwallet`, `importwallet`, and `newkeypool`. As the final
+  step for legacy wallet removal, the BerkeleyDB dependency and related
+  functions are also removed. However, the bare minimum of legacy code and an
+  independent BDB parser (see Newsletter [#305][news305 bdb]) are retained in
+  order to perform wallet migration to [descriptor][topic descriptors] wallets.
+
+- [Core Lightning #8272][] disables the DNS seed lookup peer discovery fallback
+  from the connection daemon `connectd` to resolve call block issues caused by
+  offline DNS seeds.
+
+- [LND #8330][] adds a small constant (1/c) to the pathfinding bimodal
+  probability model to address numerical instability. In edge cases where the
+  calculation would otherwise fail due to rounding errors and produce a zero
+  probability, this regularization provides a fallback by causing the model to
+  revert to a uniform distribution. This resolves normalization bugs that occur
+  in scenarios involving very large channels or channels that don't fit a
+  bimodal distribution. Additionally, the model now skips unnecessary
+  probability calculations and automatically corrects outdated mission control
+  data and contradictory historical information.
+
+- [Rust Bitcoin #4458][] replaces the `MtpAndHeight` struct with an explicit
+  pair of the newly added `BlockMtp` and the already existing `BlockHeight`,
+  enabling better modeling of both block height and Median Time Past (MTP)
+  values in relative [timelocks][topic timelocks]. Unlike
+  `locktime::absolute::Mtp`, which is constrained to values above 500 million
+  (roughly after 1985), `BlockMtp` can represent any 32-bit timestamp. This
+  makes it suitable for theoretical edge cases, such as chains with unusual
+  timestamps. This update also introduces `BlockMtpInterval`, and renames
+  `BlockInterval` to `BlockHeightInterval`.
+
+- [BIPs #1848][] updates the status of [BIP345][] to `Withdrawn`, as the author
+  believes its proposed `OP_VAULT` opcode has been superseded by
+  [`OP_CHECKCONTRACTVERIFY`][topic matt] (OP_CCV), a more general vault design
+  and a new type of [covenant][topic covenants].
+
+- [BIPs #1841][] merges [BIP172][], which proposes formally defining Bitcoin’s
+  indivisible base unit as a “satoshi,” reflecting current widespread usage and
+  helping standardize terminology across applications and documentation.
+
+- [BIPs #1821][] merges [BIP177][], which proposes redefining “bitcoin” to
+  represent the smallest indivisible unit (commonly referred as 1 satoshi),
+  rather than 100,000,000 units. The proposal argues that aligning terminology
+  with the actual base unit would reduce confusion caused by arbitrary decimal
+  conventions.
+
+{% include snippets/recap-ad.md when="2025-05-20 16:30" %}
+{% include references.md %}
+{% include linkers/issues.md v=2 issues="32155,28710,8272,8330,4458,1848,1841,1821" %}
+[lnd 0.19.0-beta.rc4]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc4
+[news314 excess addr]: /en/newsletters/2024/08/02/#remote-crash-by-sending-excessive-addr-messages
+[stewart bippost]: https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE
+[64bit bip]: https://github.com/Christewart/bips/blob/2025-03-17-64bit-pt2/bip-XXXX.mediawiki
+[news285 64bit]: /en/newsletters/2024/01/17/#proposal-for-64-bit-arithmetic-soft-fork
+[news290 64bit]: /en/newsletters/2024/02/21/#continued-discussion-about-64-bit-arithmetic-and-op-inout-amount-opcode
+[news306 64bit]: /en/newsletters/2024/06/07/#updates-to-proposed-soft-fork-for-64-bit-arithmetic
+[stewart inout]: https://delvingbitcoin.org/t/op-inout-amount/549/4
+[stewart overflow]: https://delvingbitcoin.org/t/overflow-handling-in-script/1549
+[poinsot addrvuln]: https://mailing-list.bitcoindevs.xyz/bitcoindev/EYvwAFPNEfsQ8cVwiK-8v6ovJU43Vy-ylARiDQ_1XBXAgg_ZqWIpB6m51fAIRtI-rfTmMGvGLrOe5Utl5y9uaHySELpya2ojC7yGsXnP90s=@protonmail.com/
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: harding
body: bitcoindevs.xyz isn't updating and doesn't have the Stewart post, so I had to use Google Groups for that link.  :-(
created_at: 2025-05-16T02:30:43Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,150 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  previous discussion, the new proposal uses numbers in the same
+  compactSize data format currently used in Bitcoin.  Additional related
+  [discussion][stewart inout] occurred on two [threads][stewart
+  overflow] on Delving Bitcoin.
+
+<!-- FIXME:harding: ran out of time, will work on some of these topics
+
+- Bram Cohen quines
+- CTV+CSFS BitVM bridges
+- General computation with OP_CAT
+- Wager on OP_CAT activation
+- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
+- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
+- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
+- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
+
+-->
+
+## 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._
+
+- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN
+  node.  One of the major improvements that could probably use testing
+  is the new RBF-based fee bumping for cooperative closes.
+
+## 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]._
+
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the proposed [BIP54][]
+  [consensus cleanup]​[topic consensus cleanup] soft fork. Timelocking coinbase
+  transactions solves the [duplicate transaction][topic duplicate transactions]
+  vulnerability, and would allow the costly [BIP30][] checks to be lifted.
+
+- [Bitcoin Core #28710][] removes the remaining legacy wallet code,
+  documentation, and related tests. This includes the legacy-only RPCs, such as
+  `importmulti`, `sethdseed`, `addmultisigaddress`, `importaddress`,
+  `importpubkey`, `dumpwallet`, `importwallet`, and `newkeypool`. As the final
+  step for legacy wallet removal, the BerkeleyDB dependency and related
+  functions are also removed. However, the bare minimum of legacy code and an
+  independent BDB parser (see Newsletter [#305][news305 bdb]) are retained in
+  order to perform wallet migration to [descriptor][topic descriptors] wallets.
+
+- [Core Lightning #8272][] disables the DNS seed lookup peer discovery fallback
+  from the connection daemon `connectd` to resolve call block issues caused by
+  offline DNS seeds.
+
+- [LND #8330][] adds a small constant (1/c) to the pathfinding bimodal
+  probability model to address numerical instability. In edge cases where the
+  calculation would otherwise fail due to rounding errors and produce a zero
+  probability, this regularization provides a fallback by causing the model to
+  revert to a uniform distribution. This resolves normalization bugs that occur
+  in scenarios involving very large channels or channels that don't fit a
+  bimodal distribution. Additionally, the model now skips unnecessary
+  probability calculations and automatically corrects outdated channel liquidity
+  observations and contradictory historical information.
+
+- [Rust Bitcoin #4458][] replaces the `MtpAndHeight` struct with an explicit
+  pair of the newly added `BlockMtp` and the already existing `BlockHeight`,
+  enabling better modeling of both block height and Median Time Past (MTP)
+  values in relative [timelocks][topic timelocks]. Unlike
+  `locktime::absolute::Mtp`, which is constrained to values above 500 million
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: harding
body: Thanks for this keen observation!  Updating.
created_at: 2025-05-16T02:34:58Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,150 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter FIXME
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, which would result in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
+
+## Changing consensus
+
+_A monthly section summarizing proposals and discussion about changing
+Bitcoin's consensus rules._
+
+- **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
+  [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
+  mailing list that proposes upgrading Bitcoin's existing opcodes to
+  operate on 64 numeric values.  This follows his previous research into
+  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  64bit], and [#306][news306 64bit]).  In a change from some of the
+  previous discussion, the new proposal uses numbers in the same
+  compactSize data format currently used in Bitcoin.  Additional related
+  [discussion][stewart inout] occurred on two [threads][stewart
+  overflow] on Delving Bitcoin.
+
+<!-- FIXME:harding: ran out of time, will work on some of these topics
+
+- Bram Cohen quines
+- CTV+CSFS BitVM bridges
+- General computation with OP_CAT
+- Wager on OP_CAT activation
+- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
+- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
+- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
+- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
+
+-->
+
+## 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._
+
+- [LND 0.19.0-beta.rc4][] is a release candidate for this popular LN
+  node.  One of the major improvements that could probably use testing
+  is the new RBF-based fee bumping for cooperative closes.
+
+## 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]._
+
+- [Bitcoin Core #32155][] updates the internal miner to [timelock][topic
+  timelocks] coinbase transactions by setting the `nLockTime` field to the
+  current block’s height minus one and requiring the `nSequence` field not to be
+  final (to enforce the timelock). Although the built-in miner isn’t typically
+  used on mainnet, updating it encourages mining pools to adopt these changes
+  early in their own software in preparation for the proposed [BIP54][]
+  [consensus cleanup]​[topic consensus cleanup] soft fork. Timelocking coinbase
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: harding
body: Deleted the space and rephrased slightly per our policy of trying to avoid two links in a row (which visually appear to be a single link).  Thanks!
created_at: 2025-05-16T02:37:51Z
author_association: COLLABORATOR
diff_hunk: @@ -34,26 +38,31 @@ Bitcoin's consensus rules._
 - **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
   [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
   mailing list that proposes upgrading Bitcoin's existing opcodes to
-  operate on 64 numeric values.  This follows his previous research into
-  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  operate on 64-bit numeric values.  This follows his previous research
+  (see Newsletters [#285][news285 64bit], [#290][news290
   64bit], and [#306][news306 64bit]).  In a change from some of the
-  previous discussion, the new proposal uses numbers in the same
+  earlier discussion, the new proposal uses numbers in the same
   compactSize data format currently used in Bitcoin.  Additional related
   [discussion][stewart inout] occurred on two [threads][stewart
   overflow] on Delving Bitcoin.
 
-<!-- FIXME:harding: ran out of time, will work on some of these topics
-
-- Bram Cohen quines
-- CTV+CSFS BitVM bridges
-- General computation with OP_CAT
-- Wager on OP_CAT activation
-- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
-- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
-- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
-- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
-
--->
+- **Proposed opcodes for enabling recursive covenants through quines:**
+  Bram Cohen [posted][cohen quine] to Delving Bitcoin to suggest a set
+  of simple opcodes that would the creation of recursive
+  [covenants][topic covenants] through self-reproducing scripts
+  (quines).  Cohen describes how the opcodes could be used to create a
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: jirijakes
body: I did not know the term _quine_ before. Could it be linked to https://en.wikipedia.org/wiki/Quine_(computing) ?
created_at: 2025-05-16T03:24:01Z
author_association: CONTRIBUTOR
diff_hunk: @@ -34,26 +38,31 @@ Bitcoin's consensus rules._
 - **Proposed BIP for 64-bit arithmetic in Script:** Chris Stewart
   [posted][stewart bippost] a [draft BIP][64bit bip] to the Bitcoin-Dev
   mailing list that proposes upgrading Bitcoin's existing opcodes to
-  operate on 64 numeric values.  This follows his previous research into
-  the subject (see Newsletters [#285][news285 64bit], [#290][news290
+  operate on 64-bit numeric values.  This follows his previous research
+  (see Newsletters [#285][news285 64bit], [#290][news290
   64bit], and [#306][news306 64bit]).  In a change from some of the
-  previous discussion, the new proposal uses numbers in the same
+  earlier discussion, the new proposal uses numbers in the same
   compactSize data format currently used in Bitcoin.  Additional related
   [discussion][stewart inout] occurred on two [threads][stewart
   overflow] on Delving Bitcoin.
 
-<!-- FIXME:harding: ran out of time, will work on some of these topics
-
-- Bram Cohen quines
-- CTV+CSFS BitVM bridges
-- General computation with OP_CAT
-- Wager on OP_CAT activation
-- Post quantum signatures: https://mailing-list.bitcoindevs.xyz/bitcoindev/76c5ec26-5fd5-4746-86ed-89d2c8e28cbc@mattcorallo.com/T/#t
-- Substring search: https://mailing-list.bitcoindevs.xyz/bitcoindev/e1c28747-ccc9-4d14-a93f-77dbe08a0ba9n@googlegroups.com/T/#t
-- Path to general computation on Bitcoin with OP_CAT https://delvingbitcoin.org/t/the-path-to-general-computation-on-bitcoin-with-op-cat/1106
-- Post-sig cross-input scripting: https://delvingbitcoin.org/t/post-signature-cross-input-scripting-using-the-taproot-annex/1520/3
-
--->
+- **Proposed opcodes for enabling recursive covenants through quines:**
+  Bram Cohen [posted][cohen quine] to Delving Bitcoin to suggest a set
+  of simple opcodes that would the creation of recursive
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: jirijakes
body: Some verb is missing here, e.g.:

```suggestion
  of simple opcodes that would enable the creation of recursive
```
created_at: 2025-05-16T03:29:31Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,161 @@
+---
+title: 'Bitcoin Optech Newsletter #354'
+permalink: /en/newsletters/2025/05/16/
+name: 2025-05-16-newsletter
+slug: 2025-05-16-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter describes a fixed vulnerability affecting old
+versions of Bitcoin Core.  Also included are our regular sections
+summarizing recent discussions about changing Bitcoin's consensus rules,
+announcing new releases and release candidates, and describing notable
+changes to popular Bitcoin infrastructure software.
+
+## News
+
+- **Vulnerability disclosure affecting old versions of Bitcoin Core:**
+  Antoine Poinsot [posted][poinsot addrvuln] to the Bitcoin-Dev mailing
+  list to announce a vulnerability affecting Bitcoin Core versions
+  before 29.0.  The vulnerability was originally [responsibly
+  disclosed][topic responsible disclosures] by Eugene Siegel along with
+  another closely related vulnerability described in [Newsletter
+  #314][news314 excess addr].  An attacker could send an excessive
+  number of node address advertisements to force a 32-bit identifier to
+  overflow, resulting in a node crash.  This was partly
+  mitigated by limiting the number of updates to one per peer per every
+  ten seconds, which for the default limit of about 125 peers would
+  prevent overflow unless the node was continuously attacked for over 10
+  years. <!-- 2**32 * 10 / 125 / (60 * 60 * 24 * 365) --> The
+  vulnerability was fixed in Bitcoin Core 29.0, released last month.
path: _posts/en/newsletters/2025-05-16-newsletter.md
user: login: azuchi
body: How about specifying that the vulnerability was fixed by making the identifier a 64-bit identifier?
created_at: 2025-05-16T05:37:14Z
author_association: CONTRIBUTOR

PR comments:
user: login: harding
created_at: 2025-05-16T03:15:58Z
body: Pushed remaining content and all edits (thanks @LarryRuane @bitschmidty @jirijakes !).  I have to run but I'll be back in a few hours to add the topic entries.  Thanks everyone!
author_association: COLLABORATOR
user: login: harding
created_at: 2025-05-16T06:50:54Z
body: Made edits for @jirijakes and @azuchi feedback (thanks!), added topic entries, and reviewed @Gustavojfe section (great work this week!).  Thanks everyone!
author_association: COLLABORATOR