Issue 07: September 3, 2025

Translation issues, bitcoin as a currency, and the rise of Knots

Sep 03, 2025

Good morning,

Last Thursday, Bitcoin Core developers discussed updates from four working groups: Stratum V2, MuSig2, QML GUI, and Benchmarking. They also discussed progress on the next major Bitcoin Core release, v30.0.

Additionally, on Delving Bitcoin, Bitcoin developer Josh Doman shared additional color on his arguments for why he believes bitcoin, the cryptocurrency, is the “optimal” unit-of-account under perfect capital market assumptions. Also on Bitcoin Talk, a new discussion thread sparked conversation about Bitcoin Knots and the ideological differences in the Bitcoin community driving its adoption.

Below is my write-up on the Bitcoin Core developers meeting that took place on Thursday, August 21, 2025, and other core Bitcoin discussions from this past week.

Yours truly,

Christine D. Kim

Core Release Schedule

First, here’s a quick overview of Bitcoin Core’s software release schedule and the status of the next major release:

Latest Stable Major Release: Bitcoin Core 29.0

Release Date: April 15, 2025

Latest Stable Minor Release: Bitcoin Core 28.2

Release Date: June 27, 2025

Upcoming Major Release: Bitcoin Core 30.0

Target Release Date: Early October 2025
Open issues: 14
Closed issues: 71
Milestone progress: 83%

(Previous week’s snapshot showed 9 open issues, 69 closed, and a milestone progress of 88%.)

Meeting Minutes

Editor’s note: Some quotes featured in this section and the next have been edited slightly for grammar and clarity.

🗒️Managing translations of Bitcoin Core

Discussion: Last Thursday, developers discussed PR #33224 (doc: unify datacarriersize warning with release notes). It is a minor change that updates a warning message in Bitcoin Core related to the datacarriersize parameter.

This parameter defines the maximum size (in bytes) of arbitrary data — typically in OP_RETURN outputs — that nodes will relay. Historically, the default was capped at 83 bytes. However, with the adoption of PR #32406 in Bitcoin Core v30, the default will be increased to 100,000 bytes, effectively uncapping the limit since it exceeds the maximum transaction size limit.

The parameter itself will remain available but marked as deprecated and expected to be removed in a future release.

PR #33224 proposes a slight wording change for the warning message node operators will receive if they override the default setting.

Instead of a warning telling node operators that the parameter “will be removed in a future version,” the proposed wording would say it is “expected to be removed in a future version.”

Bitcoin Core developer “L0rinc,” who authored PR #33224, said the proposed wording is “less aggressive” and more consistent with the release notes.

Despite broad agreement on the change, developers hesitated to merge it before v30 due to translation issues that could arise from the wording change.

Bitcoin Core developer “Achow” said:

The blocker on that is the translation string, since updating Transifex will mess up translations that have already been done.

As background, Bitcoin Core uses Transifex to support translations of Bitcoin Core software into languages other than English.

Any text shown to a user, such as error messages, warnings, and GUI labels, is compiled into one file and uploaded to Transifex. Each of these messages becomes a “key” in Transifex that volunteers around the world can translate into other languages.

Any changes to text require the creation of a new key in Transifex and new translations of that key. For software like Bitcoin Core, which is translated into over 150 languages with the help of more than 9,000 volunteer contributors, even minor text changes can have broad ripple effects.

About the inconvenience of updating Bitcoin Core text, L0rinc said:

Sounds like Transifex is holding us prisoners here... I'm not sure I fully understand why this is an unsolvable problem, seems like a very minor inconvenience only - and I don't mind helping where I can.

Achow responded:

It's an inconvenience to all translators, and an inconvenience to the maintainers for the next 2 years. I don't think that's "very minor.”

When preparing a new Bitcoin Core release, Bitcoin developers include the latest set of text translations downloaded from Transifex.

Bitcoin Core developer “Stickies-v” asked:

Nothing against the change, but I'm not sure it's worth spending this much time on [to be honest].

Achow emphasized that the process for Bitcoin Core development, as it relates to translations, is to avoid changing them in release branches, such as the forthcoming v30 release. Instead, Achow suggested the PR should be merged into the master branch of Bitcoin Core after the v30 release is cut.

