It should return "true" even if the inputs aren't included in a block.
It's probably because the parent is currently "not in memory pool", using sendrawtransaction to the parent before attempting to use testmempoolaccept to the child should work.

Not too low but it's only 20satoshi short to reach exactly 10sat/B for Viabtc's free accelerator, that's unfortunate.

Doing a CPFP will do.
If one of the two outputs is your change, all you have to do is to spend it with a relatively higher fee than the recommended.
Problem is your client, blockchain.com doesn't have "coin control" to be able to select inputs.

If you don't have other unspent transaction outputs (inputs) in your blockchain wallet, any new outbound transaction will be considered as CPFP because it will guarantee that the change of the "stuck txn" will be spent.

Alternatively, if your have other inputs, you can import the wallet's "recovery phrase" to Electrum and spend that transaction's change using these tutorials:

• Restore the backup phrase: https://bitcoinelectrum.com/restoring-your-standard-wallet-from-seed (read note on step4)
• Use Coin control: https://bitcoinelectrum.com/how-to-spend-specific-utxos-in-electrum/

Please be careful with the recovery phrase, read the warnings. Compromising it will lead to loss of funds.

That's technically not possible but since Blue wallet's lightning is custodial, funding the channel is as easy as depositing the change to your "lightning external refill address".

Electrum however doesn't work that way, you'll have to fund your channel(s) through lightning transaction from a third-party that accepts on-chain funds.
It has the "swap" feature but it wont accept small amounts like the typical change and it comes with a (third-party) fee.

In comparison, sending to the same address also "mix" or rather "link" those addresses, blue wallet's lightning refill address doesn't change AFAIK.

Yes, it's made for Regtest because it doesn't retarget in regtest (source), but doesn't necessarily mean that it won't work in testnet or even mainnet.
Your test probably reached the maximum 1million tries since (yes) testnet's difficulty is still too much for a CPU to handle, you GPU won't be used by that command.
You can add "maxtries" to generatetoaddress to increase the number of tries before it give up but you need to be extremely lucky to mine a block in testnet using your MAC's CPU.

I'll leave #2 to anyone who mines in testnet and uses cgminer for CPU/GPU mining.

It's easy if you have the encrypted wallet file and its password. Just paste it in Armory's data directory, example location: https://btcarmory.com/docs/pathing#example
Then start Armory, it will "mirror" the wallet if it has no ".imdb" & .imdb-lock files.

To get the private keys, just proceed to "Export Key List" backup option, it'll work even if Armory is offline.
HCP has a detailed tutorial: Re: is it possible to import Armory wallet into any other wallet?

The way your account got hacked, it looks like a compromised backup phrase. Reason is, anyone who've got their hands on it can just restore it to any wallet that supports BIP39 seed, there's no need to login to their web wallet.

Why is that URL mentioned?
Have you pasted your 'backup phrase' to that site?

You must have heard about "Quantum Supremacy" which will make old unspent P2PK outputs vulnerable.
That includes both old and new reused addresses which have their public key exposed.

But the rumor is more of an FUD since it's still decades before Quantum computers can become a threat, don't sweat it.

Go to "receive" section, tick "Generate native segwit (Bech32) address", lastly hit "Create new receiving address".
It will generate bc1 address even if the wallet is from old version (tested wallet.dat from v0.11.1) or isn't HD.

Fascinating, based from the address' history, it tends to send small amounts from time to time but with change that sends the rest back to itself.
Someone must have messed up coin control or the manually generated txn

It's not about the typical ridiculous fee due to the "congestion" simply because it's impossible to reach that fee with "wrong estimation" for a '1in-1out txn'.
The transaction was obviously created without a change (by accident or with reason) so all of the excess amount were considered as "mining fee".

Okay, now some details connect with each other.

It might be a "local transaction" with low fee rate which was probably rejected by the current server you're connected to;
check if the logo (on the left of the txn) looks like a 'blue computer' instead of 'green check' or 'gears'.
It looks like this:

The one in the image is a "local transaction" which can be deleted using right-click menu, "Remove".
After being removed, you can spend the coins it's trying to spend (read 'till the end before deciding to remove it if yours is a local txn).

The risk here is your transaction could proceed even though it was previously dropped by most mempools, because if mempools' size suddenly became lower, they may re-acquire it from the nodes that kept your txn.
To counter that, you must use at least one input of that specific transaction to ensure that it wont proceed.

To check the transaction's input, double-click the local transaction in the history tab, take note of the input's details (screenshot or copy), then proceed to remove the local transaction,
Now open "Coins" tab (View->Show Coins), and "Right-click->Spend" to the coins that has the same detail as your removed local transaction (CTRL+left click to multi-select before using right-click),
then proceed to the send tab and create a new transaction. Send it to yourself (same as cancel transaction) or to a new payment.
What you want to achieve is to invalidate the previous unconfirmed transaction for the canceled CoinPayments transaction invoice.

