v23.0 testing #24501

issue laanwj openend this issue on March 8, 2022
  1. laanwj commented at 11:01 am on March 8, 2022: member

    Umbrella issue for 23.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.

    What to test

    For an idea what to test, see @stickies-v’s 23.0 release candidate testing guide, or

    Known issues (as of rc5)

    Other known issues:

    • MacOS: SHA256 acceleration is not enabled on MacOS 11.x due to missing reporting of sysctl hw.optional.arm.*. Please upgrade to MacOS 12.x if this is important to you.

    Known issues fixed (as of rc5)

    • Due to a naming conflict after adding support for the new MacOS architecture, we had to rename the following dmgs manually from bitcoin-23.0rc2-osx-signed.dmg during upload:
    0bitcoin-23.0rc2-arm64-apple-darwin.dmg
    1bitcoin-23.0rc2-x86_64-apple-darwin.dmg
    

    This may cause issues during verification because in the SHA256SUMS.asc they still have the old name.

    • MacOS: please postpone the Monterey 12.3.1 update until 23.0rc4 to test whether #23134 has been really fixed (it’s really fixed, see #24501 (comment))
    • #24726 bitcoind/-qt may silently fail on Windows when using AVX2 SHA256 implementation
    • bitcoin-core/gui#571~
    • Windows GUI crashes while rendering bandwidth graph: bitcoin-core/gui#582
  2. laanwj added the label Tests on Mar 8, 2022
  3. laanwj added this to the milestone 23.0 on Mar 8, 2022
  4. laanwj pinned this on Mar 8, 2022
  5. gruve-p commented at 6:41 pm on March 8, 2022: contributor

    Signet miner no longer runs for me on a custom signet.

     0error code: -22
     1error message:
     2Specified sighash value does not match value stored in PSBT
     3Traceback (most recent call last):
     4  File "contrib/signet/miner", line 628, in <module>
     5    main()
     6  File "contrib/signet/miner", line 622, in main
     7    return args.fn(args)
     8  File "contrib/signet/miner", line 496, in do_generate
     9    psbt_signed = json.loads(args.bcli("-stdin", "walletprocesspsbt", input=psbt.encode('utf8')))
    10  File "contrib/signet/miner", line 603, in <lambda>
    11    args.bcli = lambda *a, input=b"", **kwargs: bitcoin_cli(args.cli.split(" "), list(a), input=input, **kwargs)
    12  File "contrib/signet/miner", line 559, in bitcoin_cli
    13    out = subprocess.run(cmd, stdout=subprocess.PIPE, **kwargs, check=True).stdout
    14  File "/usr/lib/python3.6/subprocess.py", line 438, in run
    15    output=stdout, stderr=stderr)
    16subprocess.CalledProcessError: Command '['bitcoin-cli', '-signet', '-stdin', 'walletprocesspsbt']' returned non-zero exit status 22
    

    When reverting PR: #22514 it works again

  6. Rspigler commented at 5:30 am on March 10, 2022: contributor

    Compiled v23.0rc1 with default config settings in Qubes 4.0 in a Debian-11 VM with standard networking.

    Passed all functional, util, and unit tests.

  7. Ziqhoulets commented at 2:40 am on March 11, 2022: none
    #22514 config. Compiled v23.0
  8. hebasto commented at 8:32 am on March 13, 2022: member

    v23.0rc2 on Windows 11:

    doc_2022-03-13_09-26-20

    Do we really want to make a release in March with a certificate which is valid until May only? Maybe update it?

    See:

    • bitcoin-core/gui#252
    • bitcoin/bitcoin#22017

    cc @achow101

  9. achow101 commented at 9:25 am on March 13, 2022: member
    @hebasto As long as the key is not revoked, there won’t be any issues with the installer after it expires. Those previous issues were because the key was revoked.
  10. hebasto commented at 11:40 am on March 13, 2022: member

    v23.0rc2 on macOS Monterey x86_64:

    0% shasum -a 256 bitcoin-23.0rc2-osx-signed.dmg 
    18603b36da9eae23880839c1ec95c5bfb51dbec7c253095c122e3896458e78107  bitcoin-23.0rc2-osx-signed.dmg
    2% codesign -vvv --deep --strict bitcoin-23.0rc2-osx-signed.dmg 
    3bitcoin-23.0rc2-osx-signed.dmg: code object is not signed at all
    

    cc @achow101 @fanquake

  11. achow101 commented at 11:47 am on March 13, 2022: member
    The dmg needs to be unpacked. The application bundle contained inside the dmg is signed, not the dmg itself.
  12. hebasto commented at 12:02 pm on March 13, 2022: member

    The dmg needs to be unpacked. The application bundle contained inside the dmg is signed, not the dmg itself.

    You’re right:

    0% codesign -vvv --deep --strict /Applications/Bitcoin-Qt.app  
    1/Applications/Bitcoin-Qt.app: valid on disk
    2/Applications/Bitcoin-Qt.app: satisfies its Designated Requirement
    
  13. jessebarton commented at 4:40 am on March 16, 2022: contributor
    Compiled v23.0rc1 FreeBSD 13.0-RELEASE Passed all tests.
  14. MarcoFalke referenced this in commit 74f8c551e9 on Mar 17, 2022
  15. sidhujag referenced this in commit 79173fc631 on Mar 18, 2022
  16. hebasto commented at 6:44 pm on March 22, 2022: member
    Cross-posting a bug in the GUI: bitcoin-core/gui/issues/567.
  17. Rspigler commented at 1:07 am on March 23, 2022: contributor
    I was able to fully resync the chain without issue
  18. hebasto commented at 8:13 am on March 23, 2022: member

    Cross-posting a bug in the GUI: bitcoin-core/gui/issues/567.

    A fix has been suggested in #24648 bitcoin-core/gui#568.

  19. tylerchambers commented at 2:02 am on March 25, 2022: contributor
    Downloaded and syncing w/ GUI on macOS 12.3 M1 with no problems so far. Great stuff!
  20. Ziqhoulets commented at 2:10 am on March 25, 2022: none
    👍😉👍😎👍😊👍🤩👍😘👍 Good luck everyone And congratulations to all stuff.. Good work..!!
  21. 0xB10C commented at 12:38 pm on March 26, 2022: contributor

    Tested the tracepoints in v23rc2 with the tests from #24358.

    0TEST                         | STATUS    | DURATION
    1
    2interface_usdt_net.py        | ✓ Passed  | 2 s
    3interface_usdt_utxocache.py  | ✓ Passed  | 4 s
    4interface_usdt_validation.py | ✓ Passed  | 1 s
    5
    6ALL                          | ✓ Passed  | 7 s (accumulated)
    7Runtime: 4 s
    
  22. hebasto commented at 5:28 pm on March 26, 2022: member

    Tested https://bitcoincore.org/bin/bitcoin-core-23.0/test.rc2/bitcoin-23.0rc2-win64.zip on Windows 11 Pro 21H2.

    bitcoind.exe -signet silently fails:

     0>bitcoind.exe -signet
     12022-03-26T17:24:10Z Bitcoin Core version v23.0.0rc2 (release build)
     22022-03-26T17:24:10Z Signet derived magic (message start): 0a03cf40
     32022-03-26T17:24:10Z Assuming ancestors of block 00000112852484b5fe3451572368f93cfd2723279af3464e478aee35115256ef have valid signatures.
     42022-03-26T17:24:10Z Setting nMinimumChainWork=000000000000000000000000000000000000000000000000000000de26b0e471
     52022-03-26T17:24:10Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
     62022-03-26T17:24:10Z Using RdSeed as additional entropy source
     72022-03-26T17:24:10Z Using RdRand as an additional entropy source
     82022-03-26T17:24:10Z Default data directory C:\Users\hebasto\AppData\Roaming\Bitcoin
     92022-03-26T17:24:10Z Using data directory C:\Users\hebasto\AppData\Roaming\Bitcoin\signet
    102022-03-26T17:24:10Z Config file: C:\Users\hebasto\AppData\Roaming\Bitcoin\bitcoin.conf
    112022-03-26T17:24:10Z Command-line arg: signet=""
    122022-03-26T17:24:10Z Using at most 125 automatic connections (2048 file descriptors available)
    132022-03-26T17:24:10Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
    142022-03-26T17:24:10Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
    152022-03-26T17:24:10Z Script verification uses 3 additional threads
    162022-03-26T17:24:10Z scheduler thread start
    172022-03-26T17:24:10Z HTTP: creating work queue of depth 16
    182022-03-26T17:24:10Z Using random cookie authentication.
    192022-03-26T17:24:10Z Generated RPC authentication cookie C:\Users\hebasto\AppData\Roaming\Bitcoin\signet\.cookie
    202022-03-26T17:24:10Z HTTP: starting 4 worker threads
    212022-03-26T17:24:10Z Using wallet directory C:\Users\hebasto\AppData\Roaming\Bitcoin\signet\wallets
    222022-03-26T17:24:10Z init message: Verifying wallet(s)…
    232022-03-26T17:24:10Z Using /16 prefix for IP bucketing
    242022-03-26T17:24:10Z init message: Loading P2P addresses…
    252022-03-26T17:24:10Z Loaded 281 addresses from peers.dat  3ms
    262022-03-26T17:24:10Z init message: Loading banlist…
    272022-03-26T17:24:10Z SetNetworkActive: true
    282022-03-26T17:24:10Z Cache configuration:
    292022-03-26T17:24:10Z * Using 2.0 MiB for block index database
    302022-03-26T17:24:10Z * Using 8.0 MiB for chain state database
    312022-03-26T17:24:10Z * Using 440.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
    322022-03-26T17:24:10Z init message: Loading block index…
    332022-03-26T17:24:10Z Switching active chainstate to Chainstate [ibd] @ height -1 (null)
    342022-03-26T17:24:10Z Opening LevelDB in C:\Users\hebasto\AppData\Roaming\Bitcoin\signet\blocks\index
    352022-03-26T17:24:10Z Opened LevelDB successfully
    362022-03-26T17:24:10Z Using obfuscation key for C:\Users\hebasto\AppData\Roaming\Bitcoin\signet\blocks\index: 0000000000000000
    372022-03-26T17:24:10Z LoadBlockIndexDB: last block file = 2
    382022-03-26T17:24:10Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=7157, size=116740534, heights=75849...83025, time=2022-02-03...2022-03-25)
    392022-03-26T17:24:10Z Checking all blk files are present...
    402022-03-26T17:24:10Z Opening LevelDB in C:\Users\hebasto\AppData\Roaming\Bitcoin\signet\chainstate
    412022-03-26T17:24:10Z Opened LevelDB successfully
    422022-03-26T17:24:10Z Using obfuscation key for C:\Users\hebasto\AppData\Roaming\Bitcoin\signet\chainstate: d86c5148093b888d
    432022-03-26T17:24:10Z Loaded best chain: hashBestChain=000000af126e5012ccc04cd73228deba508a60673641ec1baa412386fdfe10aa height=83025 date=2022-03-25T16:34:08Z progress=0.991581
    442022-03-26T17:24:10Z init message: Verifying blocks…
    452022-03-26T17:24:10Z Verifying last 6 blocks at level 3
    462022-03-26T17:24:10Z [0%]...
    
  23. kibnakamoto commented at 8:34 pm on March 27, 2022: none

    compiled without errors but got countless warnings (hundreds) on C++17 Mac OS X. these are a few warnings out of Hundreds:

     0/usr/local/include/boost/signals2/connection.hpp:80:22: note: overridden virtual function is here
     1        virtual bool connected() const = 0;
     2                     ^
     3/usr/local/include/boost/signals2/connection.hpp:195:22: warning: 'lock' overrides a member function but is not marked 'override' [-Wsuggest-override]
     4        virtual void lock()
     5                     ^
     6/usr/local/include/boost/signals2/connection.hpp:102:22: note: overridden virtual function is here
     7        virtual void lock() = 0;
     8                     ^
     9/usr/local/include/boost/signals2/connection.hpp:199:22: warning: 'unlock' overrides a member function but is not marked 'override' [-Wsuggest-override]
    10        virtual void unlock()
    11                     ^
    12/usr/local/include/boost/signals2/connection.hpp:103:22: note: overridden virtual function is here
    13        virtual void unlock() = 0;
    14                     ^
    15/usr/local/include/boost/signals2/connection.hpp:212:34: warning: 'release_slot' overrides a member function but is not marked 'override' [-Wsuggest-override]
    16        virtual shared_ptr<void> release_slot() const
    17                                 ^
    18/usr/local/include/boost/signals2/connection.hpp:132:34: note: overridden virtual function is here
    19        virtual shared_ptr<void> release_slot() const = 0;
    20                                 ^
    2131 warnings generated.
    

    all the warnings are related to either the use of macros or overriding. also got a lot of notes.

    All the tests passed:

     0PASS: minisketch/test
     1PASS: univalue/test/object
     2PASS: univalue/test/unitester
     3PASS: univalue/test/no_nul
     4PASS: qt/test/test_bitcoin-qt
     5============================================================================
     6Testsuite summary for Bitcoin Core 23.99.0
     7============================================================================
     8# TOTAL: 5
     9# PASS:  5
    10# SKIP:  0
    11# XFAIL: 0
    12# FAIL:  0
    13# XPASS: 0
    14# ERROR: 0
    15============================================================================
    

    The make deploy also works after command pip3 install ds_store.

  24. hebasto commented at 9:07 pm on March 27, 2022: member

    @kibnakamoto

    You can use the --enable-suppress-external-warnings option when configuring your build.

  25. jonatack commented at 9:42 am on March 28, 2022: contributor

    You can use the –enable-suppress-external-warnings option when configuring your build.

    Updated https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests to add the --enable-suppress-external-warnings flag by default (https://github.com/jonatack/jonatack.github.io/commit/e8f4c2b11ed8c6fa8791d6cdec1ed464abb66b79). I use this flag by default since it was added.

  26. hebasto commented at 10:21 am on March 28, 2022: member

    I use this flag by default since it was added.

    #22041 :)

  27. stickies-v commented at 2:49 pm on March 28, 2022: contributor

    The testing guide is now available on https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Candidate-Testing-Guide , @laanwj could you please add that link to OP?

    If anyone has any feedback or suggested changes re the guide, please let me know!

  28. eriknylund commented at 3:51 pm on March 28, 2022: contributor

    How come there is no option to receive to Bech32m (Taproot) address type when the wallet is encrypted? 🤔

    This is when I create a wallet that’s not encrypted: image This is when I create one that is encrypted: image

    Setup:

    • Apple M1 MacBook Pro (13-inch, M1, 2020)
    • macOS Big Sur 11.6.4 (20G417)
    • 23.0rc2-arm64 binary
  29. eriknylund commented at 6:42 am on March 29, 2022: contributor

    The testing guide is now available on https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Candidate-Testing-Guide , @laanwj could you please add that link to OP?

    If anyone has any feedback or suggested changes re the guide, please let me know!

    Thanks for a great guide! ❤️

    For Apple M1 testers like me jumping straight at the binary, a section about how to configure for signet could be good. Otherwise, new testers might end up waiting for the IBD on mainnet. Also, if you’re unfamiliar with working at the terminal, it might be intimidating at first.

    Given the .conf extension is not mapped to something obscure (like Tunnelblick in my case) these steps should work:

    1. From the top menu bar, go to Bitcoin Core > Preferences… or click CMD + ,
    2. Click the Open Configuration File button in the bottom left corner and then click Continue in the next dialog.
    3. The bitcoin.conf file will open in your file editor. Enter signet=1 and save the file.
    4. Restart Bitcoin Core. The start screen should now be yellow, and the icon in the dock should also change to yellow to indicate that you’re running on Signet. You can also tell from the window title, which ends with [signet].

    image image image image image image

  30. hebasto commented at 8:45 am on March 29, 2022: member

    How come there is no option to receive to Bech32m (Taproot) address type when the wallet is encrypted? :thinking:

    Tested on Ubuntu 22.04. Confirming the bug for a just created wallet. Closing the wallet, and following re-opening it could be a temporarily workaround.

  31. eriknylund commented at 9:08 am on March 29, 2022: contributor

    How come there is no option to receive to Bech32m (Taproot) address type when the wallet is encrypted? 🤔

    Tested on Ubuntu 22.04. Confirming the bug for a just created wallet. Closing the wallet, and following re-opening it could be a temporarily workaround.

    Thanks for testing @hebasto! I tried the File menu options Close Wallet... and Close All Wallets... and then tried re-opening it. For me, the Taproot option is still unavailable.

    Another thing that strikes me as I reopen, shouldn’t it be asking me for the password then? Right now I’m only asked to provide the password when I send a transaction. So it seems only part of the wallet is encrypted.

    This led me to another test. If I start out with another new, unencrypted wallet and then Go to Settings > Encrypt Wallet... after encrypting this wallet, the Taproot receive option is available on both the old and new new encrypted wallet.

    Even after closing and reopening wallets, all four receive types are present.

    UPDATE: I tried to reproduce this last “workaround” on my mainnet wallets and it didn’t behave the same. The wallet where I added a passphrase later has the Taproot option. The one I created as encrypted do not.

  32. stickies-v commented at 10:23 am on March 29, 2022: contributor

    For Apple M1 testers like me jumping straight at the binary, a section about how to configure for signet could be good.

    The signet configuration is provided at the beginning of Testing the GUI and this works when using the precompiled binaries too (I’m pointing to the .tar.gz binaries mostly for that reason), but I’ve added a link to your comment to help people that are not launching the GUI from cli. Thank you for providing the write-up with screenshots. (note: you might be interested in #414 GUI for ongoing discussion).

    I’ve just created #24706 as a feedback tracker for the testing guide, so please feel free to add any more thoughts there if you have them.

  33. eriknylund commented at 10:41 am on March 29, 2022: contributor

    I’m running the IBD on mainnet as a part of my testing, and I’ve been switching back and forth between mainnet and signet to test the encrypted wallets and other transaction tests. Because of limited disk space on my M1 I’m on the default settings with a pruned node.

    image image

    Now all of a sudden my mainnet wallets are broken:

    First I received this error message: image Then it changed into: image I am able to create a completely new wallet and open that, but the old ones are no longer working. I have only one instance of Bitcoin Core running.

    I restarted Bitcoin Core and now all wallets open again. So perhaps it wasn’t to do with the signet/mainnet switching after all. I’ll continue my testing to see if it resurfaces and gives me any more clues. For now it’s resolved.

  34. laanwj commented at 11:46 am on March 29, 2022: member

    The testing guide is now available on https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Candidate-Testing-Guide , @laanwj could you please add that link to OP?

    Added, thanks!

  35. brunoerg commented at 4:26 pm on March 29, 2022: contributor

    Tested on MacBook Air (M1, 2020) - macOS Monterey - v12.0.1 I compiled it from source - v23.0rc2

    I ran the functional tests using test_runner.py, 4 tests failed (not related to this release but some tests fail here when running with test_runner), anyway, I executed that tests individually and got no failures. Also, unit tests ran succesfully.

    I followed the guide to test the non-default ports and it worked successfully!

  36. hebasto commented at 9:30 pm on March 29, 2022: member

    How come there is no option to receive to Bech32m (Taproot) address type when the wallet is encrypted? thinking

    Tested on Ubuntu 22.04. Confirming the bug for a just created wallet. Closing the wallet, and following re-opening it could be a temporarily workaround.

    A fixed has been suggested in bitcoin/bitcoin#24711.

  37. fujicoin commented at 9:47 pm on March 29, 2022: none

    Environment: Ubuntu 20.04 Desktop on VMware WS 16 Binary: bitcoin-23.0rc2-x86_64-linux-gnu.tar.gz 15-Mar-2022 19:32 44188780 Problem: Does not start

    0$ ./bitcoin-qt -regtest &
    1./bitcoin-qt: error while loading shared libraries: libxcb-xinerama.so.0: cannot open shared object file: No such file or directory
    

    On Ubuntu 21.04 qt boots fine. Is it a specification that does not support Ubuntu 20.04 or lower?

  38. hebasto commented at 10:00 pm on March 29, 2022: member

    @fujicoin

    0$ sudo apt-get install libxcb-xinerama0
    

    ?

  39. fujicoin commented at 0:48 am on March 30, 2022: none
    @hebasto Wasn’t all the required libraries built with static link in past versions?
  40. hebasto commented at 7:10 am on March 30, 2022: member

    @hebasto Wasn’t all the required libraries built with static link in past versions?

    This is a Qt 5.15 runtime dependency introduced in #23489.

    See details:

  41. GucciPoet commented at 6:09 pm on March 30, 2022: none
    macOs 10.15.6/compiled from source passed tests…no issue.
  42. eriknylund commented at 6:42 am on March 31, 2022: contributor

    My test feedback is available here https://gist.github.com/eriknylund/768787a123ed981d4bf824995bdda733 if you prefer I can submit the full feedback in this thread as well.

    The error dialogs when opening a wallet resurfaced (see #24501 (comment) above) and I’m a bit concerned about it and what it would mean for an unexperienced user.

    image

    Could you give me some insight on what this means and is it perhaps more likely to occur during the IBD? I guess most users will start off with a pruned node, with it being the default setting, and are more likely to run into this?

    Please see the last section https://gist.github.com/eriknylund/768787a123ed981d4bf824995bdda733#ux-considerations for some ideas on UI/UX improvements.

  43. hebasto commented at 6:00 am on April 1, 2022: member

    Fellow testers who is able/willing to test ARM binaries!

    Please test #24115. On supported platforms the Using the 'arm_shani(1way,2way)' SHA256 implementation is expected in the log.

    cc @stickies-v @prusnak

  44. eriknylund commented at 7:36 am on April 1, 2022: contributor

    Fellow testers who is able/willing to test ARM binaries!

    Please test #24115. On supported platforms the Using the 'arm_shani(1way,2way)' SHA256 implementation is expected in the log.

    cc @stickies-v @prusnak

    Tested on: Apple M1 MacBook Pro (13-inch, M1, 2020) macOS Big Sur 11.6.4 (20G417) 23.0rc2-arm64 binary

    Does not match expected output in debug.log.

    02022-04-01T07:25:10Z Using the 'standard' SHA256 implementation
    
  45. laanwj commented at 10:18 am on April 2, 2022: member

    @eriknylund what does this give for output on your system:

    0sysctl -a | grep hw.optional.arm.FEAT_SHA256
    
  46. prusnak commented at 10:34 am on April 2, 2022: contributor

    On MacBook Air (M1, 2020) running macOS 12.3 (21E230):

    0$ sysctl -a | grep hw.optional.arm.FEAT_SHA256
    1hw.optional.arm.FEAT_SHA256: 1
    

    v23.0.0rc2 says:

    02022-04-02T10:32:47Z Using the 'arm_shani(1way,2way)' SHA256 implementation
    

    v23.0.0rc3 says:

    02022-04-02T10:34:30Z Using the 'arm_shani(1way,2way)' SHA256 implementation
    
  47. stickies-v commented at 10:36 am on April 2, 2022: contributor

    Tested on: Apple M1 Macbook Pro (14-inch, M1 Pro, 2021) macOS 12.3 (21E230) bitcoin-23.0rc3-arm64-apple-darwin.tar.gz

    Matches expected output in debug.log:

    02022-04-02T10:31:53Z Using the 'arm_shani(1way,2way)' SHA256 implementation
    
    0% sysctl -a | grep hw.optional.arm.FEAT_SHA256
    1hw.optional.arm.FEAT_SHA256: 1
    
  48. prusnak commented at 10:38 am on April 2, 2022: contributor

    Hm, maybe macOS 11.x reports hw.optional.arm.FEAT_SHA256 inaccurately?

    Let’s wait for what @eriknylund will report back about sysctl output.

    Edit: Yes, that’s it! See https://github.com/dotnet/runtime/issues/62832#issuecomment-994754094 - macOS 11.x does not report hw.optional.arm.* in sysctl -a.

    I think we are fine. If the OS does not report the feature, we should not be using it; plus this is an opt-in optimization. Finally, most of people with M1 hardware will be running macOS 12.x anyway (because that’s what being preinstalled since October 2021).

  49. hebasto commented at 11:14 am on April 2, 2022: member

    Fellow testers who run Bitcoin Core on macOS Monterey.

    Please postpone the Monterey 12.3.1 update until 23.0rc4 to test whether #23134 has been really fixed.

  50. eriknylund commented at 11:29 am on April 2, 2022: contributor

    Hm, maybe macOS 11.x reports hw.optional.arm.FEAT_SHA256 inaccurately?

    Let’s wait for what @eriknylund will report back about sysctl output.

    Edit: Yes, that’s it! See dotnet/runtime#62832 (comment) - macOS 11.x does not report hw.optional.arm.* in sysctl -a.

    I think we are fine. If the OS does not report the feature, we should not be using it; plus this is an opt-in optimization. Finally, most of people with M1 hardware will be running macOS 12.x anyway (because that’s what being preinstalled since October 2021). @prusnak unfortunately I won’t reach this computer for some time but hopefully you found your answer already. I’ll make sure to verify the above when I’m able to.

  51. laanwj commented at 11:38 am on April 2, 2022: member

    I think we are fine. If the OS does not report the feature, we should not be using it;

    Agree, this is the best kind of problem, it only marginally affects performance and will solve itself in time simply by updating the underlying OS. Nothing to do here.

  52. hebasto commented at 12:28 pm on April 3, 2022: member

    Fellow testers who run Bitcoin Core on macOS Monterey.

    Please postpone the Monterey 12.3.1 update until 23.0rc4 to test whether #23134 has been really fixed.

    I’ve managed to sign v23.0rc3 (using this patch), and did apply the Monterey 12.3.1 update both on Intel based and Apple Silicon based systems. The previously installed Bitcoin Core v23.0rc3 has survived. #23134 is indeed fixed.

  53. dunxen commented at 1:32 pm on April 3, 2022: contributor

    Tested on:

    iMac (Retina 5K, 27-inch, 2017) macOS 12.3.1 (Didn’t see hebasto’s comment in time 😅) Compiled from source at tag v23.0rc3

    Findings:

    • Compilation successful
    • Confirmed that creating an encrypted wallet in the GUI results in me not being able to select a bech32m address type (option is missing). I see this has been addressed in #24711 which is merged and backported. I have tested that and it works as expected with the patch.
    • Tested non-default ports and works as expected. After a while I was connected to an IPv4 peer with port 24355 on mainnet.
    • CJDNS: Have been testing this long before #23077 was merged and it’s been working without issues ever since.
  54. hebasto commented at 8:05 am on April 5, 2022: member

    Btw, users of localized GUI could test that no shortcut ambiguities have been introduced during translation.

    An example of an issue:

    Screenshot from 2022-04-05 10-15-49

  55. jsarenik commented at 8:24 am on April 6, 2022: none
    Running latest Bitcoin from 23.x branch + rebased Yggdrasil patches + Alpine Linux locales fix at ln.anyone.eu.org (btc-rpc-explorer (Bitcoin Explorer — BE) at be.anyone.eu.org). Works fine, no GUI and no recent Mac here (had a look at the testing guide), just Linux on old MacBookPro x86_64.
  56. Rspigler commented at 6:27 pm on April 9, 2022: contributor
    Compiled v23.0rc4 on Debian x86. Ran all tests. Was able to set up CJDNS, Tor and i2p connections.
  57. jonatack commented at 12:14 pm on April 11, 2022: contributor
    Ran the rc4 linux binary bitcoin-23.0rc4-x86_64-linux-gnu.tar.gz on mainnet for an hour and some CLI/RPC commands. Verified that the “lock” logging category is disabled in rc4. Ran the GUI at the same time on signet, checked various tabs and did various operations.
  58. hebasto commented at 8:10 am on April 12, 2022: member
    Cross-posting a confirmed GUI bug on Windows: bitcoin-core/gui#582.
  59. prusnak commented at 1:40 pm on April 15, 2022: contributor

    Please postpone the Monterey 12.3.1 update until 23.0rc4 to test whether #23134 has been really fixed.

    Installed 23.0rc4 and updated macOS from 12.3 to 12.3.1 (Apple Silicon) -> Bitcoin Core was not removed -> #23134 is fixed

  60. stickies-v commented at 4:40 pm on April 15, 2022: contributor

    Please postpone the Monterey 12.3.1 update until 23.0rc4 to test whether #23134 has been really fixed.

    ^ same here, 23.0rc4 kept working fine after updating from 12.3 to 12.3.1 (M1 Pro).

  61. fanquake closed this on Apr 25, 2022

  62. fanquake unpinned this on Apr 25, 2022
  63. landabaso commented at 7:41 am on May 28, 2022: none

    I think we are fine. If the OS does not report the feature, we should not be using it;

    Agree, this is the best kind of problem, it only marginally affects performance and will solve itself in time simply by updating the underlying OS. Nothing to do here.

    I’m experiencing performance issues with v23 on macos, but I’m running it on an Intel macbook pro mid 2015 with Big Sur. Mining is x10 slower with v23 than v22 (I need to mine on the regtest for integration testing purposes). Can it be related to what you described (even if I’m on Intel)? EDIT: I upgraded to Monterey and nothing changed: v22 is 10x faster than v23.

    I described the issue on stack exchange.

  64. bitcoin locked this on Jul 12, 2023

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: 2024-12-19 12:12 UTC

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