L0rinc acknowledged the contention on his PR and said he would try to understand the nuances of the development process better.

Takeaway: Bitcoin Core developers approach development with the mindset that Bitcoin is mission-critical infrastructure. Thus, even seemingly minor changes — like a wording tweak — are weighed carefully to avoid disrupting users, including those who aren’t active in development or directly represented in the English-dominated discussions about Bitcoin development. This approach is in stark contrast to Ethereum development culture, where inconveniences to users are often accepted, especially if these user groups are not represented or vocal in development discussions.

🗒️Other Topics

Stratum V2 WG: An initiative to modularize and refactor Bitcoin Core components to support a next-generation mining protocol known as Stratum V2.

Bitcoin Core developer Sjors Provoost (“Sjors”) has created a standalone Stratum v2 template provider, a tool that miners can use to generate block templates locally within the Stratum V2 protocol.
PR #31802 (Add bitcoin-{node,gui} to release binaries for IPC) has been merged.

MuSig2 WG: An initiative to modernize the cryptographic scheme that combines multiple signatures authorizing a Bitcoin transaction into a single, compact signature.

PR #29675 (wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys) requires review.

QML GUI WG: An initiative to create a new modern graphical user interface (GUI) for Bitcoin Core using Qt Quick / QML (Qt Modeling Language).

PR #497 (Add first unittest) was recently opened by Bitcoin Core developer “johnny9dev.”
Johnny9dev said his focus is on fleshing out more comprehensive testing for this project.

Benchmarking WG: Efforts to measure and improve the performance of Bitcoin Core software through benchmarking, that is, analyzing how long certain processes take, and looking for ways to make those processes faster and more efficient.

Bitcoin Core developer “L0rinc” said he is measuring initial block download speeds on Raspberry Pi devices.

Bitcoin Core v.30.0 Feature Freeze: The main features of the next major Bitcoin Core release have been finalized. The v30 release is now in a “feature freeze” stage of development, meaning developers are focused on hardening the release and preparing it for the final stages of testing.

PR #33208 (Indexes stuck on unknown best block after unclean shutdown) was removed to prevent it from blocking progress on the rest of the v30 release.
Bitcoin Core developer “stickies-v” requested help reviewing PR #33189 (rpc: follow-ups for 33106). Since last Thursday’s meeting, this PR has been successfully merged and finalized for the v30 release.
Bitcoin Core developer Eugene Siegel said he would review PR #32159 (net, pcp: handle multi-part responses and filter for default route while querying default gateway).

You’ve Got Mail! (& Other News)

Here’s a round-up of other core discussions that happened this past week from the Bitcoin Development Mailing List and other Bitcoin discussion forums:

🖥️ Delving Bitcoin Thread

Subject line: A Game-Theoretic Approach to Bitcoin’s Valuation in Equilibrium

Date(s): March 28 - August 29, 2025

Discussion: In March, Bitcoin developer Josh Doman wrote a post presenting his arguments for why the native cryptocurrency of the Bitcoin protocol, bitcoin (denoted with a lowercase “b”), will emerge as the world’s most “optimal unit of account.”

Doman wrote:

Bitcoin’s unique properties (finite supply, inertness, fungibility, accessibility, and ownership history) position it as the leading candidate to emerge as this unit.

In the post, Doman makes several predictions about the role of bitcoin in the global economy and its value.

One is that the value of bitcoin will eventually come to represent half of all global wealth, which he calls the “maximalist Schelling point”—the point at which all economic actors converge on bitcoin as the preferential unit of relative wealth with no incentives to deviate from this consensus.

A community member by the screen name “Taparoo” responded to Doman’s post, agreeing with the view that bitcoin will represent half of the world’s wealth and eventually become a “daily” unit of account.

Doman disagreed with Taparoo’s additions to his post related to Gresham’s Law and the economic principles that lead to a maximalist Schelling point. However, Doman went on to elaborate on his original motivation for writing the post.

Doman said:

Can we prove the equilibrium value of bitcoin under perfect capital market assumptions? If we can, we’ll have a new tool in our arsenal to explain bitcoin’s value to academics, and to the world at large. … This post argues that unit-of-account is what gives Bitcoin value under perfect capital markets.

