v30.0 Testing #33368

issue fanquake openend this issue on September 11, 2025
  1. fanquake commented at 4:16 pm on September 11, 2025: member

    Umbrella issue for 30.0 testing. Please help testing on a wide variety of supported platforms, as well as interaction with different software.

    Let us know which version you tested on which operating system.

    If you find an issue, please search Github for known issues first and then open a new Github issue.

    This meta issue should not be used to report bugs, as a single thread makes it impossible to track more than one topic.

    See 30.0 Release Notes Draft for a list of changes.

    See here for the testing guide: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide

  2. fanquake added this to the milestone 30.0 on Sep 11, 2025
  3. fanquake pinned this on Sep 11, 2025
  4. ellenkampguus commented at 8:24 am on September 14, 2025: none
    Maybe not the place to put this remark, but I am very concerned with the fact that the Core maintainers keep pushing through with the controversial removal of the OP_RETURN size filter. To me this change should be at least postponed. If not, I guess it can be concluded that the people controlling Bitcoin Core have been compromised in some way, which I consider a very bad thing. Bitcoin is supposed to be what Satoshi intended, no matter that some changes may be accepted by the community. But it should be supported by the far majority of the community and this OP_RETURN limit removal is definitely not supported by the vast Bitcoin community.
  5. jonasnick commented at 12:03 pm on September 14, 2025: contributor

    rc1 passes the nix-bitcoin integration test framework (except for the joinmarket tests because the latest joinmarket release requires the legacy wallet). You can run the tests with this script (requires nix).

    It seems like Cap’n Proto is a new dependency. Should it be mentioned in the release notes?

  6. 151henry151 commented at 7:41 pm on September 14, 2025: none

    v30.0rc1 Testing

    Tested on Debian 12 (bookworm) with kernel 6.1.0-37-amd64, 4-core x86_64 system. Ran through all the features from the testing guide:

    • Datacarrier size: Created a transaction with 83 bytes of data in an OP_RETURN output and successfully sent it
    • bitcoin command: Used bitcoin node to start a node and bitcoin rpc to make RPC calls - unified interface works well
    • Bumpfee: Created a transaction and successfully used bumpfee with replaceable: false
    • TRUC: Created replaceable transactions with different fee rates
    • IPC mining: Started the node with IPC enabled and confirmed the node.sock file was created
    • Coinstatsindex: Started v29.1 with coinstatsindex, then v30.0rc1, and confirmed both folders existed
  7. hMsats commented at 4:21 am on September 15, 2025: none

    Not sure if this is useful but anyway: Compiled bitcoin-30.0rc1 (it’s called v30.0.0rc1 in debug.log) with cmake on Ubuntu 24.04.3 LTS on an Acer Aspire E1-572, 64 bits, 8 GB RAM laptop with a 4 TB external ssd. All tests (test_bitcoin, test_bitcoin-qt) passed for both bitcoind and bitcoin-qt and bitcoin-qt looks fine. Upgraded bitcoind from version 29.0 to 30.0rc1. Bitcoind (30.0rc1) is working great (txindex=1) with low block verification times (about 1 second for “Saw new cmpctblock header” to “UpdateTip” (same block)) and excellent latency (18 ms) as measured by Bitnodes.

    It interacts well with the latest Core Lightning (v25.09), Electrum personal server (v0.2.4, adapted for descriptor wallets) and the Fulcrum Electrum server (v1.12.0 (edit: and the latest v2.0)). A descriptor wallet with watchonly addresses is read correctly by bitcoind and the total balance is also correct.

  8. 0xB10C commented at 10:50 am on September 15, 2025: contributor
    Running v30.0rc1 on a couple of peer.observer nodes - will report if I see something suspicious.
  9. djkazic commented at 1:19 pm on September 15, 2025: none
    Upgraded from v29.1 to v30.0rc1 on two nodes. Everything has been stable for the last 2 days.
  10. pinheadmz commented at 1:49 pm on September 15, 2025: member
    • Running 30.0rc1 on 32-bit ARM RPi with LND
    • Running 30.0rc1 on x86 Ubuntu 20 bitcoin-node with Sv2 template provider and my own idiotic block-art web stuff
    • Checked codesigned GUI on macos/ARM, will go through the testing guide
    • Will run IBD on Debian 12 VM as well with -coinstatsindex=1
  11. l0rinc commented at 7:55 pm on September 15, 2025: contributor
    I ran a full IBD for https://github.com/bitcoin/bitcoin/commit/d20f10affba83601f1855bc87d0f47e9dfd5caae using real nodes over Wi-Fi until block 914,452 with a brand new Raspberry Pi 5 (16GB RAM, 2TB SSD) - it finished successfully in 16h12m using 6GB dbcache.
  12. yuvicc commented at 8:10 am on September 16, 2025: contributor
    • I have upgraded the version of my nodes from v29.1 -> v30.0rc1, everything looks stable till now.
    • Successfully ran the testing guide on Ubuntu 24.04 and macOS 15.2.
  13. janb84 commented at 11:32 am on September 18, 2025: contributor

    Linking to #33426 (semi related to this testing) Guix build for riscv64 fails on master & 30.0rc1

    This is solved.

  14. fjahr commented at 1:21 pm on September 21, 2025: contributor
    I have done full IBD with rc1 on mainnet and signet and also synced coinstatsindex and txindex from scratch. Also did some light testing once IBD was complete. No issues so far.
  15. tnndbtc commented at 4:01 pm on September 21, 2025: none

    Tested https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/#11-datacarriersize-increase , but, it returns false instead of true after restarting bitcoind. This is on MacOS Sequoia 15.1.1, Chip: Apple M1

    Binary downloaded: https://bitcoincore.org/bin/bitcoin-core-30.0/test.rc1/bitcoin-30.0rc1-arm64-apple-darwin.tar.gz

    Steps:

    1. Modified bitcoin.conf:
    0regtest=1
    1daemon=1
    2datadir=/tmp/30-rc-test
    3
    4# Options for regtest
    5[regtest]
    6rpcport=18443
    7datacarriersize=83
    
    1. alias bcli30='/Users/user/Downloads/tmp/bitcoin-30.0rc1/bin/bitcoin-cli -conf=/Users/user/Downloads/tmp/bitcoin-30.0rc1/bitcoin.conf'

    2. start bitcoind on regtest

    0% bitcoin-30.0rc1/bin/bitcoind -conf=/Users/user/Downloads/tmp/bitcoin-30.0rc1/bitcoin.conf
    1Warning: Options '-datacarrier' or '-datacarriersize' are set but are marked as deprecated and are expected to be removed in a future version.
    2Bitcoin Core starting
    

    Not sure if this warning is expected.

    1. Then followed the testing steps:
     0% bcli30 createwallet "satoshi"   
     1
     2% bcli30 generatetoaddress 101 $(bcli30 getnewaddress)
     3
     4% coinbase_txid=$(bcli30 listunspent | jq -r ".[0].txid")
     5
     6% satoshi_address=$(bcli30 getnewaddress)
     7
     8% tx_opreturn=$(bcli30 createrawtransaction "[{\"txid\":\"$coinbase_txid\",\"vout\":0}]" \
     9    "[{\"$satoshi_address\":49.99990000},{\"data\":\"6a4d50c3ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\"}]")
    10
    11% tx_op_return_signed=$(bcli30 signrawtransactionwithwallet $tx_opreturn | jq -r .hex)
    12
    13% bcli30 testmempoolaccept "[\"$tx_op_return_signed\"]"
    14[
    15  {
    16    "txid": "e960124b180b883a6e7620b63e1f51f73ae0365e159c2a9d9f27fd9ad9845351",
    17    "wtxid": "62ed297da17d63d73e38276a92b2c9618f453de12b0fe47a6d997ec240aeda39",
    18    "allowed": false,
    19    "reject-reason": "datacarrier",
    20    "reject-details": "datacarrier"
    21  }
    22]
    23
    24% bcli30 stop
    25
    26% bitcoin-30.0rc1/bin/bitcoind -conf=/Users/user/Downloads/tmp/bitcoin-30.0rc1/bitcoin.conf
    27
    28% bcli30 testmempoolaccept "[\"$tx_op_return_signed\"]" | jq -r ".[0].allowed"
    29false
    

    Then I have restarted bitcoind multiple times and validated, it always return false

  16. janb84 commented at 5:23 pm on September 21, 2025: contributor

    Tested https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/#11-datacarriersize-increase , but, it returns false instead of true after restarting bitcoind. This is on MacOS Sequoia 15.1.1, Chip: Apple M1

    Binary downloaded: https://bitcoincore.org/bin/bitcoin-core-30.0/test.rc1/bitcoin-30.0rc1-arm64-apple-darwin.tar.gz

    Steps:

    1. Modified bitcoin.conf:
    0regtest=1
    1daemon=1
    2datadir=/tmp/30-rc-test
    
    0
    1Then I have restarted bitcoind multiple times and validated, it always return **_false_**
    

    @tnndbtc You have missed the line “Stop and restart the node with default datacarriersize” if you keep the datacarriersize on 83 the result will be false all the time. That is a expected and valid result.

  17. tnndbtc commented at 6:49 pm on September 21, 2025: none
    @janb84 Indeed, I mis-read the test step. After commenting out datacarriersize=83 and then restart the bitcoind, the test runs fine.
  18. l0rinc commented at 5:16 am on September 22, 2025: contributor

    I also just finished a full -reindex until -stopatheight=915303 compiled with AppleClang 17.0.0.17000319 against master with -assumevalid=0 (to test full script validation) and -DCMAKE_BUILD_TYPE=Debug (to test every assertion) and -DHAVE_ARM_SHANI=OFF (to test software hashing). Reindexing until block 1 took a day and reindexing the chainstate took 3 more (with default settings a reindex takes about 4-5 hours). I have cancelled it a few times, rolled the blocks forward successfully and finished reindexing, after which it synced to latest tip.

    Edit: tested -assumevalid=0 on an rpi5 as well, it finished in 65 hours

  19. monlovesmango commented at 4:06 pm on September 22, 2025: contributor

    I was doing some extra adhoc testing for section 7.1 in the testing guide and hoping for guidance on whether the result is expected or not. If I create a tx3 that is a child of tx2 (all as v3 txs) the send command fails silently. It failing is the correct behavior because the package size shouldn’t be greater than 2, but was unsure if the fail should be silent? Below will create the 3 truc transactions and check if tx3 is in mempool.

    0TRUC_address=$(bcli30 getnewaddress)
    1tx=$(bcli30 -named send outputs='{"'$TRUC_address'": 3}' fee_rate=25 version=3)
    2TRUC_address2=$(bcli30 getnewaddress)
    3tx2=$(bcli30 -named send outputs='{"'$TRUC_address2'": 0.5}' options='{"inputs":[{"txid":"'$(echo $tx|jq -r ".txid")'","vout":0}]}' fee_rate=25 version=3)
    4TRUC_address3=$(bcli30 getnewaddress)
    5tx3=$(bcli30 -named send outputs='{"'$TRUC_address3'": 0.4}' options='{"inputs":[{"txid":"'$(echo $tx2|jq -r ".txid")'","vout":0}]}' fee_rate=25 version=3)
    6bcli30 getrawtransaction  $(echo $tx3|jq -r ".txid") 1
    
  20. l3tc commented at 5:52 am on September 29, 2025: none

    RISC-V 64 / OrangePi RV2 / Ubuntu 24.04

    Completed IBD over Tor on 30.0rc1. Passed the testing guide on 30.0rc2. Pre-compiled binaries were used in both cases.

  21. Christewart commented at 8:33 pm on October 2, 2025: contributor

    One thing I noticed was the getwalletinfo RPC removed the fields balance, immature_balance, and unconfirmed_balance from the RPC result in 0ec255139be3745a135386e9db957fe81bc3d833. Is this worth a release note?

    As a side note, it seems that walletversion might be able to be removed too as the comment indicates it has been deprecated and is related to now unsupported legacy wallets?

    EDIT:

    Here is the discussion/rationale for keeping walletversion around: #32977 (review)

  22. glozow commented at 10:10 pm on October 2, 2025: member

    If I create a tx3 that is a child of tx2 (all as v3 txs) the send command fails silently.

    Thanks @monlovesmango!

    Do you see this in your debug.log?

    0CommitTransaction(): Transaction cannot be broadcast immediately, TRUC-violation, tx <tx3> would have too many ancestors
    

    If so, please see #33528

  23. fanquake commented at 1:25 pm on October 3, 2025: member

    One thing I noticed was the getwalletinfo RPC removed the fields balance, immature_balance, and unconfirmed_balance from the RPC result in https://github.com/bitcoin/bitcoin/commit/0ec255139be3745a135386e9db957fe81bc3d833. Is this worth a release note? @Christewart it was mentioned in the PR: #32721 (comment). @achow101 do you want to add one?

  24. Christewart commented at 3:42 pm on October 3, 2025: contributor

    One thing I noticed was the getwalletinfo RPC removed the fields balance, immature_balance, and unconfirmed_balance from the RPC result in 0ec2551. Is this worth a release note?

    @Christewart it was mentioned in the PR: #32721 (comment). @achow101 do you want to add one?

    I can write it if it is something that would get merged: :+1: or :-1:

  25. fanquake commented at 3:44 pm on October 3, 2025: member
  26. Christewart commented at 1:52 pm on October 4, 2025: contributor

    It seems like the RPC interface is working as expected with bitcoin-s: https://github.com/bitcoin-s/bitcoin-s/pull/6095

    The only other nit I would have is technically the watchonly json fields are deprecated this release, not removed. They will be removed in a future release.

  27. kinetickinesthetic commented at 6:05 pm on October 9, 2025: none

    This patch is a highly contentious update. I implore Core to acknowledge that the network is signaling strong resistance to the proposed changes to op_return / datacarriersize.

    We — the users and node runners — do not want the filter to be relaxed. The burden of proof is on Core developers to convince us why this change is beneficial. We understand the technical arguments better than you think. I’ve heard Core’s reasoning for the change, and I remain unconvinced. Furthermore, I will pursue other implementations to defend the network against Core’s carelessness. Find a better way to address UTXO bloat. The current proposal is dangerously risky. What happened to minimizing attack surfaces? What happened to considering second-order consequences?

    If you break with tradition and force this contentious update down our throats, your betrayal will be remembered forever.

  28. fanquake unpinned this on Oct 10, 2025
  29. fanquake commented at 6:52 am on October 10, 2025: member
    v30.0 has been tagged.
  30. fanquake closed this on Oct 10, 2025


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2025-10-10 21:13 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me