Bitcoin Forum

Bitcoin Core version 29.0 is now available from:

https://bitcoincore.org/bin/bitcoin-core-29.0/ (https://bitcoincore.org/bin/bitcoin-core-29.0/)

This release includes new features, various bug fixes and performance
improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

https://github.com/bitcoin/bitcoin/issues (https://github.com/bitcoin/bitcoin/issues)

To receive security and update notifications, please subscribe to:

https://bitcoincore.org/en/list/announcements/join/ (https://bitcoincore.org/en/list/announcements/join/)

How to Upgrade

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes in some cases), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on macOS)
or bitcoind/bitcoin-qt (on Linux).

Upgrading directly from a version of Bitcoin Core that has reached its EOL is
possible, but it might take some time if the data directory needs to be migrated. Old
wallet versions of Bitcoin Core are generally supported.

Compatibility

Bitcoin Core is supported and tested on operating systems using the
Linux Kernel 3.17+, macOS 13+, and Windows 10+. Bitcoin
Core should also work on most other Unix-like systems but is not as
frequently tested on them. It is not recommended to use Bitcoin Core on
unsupported systems.

Notable changes

P2P and Network Changes

• Support for UPnP was dropped. If you want to open a port automatically, consider using the -natpmp
  option instead, which uses PCP or NAT-PMP depending on router support. (#31130 (https://github.com/bitcoin/bitcoin/pull/31130))
  
• libnatpmp was replaced with a built-in implementation of PCP and NAT-PMP (still enabled using the -natpmp option). This supports automatic IPv4 port forwarding as well as IPv6 pinholing. (#30043 (https://github.com/bitcoin/bitcoin/pull/30043))
  
• When the -port configuration option is used, the default onion listening port will now
  be derived to be that port + 1 instead of being set to a fixed value (8334 on mainnet).
  This re-allows setups with multiple local nodes using different -port and not using -bind,
  which would lead to a startup failure in v28.0 due to a port collision.
  Note that a HiddenServicePort manually configured in torrc may need adjustment if used in
  connection with the -port option.
  For example, if you are using -port=5555 with a non-standard value and not using -bind=...=onion,
  previously Bitcoin Core would listen for incoming Tor connections on 127.0.0.1:8334.
  Now it would listen on 127.0.0.1:5556 (-port plus one). If you configured the hidden service manually
  in torrc now you have to change it from HiddenServicePort 8333 127.0.0.1:8334 to HiddenServicePort 8333 127.0.0.1:5556, or configure bitcoind with -bind=127.0.0.1:8334=onion to get the previous behavior.
  (#31223 (https://github.com/bitcoin/bitcoin/pull/31223))
  
• Upon receiving an orphan transaction (an unconfirmed transaction that spends unknown inputs), the node will attempt to download missing parents from all peers who announced the orphan. This change may increase bandwidth usage but make orphan-handling more reliable. (#31397 (https://github.com/bitcoin/bitcoin/pull/31397))
  

Mempool Policy and Mining Changes

• Ephemeral dust is a new concept that allows a single
  dust output in a transaction, provided the transaction
  is zero fee. In order to spend any unconfirmed outputs
  from this transaction, the spender must also spend
  this dust in addition to any other desired outputs.
  In other words, this type of transaction
  should be created in a transaction package where
  the dust is both created and spent simultaneously. (#30239 (https://github.com/bitcoin/bitcoin/pull/30239))
  
• Due to a bug, the default block reserved weight (4,000 WU) for fixed-size block header, transactions count, and coinbase transaction was reserved twice and could not be lowered. As a result the total reserved weight was always 8,000 WU, meaning that even when specifying a -blockmaxweight higher than the default (even to the max of 4,000,000 WU), the actual block size will never exceed 3,992,000 WU.
  The fix consolidates the reservation into a single place and introduces a new startup option, -blockreservedweight which specifies the reserved weight directly. The default value of -blockreservedweight is set to 8,000 WU to ensure backward compatibility for users who relied on the previous behavior of -blockmaxweight.
  The minimum value of -blockreservedweight is set to 2,000 WU. Users setting -blockreservedweight below the default should ensure that the total weight of their block header, transaction count, and coinbase transaction does not exceed the reduced value or they may risk mining an invalid block. (#31384 (https://github.com/bitcoin/bitcoin/pull/31384))
  

Updated RPCs

• The RPC testmempoolaccept response now includes a reject-details field in some cases,
  similar to the complete error messages returned by sendrawtransaction (#28121 (https://github.com/bitcoin/bitcoin/pull/28121))
  
• Duplicate blocks submitted with submitblock will now persist their block data
  even if it was previously pruned. If pruning is activated, the data will be
  pruned again eventually once the block file it is persisted in is selected for
  pruning. This is consistent with the behaviour of getblockfrompeer where the
  block is persisted as well even when pruning. (#31175 (https://github.com/bitcoin/bitcoin/pull/31175))
  
• getmininginfo now returns nBits and the current target in the target field. It also returns a next object which specifies the height, nBits, difficulty, and target for the next block. (#31583 (https://github.com/bitcoin/bitcoin/pull/31583))
  
• getblock and getblockheader now return the current target in the target field (#31583 (https://github.com/bitcoin/bitcoin/pull/31583))
  
• getblockchaininfo and getchainstates now return nBits and the current target in the target field (#31583 (https://github.com/bitcoin/bitcoin/pull/31583))
  
• the getblocktemplate RPC curtime (BIP22) and mintime (BIP23) fields now
  account for the timewarp fix proposed in BIP94 on all networks. This ensures
  that, in the event a timewarp fix softfork activates on mainnet, un-upgraded
  miners will not accidentally violate the timewarp rule. (#31376 (https://github.com/bitcoin/bitcoin/pull/31376), #31600 (https://github.com/bitcoin/bitcoin/pull/31600))
  As a reminder, it's important that any software which uses the getblocktemplate
  RPC takes these values into account (either curtime or mintime is fine).
  Relying only on a clock can lead to invalid blocks under some circumstances,
  especially once a timewarp fix is deployed. (#31600 (https://github.com/bitcoin/bitcoin/pull/31600))
  

New RPCs

• getdescriptoractivity can be used to find all spend/receive activity relevant to
  a given set of descriptors within a set of specified blocks. This call can be used with
  scanblocks to lessen the need for additional indexing programs. (#30708 (https://github.com/bitcoin/bitcoin/pull/30708))

Updated REST APIs

• GET /rest/block/<BLOCK-HASH>.json and GET /rest/headers/<BLOCK-HASH>.json now return the current target in the target field

Updated Settings

• The maximum allowed value for the -dbcache configuration option has been
  dropped due to recent UTXO set growth. Note that before this change, large -dbcache
  values were automatically reduced to 16 GiB (1 GiB on 32 bit systems). (#28358 (https://github.com/bitcoin/bitcoin/pull/28358))
  
• Handling of negated -noseednode, -nobind, -nowhitebind, -norpcbind, -norpcallowip, -norpcwhitelist, -notest, -noasmap, -norpcwallet, -noonlynet, and -noexternalip options has changed. Previously negating these options had various confusing and undocumented side effects. Now negating them just resets the settings and restores default behaviors, as if the options were not specified.
  
• Starting with v28.0, the -mempoolfullrbf startup option was set to
  default to 1. With widespread adoption of this policy, users no longer
  benefit from disabling it, so the option has been removed, making full
  replace-by-fee the standard behavior. (#30592 (https://github.com/bitcoin/bitcoin/pull/30592))
  
• Setting -upnp will now log a warning and be interpreted as -natpmp. Consider using -natpmp directly instead. (#31130 (https://github.com/bitcoin/bitcoin/pull/31130), #31916 (https://github.com/bitcoin/bitcoin/pull/31916))
  
• As a safety check, Bitcoin core will <strong>fail to start</strong> when -blockreservedweight init parameter value is lower than 2000 weight units. Bitcoin Core will also <strong>fail to start</strong> if the -blockmaxweight or -blockreservedweight init parameter exceeds consensus limit of 4,000,000 WU.
  
• Passing -debug=0 or -debug=none now behaves like -nodebug: previously set debug categories will be cleared, but subsequent -debug options will still be applied.
  
• The default for -rpcthreads has been changed from 4 to 16, and the default for -rpcworkqueue has been changed from 16 to 64. (#31215 (https://github.com/bitcoin/bitcoin/pull/31215)).
  

Build System

The build system has been migrated from Autotools to CMake:

• The minimum required CMake version is 3.22.
• In-source builds are not allowed. When using a subdirectory within the root source tree as a build directory, it is recommended that its name includes the substring "build".
• CMake variables may be used to configure the build system. <strong>Some defaults have changed.</strong> For example, you will now need to add -DWITH_ZMQ=ON to build with zmq and -DBUILD_GUI=ON to build bitcoin-qt. See Autotools to CMake Options Mapping (https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Autotools-to-CMake-Options-Mapping) for details.
• For single-configuration generators, the default build configuration (CMAKE_BUILD_TYPE) is "RelWithDebInfo". However, for the "Release" configuration, CMake defaults to the compiler optimization flag -O3, which has not been extensively tested with Bitcoin Core. Therefore, the build system replaces it with -O2.
• By default, the built executables and libraries are located in the bin/ and lib/ subdirectories of the build directory.
• The build system supports component‐based installation. The names of the installable components coincide with the build target names. For example:

• If any of the CPPFLAGS, CFLAGS, CXXFLAGS or LDFLAGS environment variables were used in your Autotools-based build process, you should instead use the corresponding CMake variables (APPEND_CPPFLAGS, APPEND_CFLAGS, APPEND_CXXFLAGS and APPEND_LDFLAGS). Alternatively, if you opt to use the dedicated CMAKE_<...>_FLAGS variables, you must ensure that the resulting compiler or linker invocations are as expected.

For more detailed guidance on configuring and using CMake, please refer to the official CMake documentation (https://cmake.org/cmake/help/latest/) and CMake’s User Interaction Guide (https://cmake.org/cmake/help/latest/guide/user-interaction/index.html). Additionally, consult platform-specific doc/build-*.md build guides for instructions tailored to your operating system.

Low-Level Changes

Tools and Utilities

• A new tool utxo_to_sqlite.py (https://github.com/bitcoin/bitcoin/blob/v29.0/contrib/utxo-tools/utxo_to_sqlite.py)
  converts a compact-serialized UTXO snapshot (as created with the
  dumptxoutset RPC) to a SQLite3 database. Refer to the script's --help
  output for more details. (#27432 (https://github.com/bitcoin/bitcoin/pull/27432))

Tests

• The BIP94 timewarp attack mitigation (designed for testnet4) is no longer active on the regtest network. (#31156 (https://github.com/bitcoin/bitcoin/pull/31156))

Dependencies

• MiniUPnPc and libnatpmp have been removed as dependencies (#31130 (https://github.com/bitcoin/bitcoin/pull/31130), #30043 (https://github.com/bitcoin/bitcoin/pull/30043)).

Credits

Thanks to everyone who directly contributed to this release:

• 0xb10c
• Adlai Chandrasekhar
• Afanti
• Alfonso Roman Zubeldia
• am-sq
• Andre
• Andre Alves
• Anthony Towns
• Antoine Poinsot
• Ash Manning
• Ava Chow
• Boris Nagaev
• Brandon Odiwuor
• brunoerg
• Chris Stewart
• Cory Fields
• costcould
• Daniel Pfeifer
• Daniela Brozzoni
• David Gumberg
• dergoegge
• epysqyli
• espi3
• Eval EXEC
• Fabian Jahr
• fanquake
• furszy
• Gabriele Bocchi
• glozow
• Greg Sanders
• Gutflo
• Hennadii Stepanov
• Hodlinator
• i-am-yuvi
• ion-
• ismaelsadeeq
• Jadi
• James O'Beirne
• Jeremy Rand
• Jon Atack
• jurraca
• Kay
• kevkevinpal
• l0rinc
• laanwj
• Larry Ruane
• Lőrinc
• Maciej S. Szmigiero
• Mackain
• MarcoFalke
• marcofleon
• Marnix
• Martin Leitner-Ankerl
• Martin Saposnic
• Martin Zumsande
• Matthew Zipkin
• Max Edwards
• Michael Dietz
• naiyoma
• Nicola Leonardo Susca
• omahs
• pablomartin4btc
• Pieter Wuille
• Randall Naar
• RiceChuan
• rkrux
• Roman Zeyde
• Ryan Ofsky
• Sebastian Falbesoner
• secp512k2
• Sergi Delgado Segura
• Simon
• Sjors Provoost
• stickies-v
• Suhas Daftuar
• tdb3
• TheCharlatan
• tianzedavid
• Torkel Rogstad
• Vasil Dimov
• wgyt
• willcl-ark
• yancy

As well as to everyone that helped with translations on
Transifex (https://www.transifex.com/bitcoin/bitcoin/).

Please, can anybody help me to open port for incoming connections with this  version 29.0??
What on earth  have they done with this new version that neither GUI setting for pcp or nat-pmp , nor natpmp=1 option in bitcoin.conf do NOT WORK any more??

It is definitely worth noting that the old autogen.sh build method is not supported - as noted above. 

You might also need to install libsqlite3-dev   

For ubuntu (and Debian most likely) it is easy:
sudo apt-get install libsqlite3-dev

UPnP support was removed (it was previously disabled by default) due to continuous issues with the miniupnp library.

If the automatic port forwarding protocols are not working, it is highly likely that the issue is that your router does not support them and you will have to port forward manually.

Please open a new topic in Technical Support so that your issue can be troubleshooted. You can start Bitcoin Core with the -debug=net option and find and post any lines beginning with pcp: or natpmp:. This will tell us what that module is doing, and should inform us of the issue.

Achow101, thank you very much for the answer. I can neither change my router, nor open incoming port manually with port forwarding (my router was given by my internet provider). So, I have downgraded back to the 28.1 version which opens the port fine.

Would you be willing to share what ISP you have, and the brand and model of the router? We are interested in gathering information on router compatibility for this change.

Would you be willing to share what ISP you have, and the brand and model of the router? We are interested in gathering information on router compatibility for this change.
[/quote]

Sure. My ISP is https://beltelecom.by/en/about.
My router's brand is labeled as JSC "PROMSVYAZ" . I guess that is a clone of some Chinese brand.
The model is labeled as MT-PON-AT-4 (i.e. a PON, Passive optical network type).
As i guess it supports UPnP and manual port forwarding only. I cannot use the manual forwarding because the router asks dor password i don't know and i don't like resetting its settings to defaults.
So, since v.29.0 has dropped UPnP support (as i now understand it) my BTC Core application was unable to accept incming connections any more. But that is the most important feature for me, as i consider supporting the great BTC network as an exclusively important goal.

While accepting incoming connections is definitely more helpful, not accepting incoming connections still supports the Bitcoin network. You still be receive and validate all blocks and transactions, and forward the valid ones to your other peers. The terms "incoming" and "outbound" only really refer to which node initiated connection, they are other approximately identical as data goes in both directions.

Achow101, thank you very much for your very valuable explanations on the topic!
My main goal in running Bitcoin Core full node is to help and support as much as I can the wonderful great Bitcoin network and community. It is great that even without accepting incoming connections one can still support the network!
Yet, personally, I have a pretty fast wide Internet channel and 24/7 server which I would very much like to do the maximum benefit for the Bitcoin network.
So, I prefer to stay with 28.1 version for now.
Maybe in the next versions the Bitcoin Core developers will find a solution to return the UPnP functionality (without issues).
Then I'll immediately upgrade to that new version.

It would still be useful to have this information to be sure it’s not an issue at the OS level or an implementation bug. Also add the lines with portmap:.
(feel free to DM it as it may include privacy sensitive information)

Another option, that always works, would be to accept incoming connections on Tor through an onion service, this works even if no port forwarding can be set up at the TCP level.

Wumpus, I'll try to post the debug information some later maybe.   Because, you know, these days i have big trouble with my Bitcoin node not only with the new 29.0 version. A couple of days ago i replugged my hard disk from one sata port (on the motherboard) to another.
And suddenly, my fully synchronized bitcoin core node said it could not load the blockchain database or broken indexrx or something like that (i don't remember now).
Whatever i did (check the drive for errors , etc) the node rejected my local database and started to download the full database since the very 2009 year.
And untill now , it has still been synchronizing.
It is now in 2024 year only.
So, i'm a little bit tired of all thus bustle with my node. By the way, it had been working fine for 2 years approximately without any issues.
Maybe later I'll install the 29.0 version and provide the necessary debug info here.

Is there any specific reason why this topic is not pinned after 2 weeks of its posting? Is there a policy of delay or something?

I still see 28 as pinned https://bitcointalk.org/index.php?topic=5512015.0

Usually these errors are hardware related. I wouldn't recommend running it on a HDD anymore. In the past I had issues occasionally, but on SSDs never.

Yep, ran into that too. autogen.sh is gone, and libsqlite3-dev is definitely needed now—build failed without it on my Ubuntu setup.

This appears to be the last legit version of Bitcoin Core before the spam filters are forcefully removed without community consensus.

If you don't want shitcoin lite running on your node I suggest not updating to any version beyond 29.0, or switch to Knots.

headingnorth , would you please tell us more?? What "spam filters" , what are you talking about? Personally, I've heard nothing about it.

They're referring to ongoing drama about OP_RETURN limits. See https://bitcointalk.org/index.php?topic=5539943.0

No PR removing those limits has been merged at this time, to say that they are being forcefully removed is simply hyperbole.

Thank you, I'll read the topic.
Just curious, does Bitcoin Knots still fully support UPnP? And will it be able to accept my fully synced BTC database from Bitcoin Core or will it begin syncing the database from the very 2009 again if I install it?

There's a big debate about it in Technical Discussion as achow101 mentioned.
Some short videos from Matthew Kratter to get you up to speed on the matter more quickly:

Bitcoin Core Going Rogue?
Bitcoin Core Attacking Bitcoin?
Does Bitcoin Spam Exist?
Satoshi's Secret Cure for Spam
Bitcoin Core Removes the Mask

www.youtube.com/@Bitcoin_University/videos


I hope achow101 is right and it won't happen but according to Matt Kratter (Bitcoin Core Removes the Mask)
the announcement was made a couple days ago by the devs and the PR will be merged. We will see.

But if true then there is no doubt Core has been compromised and must be rejected by all node operators IMO.

Thank you, in my opinion, this is a very important topic.
I will try to get to know this topic better, thank you

Makes sense—glad 28.1 still works for your setup. Hopefully future versions improve port handling.

From discussions I have read elsewhere, none of the videos he has posted are actually accurate and supposedly he is significantly overexaggerating/being hyperbolic. I cannot attest this as I have not watched them myself.

There is no such announcement that anything will happen. I would happen to know, as I am one of the maintainers.

The document that was published a few days ago was a draft of one that had intended to be "official" from the project, but it did not have enough agreement amongst contributors to adopt it as such. The author then published the draft. It is neither an announcement nor the project's "official" stance on the topic.

---

Regardless, continued discussion of OP_RETURN limits is off topic for this thread and I will be removing any further posts on the subject. Go to the myriad of other threads/forums where this is being discussed.

Thank you for the info. It is a relief to hear that. I am hearing a lot of conflicting information right now.
Some articles came out yesterday claiming otherwise so I don't know what to believe.

Bitcoin Developers Plan OP_RETURN Limit Removal in Next Release
https://finance.yahoo.com/news/bitcoin-developers-plan-op-return-062522161.html

Bitcoin Core to unilaterally remove controversial OP-Return limit
https://cointelegraph.com/news/bitcoin-core-unilaterally-remove-controversial-op-return-limit

It appears they are using dev comments on Github as their source but that is not an official announcement.
I guess the only way to know for sure is when the next release of Core comes out.

You can follow the discussion on the pull request but also in the email lists. That is much better than reading articles by under qualified writers that are posing as Bitcoin journalists.

How come the latest version still won't support seed phrases?

Well, my Bitcoin core was corrupted for some reason, and I had to uninstall it. I don't remember if there is an option to recover or create a new wallet with seed phrases. I assume most people on the internet do not use Bitcoin Core as a wallet. They just run the Bitcoin core to help the network. For wallet purposes, it is recommended to use Electrum.

There might be other software wallets with better services, but I find Electrum easy to use and safe, and I have been using it for a couple of years now.

According to ChatGPT

Anything about addressing the migration for countering quantum computer? Are we waiting 2030?

No. For that you need to follow the BIP repository and the developer mailing list. Quantum resistance research is still in progress and it is unlikely that an implementation will be available or merged very soon.

Excuse my ignorance, what is the BIP about quantum research? And how can I stay up to date on this topic?

There is only a draft BIP with the tentative number 360. I had opened a thread about that discussion (https://bitcointalk.org/index.php?topic=5546090.0).

It's however unlikely the BIP will be implemented soon. The problem is that the developers don't consider the current post quantum algorithms to be mature enough, and for example @achow101 (a Bitcoin developer) has stated in that thread that he'd prefer to choose a single, battle-tested algorithm, instead of letting the users decide which algorithm to use (that can be dangerous because many users have no idea about the safety of the different algorithms and their particular challenges and potential vulnerabilities).

I personally think that it is reasonable to wait a couple of years more, because quantum computers with hundreds of thousands of logical qubits would be needed to crack a Bitcoin key in several years, and millions if it should happen in a few days. That's imo at least a decade, if not a century away. (And afaik you can't just connect several 1000-qubit-machines to create a million-qubit supercomputer.) And until quantum computers can crack keys in a few minutes, there is a simple strategy to make coins "almost" quantum safe: don't re-use your addresses, and thus no public key is exposed.

The best way to stay up to date about development issues is to follow the Bitcoin-dev mailing list (https://groups.google.com/g/bitcoindev/). There was a quite long discussion about the proposed BIP360 (https://groups.google.com/g/bitcoindev/c/oQKezDOc4us).

The NIST have already released quantum-resistant replacements for the SHA-256 and EDCSA encryption used by bitcoin.
They are called FIPS 203, 204, 205. NIST is the US federal agency that originally created SHA and EDCSA encryption methods.

NIST Releases First 3 Finalized Post-Quantum Encryption Standards (https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards)

• NIST has released a final set of encryption tools designed to withstand the attack of a quantum computer.
• These post-quantum encryption standards secure a wide range of electronic information, from confidential
email messages to e-commerce transactions that propel the modern economy.
• NIST is encouraging computer system administrators to begin transitioning to the new standards as soon as possible.


The question is, if and when the devs will start implementing them into bitcoin?

The general view is that this field is still in its emergence and that more changes will come. Bitcoin is not the kind of technology that allows for making fatal errors with minimal consequences. The consequences of adopting the wrong algorithm could be devastating. Keep in mind that knowledge in this field is still lacking, i.e., there are too many unknowns. What seems secure today could become insecure tomorrow as quantum computers actually start getting used and we discover new ways of attacking encryption and hashes. Anyhow, some of these algorithms may be rejected for different reasons here but they may be useful somewhere else. Decentralized systems have different limitations and restrictions than centralized systems.  

Furthermore, Bitcoin is generally a very slow mover. I'd expect at least a few more years to pass before we start considering some "final candidates" for our replacements. Note that I am talking about final candidates for Bitcoin, not final candidates as given by NIST. Unless something forces us to act faster.

That makes sense. One of the questions concerning the process of future-proofing bitcoin
to me would be how to protect legacy addresses from a quantum attack, addresses where
the private keys may have been permanently lost.

Potential solutions:

1. Provide plenty of warning and time for people to move their bitcoin before permanently
"locking" legacy addresses. Of course, doing that would be highly controversial.

2. Do the above, but provide a means for the owner of a locked legacy address to prove
ownership by "signing" the bitcoin and restoring their access. I have no idea if that would even be possible.

3. Something else

If you want to seriously discuss this, it would be better to open a new topic in Development & Technical Discussion (https://bitcointalk.org/index.php?board=6.0) as it would be off topic to continue this here. I've seen pieces of this discussion in many threads though.

Thanks I'll start another thread later.

The release notes for all Bitcoin Core versions up to and including version 28.2 say it's "supported and extensively tested" on Windows 7 and newer (or something to that effect).  But I notice in the release notes for version 29 that statement has now changed to "Windows 10+".

Can someone confirm Windows 7 support was quietly dropped?  I tried googling, but can't find any discussion about that or any explicit statements to that effect.

I'm interested in the backstory behind this change in the release notes.  Was that edit intentional?  Was there any discussion behind it among devs?  Have there been any specific codechanges introduced which are known to break on the older OS?  Was there a team member who did testing on Win 7 who left or no longer has access to that hardware?  Has it already not been tested on that OS for a long time and the team just decided now to adjust the release notes to reflect that?

I recognize Microsoft dropped Win 7 support a long time ago.  I understand there are security implications to running it.  I know most of the rest of the industry has moved on and the corpus of software titles that run on it is thinning.  And I acknowledge dropping support at this stage wouldn't be unreasonable.  All that said, I always felt it somewhat a badge of honor and testament to permanence that Bitcoin in particular maintained support for such an "OG" OS.

I'm not interested in arguing merits of the OS here, just genuinely curious about the change and discussion or consensus leading to it.

Also, is there a reason the bitcoincore.org landing page still doesn't mention version 29 at https://bitcoincore.org/, and that bitcoin.org still links to 28.1 e.g. at https://bitcoin.org/en/bitcoin-core/?  Is 29 still considered very-new/upgrade-cautiously?

Yes. https://github.com/bitcoin/bitcoin/pull/31172

It does. The downloads page always has the latest major version. The website front page with latest posts will have earlier posts (e.g. announcing new versions) moved down, and eventually off the page. Since 29.0 was released, there have been 3 posts so it is no longer at the top.

We have no control over bitcoin.org. The owner of that website updates everything whenever they feel like/get around to it, and it is often outdated.

No

Since Bitcoin Core 29.0 removed UPnP, do developers plan to introduce an alternative that is easier to use than manual port forwarding?

How much does enabling an onion service on Tor affect the performance or latency of Bitcoin Core network connections?

Is there any chance that a future version will bring back UPnP support, or will a safer alternative be introduced instead?

For users who encounter blockchain database corruption like Bestcoin-fan, is there any way to repair or recover the data without having to resync from 2009?

Why doesn’t Bitcoin Core support seed phrases in the same way as Electrum, even though most users are more familiar with that system?

Regarding quantum resistance: does Bitcoin Core have any plans to begin testing or experimenting with NIST’s post-quantum algorithms on testnet or in an experimental branch?

The alternative has already been chosen, PCP with NAT-PMP as fallback.

Not any worse than general use of TOR. If you get bad relays occasionally it can slow down, otherwise it works good.

They have already been introduced, here is the context of PCP and NAT-PMP.  https://github.com/bitcoin/bitcoin/pull/31130. Much better and safer than UPnP.

No, usually reindex is the way to go. You are not supposed to encounter a corruption, if it happens frequently then you are doing something wrong (e.g., running Bitcoin Core on an USB connected HDD with an unstable connection).

Here is your answer.

AFAIK no plans yet.