Compiled v24.0 rc1

Qubes 4.1.1 on a Debian 11 standalone Qube with normal networking
Intel CPU

All tests pass except feature_block.py and feature_pruning.py (I think just because of local resource exhaustion - I'll post on it later).

New IBD with debug=net works with no issues.

Tested the new unification of settings b/w the GUI and bitcoind with no issues

I2P transient addresses work

When testing miniscript I had some issues:
I used min.sc to show me the miniscript of a 3-of-3 that turns into 2-of-3 after a timeout. Tried to use getdescriptorinfo to find the checksum:

getdescriptorinfo "wsh(thresh(3,pk(029ffbe722b147f3035c87cb1c60b9a5947dd49c774cc31e94773478711a929ac0),s:pk(025f05815e3a1a8a83bfbb03ce016c9a2ee31066b98f567f6227df1d76ec4bd143),s:pk(025625f41e4a065efc06d5019cbbd56fe8c07595af1231e7cbc03fafb87ebb71ec),sdv:older(4201803)))"

thresh(3,pk(029ffbe722b147f3035c87cb1c60b9a5947dd49c774cc31e94773478711a929ac0),s:pk(025f05815e3a1a8a83bfbb03ce016c9a2ee31066b98f567f6227df1d76ec4bd143),s:pk(025625f41e4a065efc06d5019cbbd56fe8c07595af1231e7cbc03fafb87ebb71ec),sdv:older(4201803)) is invalid (code -5)

Without the checksum I can't try importdescriptors

Although, when using miniscript.fun 's given descriptor, which has a checksum,(wsh(thresh(2,dv:older(12960),s:pk(038b4059419fe3b95acdee6aff2f9afdca87231d14bd2cbcd3367b11d9d819a71d),s:pk([c893176c/48'/0'/0'/2']xpub6EpqBFyJW2qiEmgcYZqwEGCRuQh3y9fY72RWeAG7pNvKJWgnx7mkviWtfsF7VNQhWPx43zzNfkWhoF8RcnP2KKsXbNHrFNdzx8MFy83N5Sq/0/*)))#3k2f9d8v) - I still run into some issues.

(For people having trouble testing, remember that you have to escape quotes (this isn't in the documentation). So for example:

importdescriptors "[{ \"desc\": \"wsh(thresh(2,dv:older(12960),s:pk(038b4059419fe3b95acdee6aff2f9afdca87231d14bd2cbcd3367b11d9d819a71d),s:pk([c893176c/48'/0'/0'/2']xpub6EpqBFyJW2qiEmgcYZqwEGCRuQh3y9fY72RWeAG7pNvKJWgnx7mkviWtfsF7VNQhWPx43zzNfkWhoF8RcnP2KKsXbNHrFNdzx8MFy83N5Sq/0/*)))#3k2f9d8v\", \"active\": true, \"timestamp\": \"now\"}]"

Results in:

[
{
"success": false,
"error": {
"code": -5,
"message": "thresh(2,dv:older(12960),s:pk(038b4059419fe3b95acdee6aff2f9afdca87231d14bd2cbcd3367b11d9d819a71d),s:pk([c893176c/48'/0'/0'/2']xpub6EpqBFyJW2qiEmgcYZqwEGCRuQh3y9fY72RWeAG7pNvKJWgnx7mkviWtfsF7VNQhWPx43zzNfkWhoF8RcnP2KKsXbNHrFNdzx8MFy83N5Sq/0/*)) is invalid"
}
}
]

Just leaving a link to the 24.0-Release-Candidate-Testing-Guide - maybe also add to OP?

maybe also add to OP?

Added.

Compiled v24.0rc1 from source on Ubuntu 22.04.

No issues encoutered with testing the new features as described by the guide. I did not try with any custom descriptors.

Like @Rspigler I did modify the quotes for descriptors as described by the man page.

I did encounter an issue with the getcoins.py script which I filed a seperate PR for.

I did also notice a few graphical glitches which seem unrelated to the release, and seem most likely to be related to my DE or something else local:

@willcl-ark

I did also notice a few graphical glitches which seem unrelated to the release, and seem most likely to be related to my DE

Mind opening an issue in https://github.com/bitcoin-core/gui/issues and providing your DE details and first rows of you debug.log file with details of your system and loaded plugins?

I've gone through all the scenarios in the guide and just about everything tested as expected, though I did not do any kind of off-roading to explore scenarios that were not described in the guide.

My results and the details for each test can be found here: https://github.com/satsie/bitcoin-notez/blob/master/v24.0rc1-testing.md

I used Ubuntu 22.04, and compiled v24.0 rc1 from source.

A few notes,

• I left a few small comments on the test guide
• During the wallet migration test, I had to walk away from my computer. This was after I did the wallet migration, but before I verified the descriptors. In the 1.5 days I was AFK, my node shut down because I ran out of disk space. When I came back I had to reload the legacy wallet before I could take a look at the descriptors. I'm assuming this is to be expected, and did not have to reload the wallet when I tried this test a second time.
• I witnessed several of crashes in the GUI when I was testing wallet restoration, but I think it was related to the situation I just described with my node stopping because it was out of disk space. When I restarted the node, I turned pruning on. Upon starting the GUI, I was prompted to agree to a reindex, which I did. Despite that, I still had crashes while trying to restore a wallet. This seems like an edge case though, and I'd expect there to be unpredictable behavior before the reindex completes. I unfortunately didn't capture any logs for this because I initially thought it had to do with reloading a wallet to a data directory that already had the wallet loaded. I figured I'd just retest and get logs then. However, I went on to test that scenario and there were no problems.
• Regarding the escaping for the importdescriptors command mentioned in previous comments, the test guide uses a combo of single and double quotes, and stores the descriptor in a variable. This seems to reduce the total number of annoying quote escapes that have to be made. I know this is technically a CLI thing as opposed to a bitcoin core thing, but mentioning it in case it can help with documentation.

Regarding the escaping for the importdescriptors command mentioned in previous comments, the test guide uses a combo of single and double quotes, and stores the descriptor in a variable.

@satsie , Thank you. I will try that. I wonder why it doesn't work with the traditional importdescriptors (it was recognized but said invalid?)

@willcl-ark

I tried to reproduce the GUI text bug you mentioned in your comment. But I couldn't replicate it.

System Configuration:

• Ubuntu 22.04
• Qt version 5.15.3

Screenshot:

@shaavan

I tried to reproduce the GUI text bug you mentioned in your comment. But I couldn't replicate it.

I guess it depends on the DE used by @willcl-ark.

I've just tried again and afraid that I cannot reproduce it either. FWIW I was using Stock Ubuntu 22.04 (Wayland?) for the previous test where I saw the glitch, but just tried in both that environment and my normal X11/i3 and it looks fine in both. So I guess it's fine.

@Rspigler to clarify, I'm referring to this line in the guide:

cli importdescriptors '''[{"desc": "'$descriptor'", "active": true, "timestamp": "now"}]'''

That's what you're referring to when you say traditional importdescriptors right?

I compiled 24.0rc1 from source on Ubuntu 24.0

I have only tested Miniscript descriptors so far but will hopefully get to the other sections of the testing guide.

I used the following descriptor:

wsh(or_d(multi(2,[a1fea26b]tpubD6NzVbkrYhZ4WpWv4FVzFMoXptxyP2V9hkXngApGN2T5i1ikLBMS4Ppk8gEdn4w9TPw5t2NEa8CMAVW8qPVifL8Jx1yPAEMTQfYMSjx9gZL/0/*,[2fdf5425]tpubD6NzVbkrYhZ4Xb3qd5sz65UqtNCAx32cJPpKY5cjFAK7FVdXS6D8qJqapyRBtq221vHvreAJN6gehJZ1wMNVez75JeZ6w5kekXgexfY9Dqa/0/*,[bb6d66cb]tpubD6NzVbkrYhZ4WNgb7PhhKJ7cX3Weofnj5u8UhrVrACYKoMszKH4RK14qJcX8z3iDqxE6buUj8pp2g3txHXzu2Z4EqvCVGGCMxXkVib39YRF/0/*),and_v(v:pk([e18bfc51]tpubD6NzVbkrYhZ4Y5VYLAafGd2aDnmSxpn99Doew6JZBcWXJLtDjN9rvCGPH9pqzZR2ZMuzHasu1eCLL49m1AGCwFzJjGAtZ23Qj2y4Nehyz9d/0/*),after(52560))))#mfr3c0nd

And everything worked as expected

@Rspigler

Although, when using miniscript.fun 's given descriptor, which has a checksum,(wsh(thresh(2,dv:older(12960),s:pk(038b4059419fe3b95acdee6aff2f9afdca87231d14bd2cbcd3367b11d9d819a71d),s:pk([c893176c/48'/0'/0'/2']xpub6EpqBFyJW2qiEmgcYZqwEGCRuQh3y9fY72RWeAG7pNvKJWgnx7mkviWtfsF7VNQhWPx43zzNfkWhoF8RcnP2KKsXbNHrFNdzx8MFy83N5Sq/0/*)))#3k2f9d8v) - I still run into some issues.

Perhaps this is because this is invalid Miniscript? I am not certain that it is invalid, but when I enter the following on the Miniscript reference website under the "Analyze a Miniscript " section it is unable to analyze it:

thresh(2,dv:older(12960),s:pk(KEY_A),s:pk(KEY_B))

But it is able to analyze this:

thresh(2,ln:older(12960),s:pk(KEY_A),s:pk(KEY_B))

So perhaps this descriptor may work:

wsh(thresh(2,ln:older(12960),s:pk(038b4059419fe3b95acdee6aff2f9afdca87231d14bd2cbcd3367b11d9d819a71d),s:pk([c893176c/48'/0'/0'/2']xpub6EpqBFyJW2qiEmgcYZqwEGCRuQh3y9fY72RWeAG7pNvKJWgnx7mkviWtfsF7VNQhWPx43zzNfkWhoF8RcnP2KKsXbNHrFNdzx8MFy83N5Sq/0/*)))

Thank you for the above discussion and suggestions.

I re-compiled, with more memory.

All tests now pass.

I am using https://min.sc for descriptors. Using 'One of two keys', which has the Minsc of pk(A) || pk(B), says it compiles to Miniscript/Descriptor of:

wsh(or_b(pk(029ffbe722b147f3035c87cb1c60b9a5947dd49c774cc31e94773478711a929ac0),s:pk(025f05815e3a1a8a83bfbb03ce016c9a2ee31066b98f567f6227df1d76ec4bd143)))

Because there is no checksum, I should be able to use getdescriptorinfo

getdescriptorinfo "wsh(or_b(pk(029ffbe722b147f3035c87cb1c60b9a5947dd49c774cc31e94773478711a929ac0),s:pk(025f05815e3a1a8a83bfbb03ce016c9a2ee31066b98f567f6227df1d76ec4bd143)))"

{
"descriptor": "wsh(or_b(pk(029ffbe722b147f3035c87cb1c60b9a5947dd49c774cc31e94773478711a929ac0),s:pk(025f05815e3a1a8a83bfbb03ce016c9a2ee31066b98f567f6227df1d76ec4bd143)))#66nn4z9j",
"checksum": "66nn4z9j",
"isrange": false,
"issolvable": false,
"hasprivatekeys": false
}

Great!

However, what happened last time/above, is that I tried using 'A 3-of-3 that turns into a 2-of-3 after a timeout'. This has a Minsc of 3 of [ pk(A), pk(B), pk(C), older(1 month 2 weeks) ], and a Miniscript/Descriptor of:

wsh(thresh(3,pk(029ffbe722b147f3035c87cb1c60b9a5947dd49c774cc31e94773478711a929ac0),s:pk(025f05815e3a1a8a83bfbb03ce016c9a2ee31066b98f567f6227df1d76ec4bd143),s:pk(025625f41e4a065efc06d5019cbbd56fe8c07595af1231e7cbc03fafb87ebb71ec),sdv:older(4201803)))

Like previously, getdescriptorinfo fails:

I believe this is an issue with Min.sc, since besides failing with Bitcoin Core, Sipa's site also cannot analyze it.

Let's import the working 'One of two keys' descriptor:

importdescriptors "[{ \"desc\": \"wsh(or_b(pk(029ffbe722b147f3035c87cb1c60b9a5947dd49c774cc31e94773478711a929ac0),s:pk(025f05815e3a1a8a83bfbb03ce016c9a2ee31066b98f567f6227df1d76ec4bd143)))#66nn4z9j\", \"active\": true, \"timestamp\": \"now\"}]"

[
{
"success": false,
"error": {
"code": -8,
"message": "Active descriptors must be ranged"
}
}
]

So, try it with a range:

importdescriptors "[{ \"desc\": \"wsh(or_b(pk(029ffbe722b147f3035c87cb1c60b9a5947dd49c774cc31e94773478711a929ac0),s:pk(025f05815e3a1a8a83bfbb03ce016c9a2ee31066b98f567f6227df1d76ec4bd143)))#66nn4z9j\", \"active\": true, \"range\": 10, \"timestamp\": \"now\"}]"

[
{
"success": false,
"error": {
"code": -8,
"message": "Range should not be specified for an un-ranged descriptor"
}
}
]

Hmm. Any ideas?

@Rspigler A ranged descriptor is one with a key range in it, for example an xpub expression ending with "/*".

@Rspigler using sipa's site you can input the general policy thresh(3,pk(A),pk(B),pk(C),older(4201803)) to have it analyzed. Note that the site analyzes policies using a NAME (and not a full pubkey). This will output the miniscript thresh(3,pk(A),s:pk(B),s:pk(C),sln:older(4201803)), which, if we substitute your pubkeys in we get the following which is able to have it's info fetched:

$ ./src/bitcoin-cli -signet getdescriptorinfo "wsh(thresh(3,pk(029ffbe722b147f3035c87cb1c60b9a5947dd49c774cc31e94773478711a929ac0),s:pk(025f05815e3a1a8a83bfbb03ce016c9a2ee31066b98f567f6227df1d76ec4bd143),s:pk(025625f41e4a065efc06d5019cbbd56fe8c07595af1231e7cbc03fafb87ebb71ec),sln:older(4201803)))"
{
  "descriptor": "wsh(thresh(3,pk(029ffbe722b147f3035c87cb1c60b9a5947dd49c774cc31e94773478711a929ac0),s:pk(025f05815e3a1a8a83bfbb03ce016c9a2ee31066b98f567f6227df1d76ec4bd143),s:pk(025625f41e4a065efc06d5019cbbd56fe8c07595af1231e7cbc03fafb87ebb71ec),sln:older(4201803)))#3a0q4c2h",
  "checksum": "3a0q4c2h",
  "isrange": false,
  "issolvable": false,
  "hasprivatekeys": false
}

Make sure you are using Bitcoin Core v24.0 to analyze it, otherwise it will fail!

@Rspigler:

Let's import the working 'One of two keys' descriptor:

importdescriptors "[{ \"desc\": \"wsh(or_b(pk(029ffbe722b147f3035c87cb1c60b9a5947dd49c774cc31e94773478711a929ac0),s:pk(025f05815e3a1a8a83bfbb03ce016c9a2ee31066b98f567f6227df1d76ec4bd143)))#66nn4z9j\", \"active\": true, \"timestamp\": \"now\"}]"

[
{
"success": false,
"error": {
"code": -8,
"message": "Active descriptors must be ranged"
}
}
]

Note that the passed descriptor is not active; setting the passed active parameter to "false" (or simply remove it, since importdescriptors assumes inactive descriptors by default) should work.

Ah, of course, I'm sorry - that's embarrassing. That's what happens when I pull all nighters, make stupid mistakes.

importdescriptors "[{ \"desc\": \"wsh(or_b(pk(029ffbe722b147f3035c87cb1c60b9a5947dd49c774cc31e94773478711a929ac0),s:pk(025f05815e3a1a8a83bfbb03ce016c9a2ee31066b98f567f6227df1d76ec4bd143)))#66nn4z9j\", \"active\": false, \"timestamp\": \"now\"}]"

[
{
"success": true
}
]

I have no further issues with v24.0r c1

I successfully tested v24.0rc2, built from source on Ubuntu 21.04 in a virtual machine.

All tests suggested in the guide worked.