Alternatively, he can dedicate a blank descriptor wallet and import a "pk" descriptor containing the public key's private key pair.
Then, Bitcoin Core will be able to conveniently spend P2PK outputs for that pubKey with wallet commands or GUI.

Example import command with P2PK descriptor:

My only concern in this is the misleading GUI elements which shows an address in the 'receiving addresses' and in the 'inputs' list (as well in "listunspent" command)

Child-Pays-for-Parent doesn't actually increase the fee of the parent, it's just the result of current default selection of transactions used by miners.
Here's the PR when it's implemented: https://github.com/bitcoin/bitcoin/pull/7600

What actually happens is the parent and children transaction fees and sizes are all taken into consideration when getting the overall fee rate,
Kind of like a "bundle deal", you sent a transaction that pays a high fee but it can't be mined unless its parent is mined as well.
So the miners have to check if the overall fee rate when the parent is included is still higher than the other transactions in their mempool.

With that, it's not limited to Electrum, as long as miners use the same transaction selection method, CPFP will work.

Thanks, I see that it's just merged 3 weeks ago which will be included in the next release.
I'm surprised that OP is using the dev build.

The fact that it's already in your receiving address list tells that it's imported successfully.
So the main issue is either there's a transaction that Bitcoin Core failed to scan in Computer2, or the transaction in Computer1 isn't actually in the Blockchain,
only locally saved in the wallet for a couple of possible reasons like dropped, replaced, invalid or not broadcasted.

I think this whole issue really needs its own topic since there's more to it than failing to import a private key to another computer.
For example, computer1 doesn't have to be 99.99% off, it just have to be "AirGap";
And computer 2 doesn't have to be imported with a private key from Computer1, it only needs a watching-only descriptor.
What described is a Cold-Storage Setup which is a lot safer than Hardware Wallets.

You can start a topic by going to the proper board, recommended: Bitcoin Forum > Bitcoin > Bitcoin Technical Support
And by clicking the small blue "new topic" button at the right-hand side of the page.

No, it's not in the derivation path; the script type (p2wpkh or p2sh-p2wpkh) only if it follows BIP48 standard but not the information about the consignees.

The number of required signatures is in the "redeem script" and the number of cosigners is based from the number of public keys in it.
That wont affect the derivation from the user's master private key to the extended public key that'll be used to derive the public keys in the MultiSig setup.

Different m-of-n setup wont produce a different xpub, it's just the difference in derivation path as explained in the previous posts.

I'm not aware of any "importmempool" command in Bitcoin Core, perhaps you're looking at some other Bitcoin node implementation?

If so, please specify;
While you're at it, please provide more information about your "experiment" so that users can give you more fitting answers.

Most of your comments are on point which deserved a merit, I'd just want to point out the correct terms here.

Electrum's default wallet types connect to the internet so it should be called "Hot Wallet" instead of online wallet.
"Online wallets" are mostly accessed though websites or even mobile apps connected to it, the core difference is the wallet file is saved online into the wallet provider's server.
For example: Blockchain(dot)com save their clients' "wallet.aes.json" in their server while Electrum saved the wallet files locally in the user's PC.

Unfortunately, nothing in log tells the cause of the issue. That'll make things harder to check.

I can only suggest to test a few things:
Are those "test" and "test1" wallets created normally?
Is it crashing when backing up 'test1' wallet only or both?
Try to create another wallet and try if it'll also crash when you backup.
Try another directory to save the backup wallet file.

Check the logs if there's any related issue in the last few lines.
Or you can post it here inside [code][/code] tags for others to check,
You do not have to post the entire thing, just the latest session and you can remove PC username, etc. if you prefer.

You can find your debug.log file in %appdata%/bitcoin (paste to File Explorer) or in your custom data directory if set.
Open it as text to see the contents.

For now, you can manually backup your wallet by copying it from "wallets" folder inside bitcoin data directory.
Either the entire folder that has the same name as your wallet or the 'wallet.dat' inside it.
Make sure that Bitcoin Core isn't running while copying the wallet file.

