Similar but that may be an unrelated issue.
Based from that info alone, I can tell that it's an issue with the "coin_index" derivation path used in testnet which should be different from mainnet.
Still need confirmation with testing though.

But with their "busy" developers (since the original issue I reported above is still not closed) and the issue being testnet-specific,
I wont make the effort to report this issue myself.

Go to the directory pointing to "settings.json" file in the error message in your previous reply.
Open it as "text" and see if you can make some edits to the contents and save without errors (but make sure to revert the changes after).

But the failed write attempt to settings.json is less likely the culprit of the random crash but most likely a side effect of the underlying issue.
Furthermore, if it's the issue to begin with, Bitcoin Core will immediately alert you that it can't write to the file during its start process and will not proceed.

Your log looks fine and seem to be cut off while running, leaving no errors.

The error message concerning the settings.json file will also occur if it can't write to or find the path where it should dump the temporary settings.
Or try to follow its instructions.

The range is too loose to be specific on Bitcoin Core, perhaps it's your drive failing at some point.
I'd suggest you to test your hardware with stress tools specially the SSD/HDD/RAM.
And check the drive for bad sectors.

Take note that Bitcoin Core pushes your drive to its limit unlike other programs.

Although you're exclusively connected to your full node in the virtual Linux server and prevents inbound connections,
that node may still advertise your IP through addr message or when it receive getaddr message from its peers.
But I'm not sure if any of your config makes a difference on how the remote node create the addr message though.

Ref: developer.bitcoin.org/reference/p2p_networking.html#addr

Yes, that's one way to make it in Bitcoin Core.
And in the later versions, it will even output a "Descriptor" that you can import to a descriptor wallet where you can manage the transactions and co-signing instead of relying on commands.

The source doesn't matter since incompatibility to send to different address types is mainly a client-related issue.

Transactions are locked with a script not in the private key(s), in this case that MultiSig address.
Different addresses are representation of different locking scripts so the generated MultSig address will be treated differently as it requires different unlocking script to be spent.

Privacy issues, it'll be obvious that the MultiSig address and those two SingleSig addresses are owned by two individuals just by checking any of their "spending" transactions.

The only security concern in that is the double risk of getting their funds compromised due to using the same private key to two use-cases, but that depends on how they handle the private keys.

Bottom-line is it's a bad answer to OP's question.

You see, he's asking if it's enough to re-establish the MultiSig wallet, if he followed the advice that the descriptor is enough.
He may count on it in case the seed phrases are gone.

As you can see, that exported descriptor wallet doesn't contain anything that can sign a transaction from either cosigner.
You can check it yourself that it contains "extended public keys" and no master private keys or seed.

If it's a watch only wallet, it is a watch only wallet.
In exception to hardware wallet that can be used to sign transactions which isn't OP's case.

Like I said, if that BIP39 software wallet is loaded,
even if you created the transaction using that watching-only wallet, Sparrow will use the necessary wallet to sign it, in that case, the BIP39 software wallet.

Go to your BIP39 software wallet and close it, then try to send a new transaction again using the watch only wallet.

If you somehow created it as 1-of-2, then one signer is only required so keep it in consideration with the results.
E.g. Can be signed by Passport 2 alone.

No it's not, you created a 'Watch Only Wallet' with the "extended public keys" in the descriptor.
It's just Sparrow doesn't indicate it in obvious spots, it's only visible in the specific wallet's settings

If you've tested a transaction and you somehow signed it successfully, you must have the original non-watching-only wallet loaded together with that restored watching-only copy.

One way to make sure of it is to expand your transaction in the 'Transactions' tab.
Use the forward arrow icon ▶ on front of it and you'll see which UTXO are spend and created;
"Spent" represents which UTXO are removed from your UTXO tab since those are used by that transaction.
And "Change" or "Received" are the ones added to your UTXO tab.

If you check its "output point" (Shown as: Change to <txid:txindex>), it should match with its corresponding entry in the UTXO tab.

Of course, if you have other transactions, check if the change or received UTXOs in the other transaction are spent by the later ones.

If in the same wallet, yes with just the seed phrases.
If in separate wallet, you'll have to derive the extended public keys from those seed phrases (during wallet creation or somewhere) to re-create the cosigner wallets.
But it's better to backup the other cosigner's extended public keys in case one of the cosigner lost his seed phrase.

No, as of the latest version, it can only export watch-only descriptors containing extended public key(s) rather than master private key(s).
As noted in the "Information" in the export dialogue, it's mainly for watching-only wallet generation rather than backup.

My test with "Positional Anchors" for the first 6 words (to speed-up testing) are successful.
Just make sure that those 2048 words are listed in the same line so it will only try one word in that line in each combination
Because otherwise, each line wont be treated as "Mutual Exclusion" and will be tried together with the other words.