Takeaway: Bitcoin’s functionality as a protocol is straightforward to verify: it is open-source, its properties are transparently defined in code and specifications on GitHub, and any changes can be traced through past merges to the codebase.

By contrast, the functionality of bitcoin, the asset—its role, value, and broader use cases in society—is far more subjective and difficult to assess using the principles of economics, game theory, and human nature.

There are ongoing efforts in the Bitcoin community to advance the study of both Bitcoin as a technical protocol and bitcoin as a global monetary asset.

🪙 Bitcoin Talk Thread

Subject line: What is your take on Bitcoin Knotz? Bitcoin node and wallet by Luke Dashjr

Date(s): August 29 - September 2, 2025

Discussion: In a recent discussion thread, Bitcoin community member “Bitmover” asked for context on the debate about Bitcoin Knots.

As background, Knots is a competing implementation of Bitcoin Core created by Core developer and CTO of Bitcoin mining pool OCEAN Luke Dash Jr.

As one response in the thread notes, the adoption of Knots has grown significantly in recent months.

Number of publicly identifiable Bitcoin nodes running Knots. Source: Coin Dance

At the time of writing, roughly 20% of publicly identifiable Bitcoin nodes are running Knots.

The rise in popularity of Knots is primarily due to its mempool policies. Knots nodes will reject forthcoming changes in Bitcoin Core v30 that remove the default cap on arbitrary OP_RETURN data.

Though transactions with more than 83 bytes of such data will still be valid under the protocol’s consensus rules, Knots nodes will not relay them.

One Knots user by the screen name “Headingnort” wrote in the thread that he switched to Knots software “long ago” to avoid having to host “all kinds of garbage” on his Bitcoin node. They added that Bitcoin should only be used for monetary purposes. Headingnort wrote:

From the start Bitcoin was created by Satoshi as a monetary
network first and foremost and should not be turned into another shitcoin like Ethereum, solana, pepecoin, fartcoin, etc.

One community member by the screen name “BitGoba” described the differences in ideologies between Knots and Bitcoin users in the following way:

As a result, many Bitcoin users don’t want to use the Core software and are switching to Bitcoin Knots. Essentially, one side wants Bitcoin only as money and a monetary network, while the other side is more crypto and blockchain oriented.

Proponents of Bitcoin Core pointed out that Knots is not significantly different from Core and does not offer a more secure implementation for protecting nodes from spam transactions.

However, as another community member, “satofan44,” , the technical details are secondary to ideology:

Actually from one side of things, it doesn't even matter if the stuff in Knots works. You can see it more as behavior which signals disagreements with how Core handled this situation.

Takeaway: The debate over Bitcoin Knots versus Bitcoin Core isn’t really about code—it’s about ideology. While Knots developers enforce stricter relay policies and appeals to users who want Bitcoin only for peer-to-peer payments, Core developers prioritize neutrality, allowing a broader set of use cases on Bitcoin so long as the activity doesn’t violate the rules of protocol consensus. The difference in technical implementations between Knots and Core highlights a major ideological divide over Bitcoin’s purpose as a technology in the Bitcoin community.

🗞️Other News

A new Bitcoin Core release candidate (RC) is now available for testing and review. This RC is for the forthcoming Bitcoin Core minor version release, v29.1. (Bitcoin Development Mailing List)
Bitcoin Core contributor Ben Westgate shared a proposal for adding “codex32” as a standardized way for wallets to generate deterministic backups of Bitcoin seed phrases under the BIP-85 framework. (Bitcoin Development Mailing List)
Pseudonymous Bitcoin developer “Apogio” shared a new tool, BASH38, that makes it easier to use the BIP-38 standard for password-protecting Bitcoin private keys, even entirely offline. (Bitcoin Talk)
A long-time Bitcoin community member asks about the basics of starting up a Bitcoin node. The discussion thread features questions and answers about node hardware and bandwidth requirements. (Bitcoin Talk)

🟠 That’s all for my round-up of the core discussions on Bitcoin from the past week. You are now officially caught up on the state of Bitcoin Core development and governance!

🙏 Thank you for reading this issue of BTC Before Light. If you like what you read, consider sharing it with a friend who might also enjoy the content.

💥If today’s post sparked any thoughts, opinions, or questions, I’d love to hear them. Please share your feedback on today’s newsletter by leaving a comment.