I have run into an issue where I cannot verify the signatures for test releases (like v24rc3 or v25rc2). When I execute:

gpg --verify SHA256SUMS.asc SHA256SUMS

It returns exitcode 2, while on the final releases it works fine.

What could be causing this behaviour? Or is it to be expected that test releases are not signed?

What could be causing this behaviour?

There are a few new signers this time so you're probably missing their keys.

Thanks, when updating the keys I found that keys.txt no longer exists in this repo, so I solved it by doing:

 KEY_URL=https://raw.githubusercontent.com/bitcoin-core/guix.sigs/main/builder-keys

 curl -sSL ${KEY_URL}/CoinForensics.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/Emzy.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/Sjors.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/TheCharlatan.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/achow101.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/benthecarman.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/cfields.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/darosior.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/dunxen.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/fanquake.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/glozow.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/guggero.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/hebasto.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/jackielove4u.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/josibake.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/laanwj.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/satsie.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/sipa.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/svanstaa.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/theStack.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/vertiond.gpg | gpg --import - \
 && curl -sSL ${KEY_URL}/willyko.gpg | gpg --import -

But as soon as new signers will be added or removed in the future, the script will break again.

So why is there not a single file that bundles all the current keys so that I dont have to download them all individually?

So why is there not a single file that bundles all the current keys so that I dont have to download them all individually?

No one can know all the current keys, because they can change for every release. However, it is possible to find them for a given release by looking into the folder. For example, you can look into https://github.com/bitcoin-core/guix.sigs/tree/main/25.0rc2 to find all current ones for that tag.

For a script it will be hard to parse the directory names for a Github folder reliably with only curl calls.

It was so much easier if there was a text-file containing a list of names, so that I could just download that and loop over that line by line. In any case I made an issue in the guix.sigs repo about this, because this is a bit off-topic here. Thanks.

Not sure what your goal is, but if you want to blindly download all keys, you can also use git to clone the whole folder https://github.com/bitcoin-core/guix.sigs/tree/main/builder-keys and then just import all files in the folder into gpg?

Yes, but I do this from a script and I wanted to avoid having to install git just to quickly verify a binary release.

You could query the repo with curl?

$ curl -s "https://api.github.com/repos/bitcoin-core/guix.sigs/contents/25.0rc2" | jq -r '.[] | select(.type=="dir") | .name'
CoinForensics
Emzy
Sjors
TheCharlatan
achow101
benthecarman
cfields
darosior
fanquake
glozow
guggero
hebasto
jackielove4u
josibake
laanwj
svanstaa
theStack
vertiond

@willcl-ark Thank you very much. I had already opened an issue ( bitcoin-core/guix.sigs#696 ) where TheCharlatan came up with a very similar suggestion.

Question about the guide @ismaelsadeeq

https://github.com/bitcoin-core/bitcoin-devwiki/wiki/25.0-Release-Candidate-Testing-Guide#test-finalizing-a-psbt-with-inputs-spending-miniscript-compatible-p2wsh-scripts-and-test-spending-the-coin

Is the explanation of the descriptor correct?

it looks to me like simplified its or(tprv8Zgx, and(tprv8Zgx, and(tprv8iF7, older(10)))) which IIUC means "either the first key OR all three of the remaining conditions (the two other keys and the timelock)"

Here is the decoded script after running through the guide:

02b06d1fe4fb4cfd57a2b2023ab0ae4b043454875322a8870bb44b02c74715c48b OP_CHECKSIG
OP_IFDUP OP_NOTIF
    034c91ea58dfaad58d11b867be402ef2b72ad0260e3f95640e7d94da0d3a69496c OP_CHECKSIGVERIFY
    03ba41d437924e883d0f8c4a5c764e3cca4edcd7eeaca754518088e5d3945185e5 OP_CHECKSIGVERIFY
    10 OP_CHECKSEQUENCEVERIFY
OP_ENDIF

Other feedback about the guide:

• You can add -named and -minconf=100 to listunspent to find the mature coinbase coins more easily

• If testers download a binary, it may be GUI only (e.g. macOS) which is fine but may require a few extra params for example I ran this:
  .../Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -server -regtest -printtoconsole=1

https://github.com/bitcoin-core/bitcoin-devwiki/wiki/25.0-Release-Candidate-Testing-Guide#test-finalizing-a-psbt-with-inputs-spending-miniscript-compatible-p2wsh-scripts-and-test-spending-the-coin

Is the explanation of the descriptor correct?

Sure that is the correct explanation, I got the same output from https://bitcoin.sipa.be/miniscript/
Miniscript input or_d(pk(A),and_v(v:pk(B),and_v(v:pk(C),older(10))))
Script output

<pk(A)> OP_CHECKSIG OP_IFDUP OP_NOTIF
  <pk(B)> OP_CHECKSIGVERIFY <pk(C)> OP_CHECKSIGVERIFY 10 OP_CHECKSEQUENCEVERIFY
OP_ENDIF

I will update and simplify the explanation, thank you for pointing this out.

I downloaded the binaries on a System76 machine running Pop!OS 22.04 LTS. I ran all the tests in the testing guide(except the last one about verifying binaries) and got expected results. More detailed notes can be found here. https://github.com/chippsmith/bitcoinnotes/tree/main/bitcoin25.0rc.

Looks like >> is missing after "maxconnections=2" in

$  cd $DATA_DIR && echo "signet=1" >> bitcoin.conf && echo "maxconnections=2" bitcoin.conf  && cd ~

Also, it’s easier to copy the commands using the (hover) copy icon on Github if you remove the $ in front.

A comment on the following paragraphs:

To create a non-witness transaction of 64 bytes or so, You can generate an OP_RETURN output with the following dummy data in hexadecimal format: 6a00000000.

Get a new change address
$ bcli -regtest getnewaddress
You should create a transaction with two outputs: one that sends Bitcoin to the address you generated, and the other that is an OP_RETURN output with the hex value of 6a00000000

$ bcli -regtest createrawtransaction '[{"txid":"04b1a84bce28b2c989d53689404db5e3e22a2ca1875678e20286edd74dc11ace","vout":0}]' '{"data":"6a00000000"}'
You will get an unsigned transaction hex.

It’s not clear how the change address should be used in the creation of the raw transaction.

@chippsmith Thanks for your testing effort.
@schjonhaug Thank You for your feedback, I will update the document.
For all feedback on the testing guide document please drop it here #27736

Tested up to "Finalizing a PSBT..." (no bonus test yet).

They all executed successfully!

25.0rc2 compiled from source

Hardware Info:

• Memory: 15.5 GiB
• Processor: Intel® Core™ i7-7700HQ CPU @ 2.80GHz × 8
• OS: Ubuntu 20.04.5 LTS 64-bit

25.0 has been tagged.

• MacOS 13.3.1
• 25.0rc2 compiled from source
• tested through the entire guide, including bonus and verifying binaries test.
• everything worked, documented a test guide comment in the test guide issue as we discussed in irc.