(refer to the old/new BTCRecover's token file documentation for the terms)

I've just finished testing Bitcoin Knots' latest version and it seems like an unreported issue,
you can report it to their repo to see if the developers can make it work.

For now, the workaround is to use the command line instead.
I used bitcoin-cli to issue the command and it worked as intended, of course set the necessary config/args to enable RPC.

How about Bitcoin Core's version?
The latest Bitcoin Core version 26.0 uses QT v5.15.10.

I'm unable to reproduce this in v26.0 with "deprecatedrpc=create_bdb" to create a legacy wallet file.
The wallet loads and I'm able to import a watch-only address.

Try upgrading to the latest version and/or try manually loading the wallet via loadwallet "wallet_name" command.
See if it'll actually load without any error, if not, there may be something wrong with the wallet.dat file or the way it's loaded. (more info on that may help)

But it's for btcrecover while OP is utilizing "seedrecover.py" script which doesn't use btcrpass.py but btcrseed.py.
In seedrecover, as of btcrecover v1.12, his options to use GPU is under "OpenCL acceleration" when prompted for commands via seedrecover.py -h.

Here are the available args for seedrecover gpu acceleration: github.com/3rdIteration/btcrecover/blob/master/btcrecover/btcrseed.py#L3204-L3210
The developer has a note in the official documentation page that it's currently buggy though.

Not usually the case, unless it somehow broken the path to your default data directory and bitcoin.conf file where you set the custom datadir while the GUI's setting is set to default.
In that case, it'll create a new "bitcoin" folder in the default datadir at the correct path and save the blockchain and other data there.
(the folder may be hidden)

If the custom datadir is set in the GUI's config instead (set in the Welcome Screen) and the path to "com.Bitcoin" somehow messed up by the network setting change,
In the next restart of Bitcoin Core, the Welcome screen will prompt you again to set the data directory,
if you didn't noticed and just clicked ok, it'll use the default internal drive.

In your December 2023 thread, there was no unknown word and the issue was just the arrangement.
I'm doubtful that there's just additional 1 missing word at play here.

Anyways, just do the same as the previous token file but instead of the line "casual", replace it with the whole BIP39 word list without break lines (enter).
So the whole 2048 words are only separated by spaces occupying only one line.

Example:

As for the GPU, I can't add anything aside from what's already mentioned in the other topic.

Most of the members take the phrase "consolidate them to 1 transaction" as "to one UTXO", so am I.
If so, those scenarios don't represent the same use-case so it's unfair to the other option to compare fees.
'Scenario 1' pays three recipients and 'Scenario 2' pays only one; to balance it, second scenario should also be paying three recipients.

-> If the use-case is to pay three different recipients in a short period when mempools' average fee should be similar;

• In "Scenario 1", you will create three separate transactions with 'one input' - 'one or two outputs' each.
• In "Scenario 2", you will create three separate transactions, the first one will have 'three input' - 'two outputs', then the change will be spent by the second txn (1in-2out) and the second's change to be spent by the third txn (1in-1or2out).

Basically you'll spend more fee in "Scenario 2" because of the unnecessary consolidation of 3 inputs in the first transaction that'll be larger than spending just 1 input.

-> But if Scenario 2 will pay all three recipients in one transaction, the single transaction will spend all three inputs and create three or four (if has change) outputs.
The overall size, so as the fee in "Scenario 2" in this case would be lower than three separate transactions.

You mean the "log2_work=" in each "UpdateTip" lines in the debug.log file?
That's just the accumulated number of hashes it would take to build the blockchain at that point.
It has something to do with choosing the best chain and unfortunately has nothing to do with your node failing at 97% IBD.

Better focus on the actual error or share your log for forum members to look into.

Then I suppose Base58 failed at accomplishing its very own purpose in some cases, being "human-friendly".
IDK but WIF private keys don't look intimidating to copy for me since each characters look different from each other.

Based from OP's latest reply, I guess this is a matter of preference rather than actual (dis)advantage when it comes to writing backups.

In that case, it's completely safe.
That's considering that you haven't exported any of your air-gap wallet's private key, even one.
Because if you do, if compromised, it can be used together with the extended public key in the online machine to compute all of your other private keys.
Otherwise, it's safe.

The public server and the MITM attacker don't have access to users' private keys even in a non-air-gap setup anyways.
All it can access are privacy-related data which are your transactions and addresses, and as you know it, fake the data that you receive.
SPV wallets sign transactions locally.
(this is considering Sparrow doesn't have bugs that will lead to the attacker to intercept the private key in another way, so keep it air-gap)

The warnings about it's unsafe to access your air-gap machine (PC) in an online environment is because that will defeat its purpose.
It may or may still be safe depending on the online device's security but it's not "air-gap" anymore once connected to the internet even after disconnection.