May be a "pathing" issue and you're both using a non-default Bitcoin datadir, read this: btcarmory.com/docs/pathing#config-files and point satoshi-datadir to your Bitcoin core's data directory.
Example: satoshi-datadir="E:\AppData\Bitcoin"

If you click "max" after pasting an address in the send tab, is the amount getting auto-filled?
If "0" and you have positive balance, then it must be what ranochigo said, you must have frozen an address or coin.
To check that, open "Addresses" tab ('View->Show Addresses' to enable the tab) and "Coins" tab  (View->Show Coins), look for entries with blue highlight.
Frozen coins will have the highlight under "Output point", not the address.

To unfreeze them, use "right-click->Unfreeze Coin/Address".

That may be an issue if he changed the settings in both PC,
Electrum will default with "spend only confirmed coin" disabled, that will enable new users to spend unconfirmed UTXO.
@Jeffro64 if you've ticked that particular setting and the coin is unconfirmed, disable it to be able to send now.

One important note: Bitcoin transactions can't be cancelled by the recipient.
What they cancelled must be the invoice for the service that you're paying for, so if you haven't done anything and your transaction's fee is "good", then it will proceed if it's still unconfirmed.

Also, check the history tab for transactions related to that service if it's still unconfirmed (with gears icon), make sure that Electrum is online.
If it is unconfirmed, try to use "right-click->cancel transaction" to send it back to yourself, that's if you didn't disabled "use Replace-by-fee".

Might be an issue after the devfee session?
If increasing the page filed didn't worked, try to add --coin eth to your bat file after the algo.

You're also using memory tweak mode, so t-rex.exe should be set to launch as administrator.

You're not sure about that, since your wallet is standard, your wallet must have used "change address" and that won't be restored in a 'watch-only imported' wallet made using the receiving address.
One of your transactions' output must be your change.

Most likely, unless you have set a "passphrase" aka. "extension", "custom word" or "13th word", whatever they call it.

That looks like your previous transaction in your other thread because it was 1-3 days (depending on what's edited) since your last post: /index.php?topic=5311792.msg56374153
and the number of confirmations is just about right.

So if that transaction went through, then you must have already swept the bitcoins.

Note: Their tutorials all explained the "Advanced Preview", but normally and by default in v4.0.9 (or lower?),
it'll just show the standard send dialogue box after pasting the keys, so you must have used it instead and sent the transaction unknowingly.

You have the option to reduce the fee rate to your desired amount through the "Advaced" button when sending transaction, but lowering it way below the recommended fee rate will lead to slow confirmation time.

BTW, IDK if a $5 equivalent in bitcoin is an amount worth 4years of savings.
You must have been mistaken the unit mBTC as BTC, the former is equals to 0.001 BTC; given the amount you've sent, are you trying to spend a 0.1 BTC input?

Another, if your wallet is 2FA (check the title bar for the wallet name if it has "2fa" in it), your txn didn't added an extra output then you must have already paid their service fee of 0.0005 BTC for 20 transactions during one of your previous transactions.

Congrats, there are some inconsistencies though...
The link provided by BitMaxz is simply the same as restoring your seed phrase to Electrum and selecting "disable" when prompted what to do with '2fa'.
It won't accept BIP39 seeds (or even 2fa-SegWit) while your previous posts suggest that you have a BIP39 seed.

How did you solved the problem? This is for others who might encounter / might have encountered the same issue.

You must contact that exchange or wallet's support or in some cases, the 2FA service provider;
Note: bitcointalk members can't help you reset your 2fa aside from providing guides, this forum is not affiliated to any exchange, wallets or services.

Stepping in since you didn't received a reply: Is the wallet named "Coinbase" or "Coinbase Wallet"?
If the latter, you can get it from "Settings Icon->Recovery Phrase"; If 'Coinbase', then there's no way to get the seed phrase since it's a custodial wallet/exchange.

That's the one, you have too many inputs (unspent transaction outputs) making your transaction's size too large for a 6-11sat/vB fee rate;
you see, it's in satoshi per (virtual) byte means that the total fee will be based from the size of your transaction.
Each input will be added to your transaction's size.

Sending it all to the same wallet will consolidate all of those inputs to a single unspent txn output but will still require the same transaction fee as sending it all to your desired wallet.
You can use "coin control" (tutorial) for now and select only 1-5 large value inputs, then leave the "hundred satoshi inputs" to be consolidated (by you) later when the mempools are low.

What you did wrong was to set your mining withdrawals in "frequent-low-amounts" rather than "fewer-high-amounts", the latter should produce less number of inputs.

I assume that you're using a 2FA wallet because the transaction is MultiSig.
Aside from the explanation above, those types of transactions are generally higher in size (bytes) compared to Legacy and far higher compared to SegWit's average virtual size.
The higher the transaction's size, the higher the total fee will be; it's best to send small amounts like that with 1-2sat/vB fee rate when the average mempool size is low.