If you have Bitcoin Core, you can query the current target with getblocktemplate "{\"rules\": [\"segwit\"]}" command.

For the difficulty, you can query the exact difficulty with either one of these commands: getmininginfo or getdifficulty
This webpage also allow you to execute some commands including those two: chainquery.com/bitcoin-cli

Some will hate this comment but the topic is pretty much documented: Google search
Or go here for more info (since it didn't made it to Google search): learnmeabitcoin.com/beginners/difficulty (use search above to see more topics like "target")

I checked the tool and all it does is to automatically derive the p2pkh address from the provided private key, it doesn't take an address input.
So you couldn't have used the native SegWit address to sign the message in the first place.

Also, for the address that you mentioned that changed to the one in IanColeman:
It can't be the same address from your BIP44 derivation path since the private key from BIP84 derivation path is different.
If you provided the prvKey of your native SegWit address derived from seed with BIP84 derivation path, the signing tool shouldn't derive your legacy address from BIP44 derivation path.
It may look similar because the tool only derives addresses that start with '1', maybe you just mistook it for the first address or provided its private key.

Make sure to keep the seed phrase safely backed-up before doing that,
even though you want to quit using the wallets, it's best to keep a way to restore the keys in case you need to recover/verify something.

In Guardia, you'll need to logout since you're basically still using blockchain.com's wallet. You can logout in the lowest-most part of the settings.
Then proceed to create a brand new wallet as suggested by others, get a receiving address and send from the restored Electrum wallet using "max" amount.

In Electrum, you can delete the wallet file from electrum data directory (location)
It wont be deleted when you uninstall Electrum so manual removal is necessary if you really need to get rid of it.
(Delete only after sending the funds)

In Blockchain.com, your "wallet.aes.json" file is stored in their server so there's no way to actually delete your wallet.
All you can do is to logout from their wallet and never log-in again. (try their support if it's possible, GL with that though)

Take note that there's still a chance to recover deleted wallet/keys from your drive even after deletion, but that wont be much of a risk if you're still going to use your machine.
Just make sure to "Zero Fill" the drive in time when you need to hand it over to others.

Could be the decimal representation of a private key but the end range can only be 78 characters long.
That FAQ page is outdated by the way, the latest Armory website is "btcarmory"
Another thing is, Armory's first Alpha release was on "Feb 15, 2012", that's 2 years past after you received your Bitcoins.

I'll try to download some old versions of Armory and check if I can find an 80-character private key like described in the old FAQ.
You can also directly ask in Armory sub-board (link) if the new developer 'goatpig' knows about what 'etotheipi' said in the FAQ.

Then, you need to find a good resource with basic and technical articles about Bitcoin,
then just "forum search" what you can't understand; if it's not discussed yet, create a NewTopic.

Other famous cryptocurrencies work differently so you'll need a different resource for those
but some are straight-up copy of Bitcoin so what you'll about to learn is applicable to those bunch.

I'd suggest you to read everything from this website, it's a good start:

• https://learnmeabitcoin.com/beginners/
• https://learnmeabitcoin.com/technical/

It's the derivation from "master private key" to "extended public key".

The xpub/zpub are different because those are derived with different derivation paths which you can check in the wallet's 'Settings' under 'Keystores'.
For example (single-sig Native SegWit): m/84'/0'/0'
Each number separated with "/" starting from "m" (master private key) represents a key derivation index, which different index produce different child key.
The xpub is usually the child key at the last number of the derivation path shown.

That's the expected 'Receive' tab behavior for blank wallets since those rely on active 'hdseed' or active ranged descriptor to generate new addresses from.
Since it's available in your receiving addresses list, the private key is imported successfully.

As for the imported key, the balance should've reflected based from the transactions that it scanned.
If it's zero, it's either the transaction are all spent or it failed to scan some of the transactions.
For the latter, you can try to rescan the blockchain using the command: rescanblockchain

I'm not actually sure that they support it,
it's just that I observed that unconfirmed replacement transactions of non-rbf flagged transactions are available in their blockexplorer while it's not available on others.
That's why it's the only blockexplorer I suggested OP to use in that specific instructions; if he needed to use full-rbf and shared the raw txn, I could've broadcasted it to my node as well.

I see, that's the reason why you missed my reply in the first page regarding that exact procedure.
link: https://bitcointalk.org/index.php?topic=5463909.msg62723483#msg62723483

Well, "estimates" are just estimation based from statistics and shouldn't be relied on with 100% accuracy.
The longer your projection is (like 48hours), the harder it is to make a close estimate since nodes' mempools states in the future cannot be predicted.

As for mempool.space, it seems like they have their own fee rate estimation using their own API  (e.g.: mempool.space/api/v1/fees/recommended)
Based from the result of the above, it's not similar to Bitcoin Core's estimatesmartfee or estimaterawfee.
For accuracy, there's no way to tell or rather, fee estimation algorithms aren't really meant to be accurate, those are just trying to suggest the "best" fee rate for your target block.

Here's the source code of their fees API, BTW: https://github.com/mempool/mempool/blob/master/backend/src/api/fee-api.ts

@SmartGold01 Can you try this?
This will enable you to create a replacement without waiting for it to get dropped, you can try to broadcast it to a couple of nodes.
Bitcoin nodes with full-rbf will still accept it.

• 1. Turn-off your internet so that it wont sync.
• 2. Manually flag to remove the unconfirmed transaction from your electrum wallet by using the console command below;
  Open the console (View->Show Console): wallet.adb.remove_transaction("d5f80b303486f616dc02df5413520b43543b725246161c520816e51aa1f4ebf3")
• 3. Restart Electrum and the transaction should be removed from your history (only in your Electrum),
  while it's like that, create a raw transaction: Add the recipient in "Pay to", optional description and "Amount" (max), then click "Pay..."
  In the 'Pay' preview, set a fee rate that is enough to get it mined in the next block (ETA/mempool fee sliders wont work while offline), then click "Preview".
• In the transaction preview, Click "Sign" (type your password if asked); then click "Add to History" to save it locally.
• To export the Signed Raw Transaction, click "Share->Copy to Clipboard" and paste it to a text file.
• Now try to broadcast that copied raw txn to a blockexplorer/node that supports full-rbf, try in https://live.blockcypher.com/btc/pushtx/

You can also ask us to try to broadcast it by pasting the signed raw transaction inside [code][/code] tags.
Since you already shared the original transaction, sharing the replacement wont pose additional privacy issue.

The computers' names are quite misleading, there's "second computer" and there's "wallet #2".
Do you mean "address #2"? Because "addresses" aren't "wallets", the loaded Bitcoin Core wallet(s) is your wallet.
With that, try to name them: "computer 1", "computer 2", "address 1", "address 2"... etc.

Anyways, since it's descriptor, how did you managed to export the private key?
Because dumpprivkey command wont work on it (there's a workaround but I'd like to ask how you did it)

Descriptor wallets do not support importprivkey command.
If you want to import a single private key to a descriptor wallet, you should use importdescriptor command instead.

For P2SH-SegWit, the descriptor should be in this format (with sample RegTest prvKey):To import it using importdescriptor command, it should be in this format:"#fjl3gf6p" is the checksum which you can get from getdescriptorinfo command, e.g.:

For non-descriptor wallets, all three address types will be derived from the imported private key, including P2SH-SegWit.
Try to add a label to see if it's actually not imported (e.g.: importprivkey "prbvKey" "address #2");
In case the P2SH-SegWit address is different, you may be importing the wrong prvKey.

---

BTW, although there's a conversation here about how to import to Bitcoin Core, the question is quite off-topic.
I'd suggest you to create a new topic in case you need a follow-up to your question.