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

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

When reverting PR: #22514 it works again

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.

#22514 config. Compiled v23.0

v23.0rc2 on Windows 11:

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

See:

• bitcoin-0.21.0-win64-setup installer blocked by UAC, Digital Signature certificate revoked. bitcoin-core/gui#252
• Update Windows code signing certificate #22017

cc @achow101

@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.

v23.0rc2 on macOS Monterey x86_64:

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

cc @achow101 @fanquake

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

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

You're right:

% codesign -vvv --deep --strict /Applications/Bitcoin-Qt.app  
/Applications/Bitcoin-Qt.app: valid on disk
/Applications/Bitcoin-Qt.app: satisfies its Designated Requirement

Compiled v23.0rc1 FreeBSD 13.0-RELEASE Passed all tests.

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

I was able to fully resync the chain without issue

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

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

Downloaded and syncing w/ GUI on macOS 12.3 M1 with no problems so far. Great stuff!

👍😉👍😎👍😊👍🤩👍😘👍
Good luck everyone
And congratulations to all stuff..
Good work..!!

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

TEST                         | STATUS    | DURATION

interface_usdt_net.py        | ✓ Passed  | 2 s
interface_usdt_utxocache.py  | ✓ Passed  | 4 s
interface_usdt_validation.py | ✓ Passed  | 1 s

ALL                          | ✓ Passed  | 7 s (accumulated)
Runtime: 4 s

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:

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

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

/usr/local/include/boost/signals2/connection.hpp:80:22: note: overridden virtual function is here
        virtual bool connected() const = 0;
                     ^
/usr/local/include/boost/signals2/connection.hpp:195:22: warning: 'lock' overrides a member function but is not marked 'override' [-Wsuggest-override]
        virtual void lock()
                     ^
/usr/local/include/boost/signals2/connection.hpp:102:22: note: overridden virtual function is here
        virtual void lock() = 0;
                     ^
/usr/local/include/boost/signals2/connection.hpp:199:22: warning: 'unlock' overrides a member function but is not marked 'override' [-Wsuggest-override]
        virtual void unlock()
                     ^
/usr/local/include/boost/signals2/connection.hpp:103:22: note: overridden virtual function is here
        virtual void unlock() = 0;
                     ^
/usr/local/include/boost/signals2/connection.hpp:212:34: warning: 'release_slot' overrides a member function but is not marked 'override' [-Wsuggest-override]
        virtual shared_ptr<void> release_slot() const
                                 ^
/usr/local/include/boost/signals2/connection.hpp:132:34: note: overridden virtual function is here
        virtual shared_ptr<void> release_slot() const = 0;
                                 ^
31 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:

PASS: minisketch/test
PASS: univalue/test/object
PASS: univalue/test/unitester
PASS: univalue/test/no_nul
PASS: qt/test/test_bitcoin-qt
============================================================================
Testsuite summary for Bitcoin Core 23.99.0
============================================================================
# TOTAL: 5
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

The make deploy also works after command pip3 install ds_store.

@kibnakamoto

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

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 (jonatack/jonatack.github.io@e8f4c2b). I use this flag by default since it was added.

I use this flag by default since it was added.

#22041 :)

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!

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:

This is when I create one that is encrypted:

Setup:

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

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].

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

@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:

• https://github.com/bitcoin/bitcoin/blob/v23.0rc2/contrib/devtools/symbol-check.py#L119
• https://doc.qt.io/qt-5/linux-requirements.html

macOs 10.15.6/compiled from source
passed tests...no issue.

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.

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.

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

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.

2022-04-01T07:25:10Z Using the 'standard' SHA256 implementation

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

sysctl -a | grep hw.optional.arm.FEAT_SHA256

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

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

v23.0.0rc2 says:

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

v23.0.0rc3 says:

2022-04-02T10:34:30Z Using the 'arm_shani(1way,2way)' SHA256 implementation

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:

2022-04-02T10:31:53Z Using the 'arm_shani(1way,2way)' SHA256 implementation

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

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).

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.

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.

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.

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.

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 wallet: Postpone wallet loading notification for encrypted wallets #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 Full CJDNS support #23077 was merged and it’s been working without issues ever since.

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

An example of an issue:

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.

Compiled v23.0rc4 on Debian x86. Ran all tests. Was able to set up CJDNS, Tor and i2p connections.

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.

Cross-posting a confirmed GUI bug on Windows: bitcoin-core/gui#582.

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

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).

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.