Open jakubtrnka opened 8 months ago
Can you try this again with the sv2
branch (https://github.com/bitcoin/bitcoin/pull/29432). They're probably the same, apart from rebases b171a79edf7cdd2e1ddf968b7634af19e0a05ce9.
Did you check that your server_static_key=9buWsBdB1WEsGTn95Q2qM8A4RHvE3RbnuFWhQk7u3JWkNyiKzr7
(base58) matches the hex encoded static key 02a7e5a29bf028e6c8191f88b508edce7734282dd8bafeeb2b26bb92ebdd8c0027
printed by the template provider?
I'm assuming the valid_from
and not_valid_after
fields were not the issue?
One next step for debugging would to be log and compare "Certificate hashed data" with 00006e20eb65ffffffff
.
Were you able to connect to an SRI role? Last time I tested I was able to connect from various SRI roles to the Template Provider, including certificate verification.
I just looked up the commit hash you used: 8b42c0f7d5629887584e2c1fa4bd8a8a8efce907
It's from before we fixed the certificate checking in SRI https://github.com/stratum-mining/stratum/pull/752
This branch contains a workaround for this bug: f00ef11c3423cd03520ea9e4d46eb0ac475e8188
That's why the "Certificate hashed data" data is so short: it doesn't include the static key.
Hopefully switching to my sv2
branch will magically fix things for you.
Are you still seeing this?
Is there an existing issue for this?
Current behaviour
Noise handshake fails if NOISE_SIGNATURE_MESSAGE validation is enforced.
Expected behaviour
The signature should be validated successfully
Steps to reproduce
./bitcoind -regtest -sv2 -debug=sv2 -loglevel=sv2:trace
2024-03-08T15:27:58Z Template Provider authority key: 9bNYLvwTgfh9Ez9REW9giPcXgKi3HTijS5bSJvgF47gRdQmsveT
9bNYLvwTgfh9Ez9REW9giPcXgKi3HTijS5bSJvgF47gRdQmsveT
Relevant log output
my logs
logs on TP on start
How did you obtain Bitcoin Core
Compiled from source
What version of Bitcoin Core are you using?
2024/02/sv2-poll-ellswift@8b42c0f7d5
Operating system and version
arch linux
Machine specifications
No response