I saw one of your thread inquiring about "pruned blockchain".
Was this happened in that laptop with Bitcoin Core that has "prune block storage to" setting?

Because if it was, it's not just the correct data directory that you need to set to the new installation but the prune setting as well.

Not all the time, it can also be interpreted as your lightning node (electrum client) can't establish connection to the other party.
Most of the time, you'll just have to wait for a few minutes for the status to switch to "OPEN" if there nothing wring with the connection.

I haven't sent amount higher that that with lightning so I haven't experienced it, but I believe it's a config of your channel set by the remote node:

• github.com/spesmilo/electrum/blob/master/electrum/lnchannel.py#L762
• github.com/spesmilo/electrum/blob/master/electrum/lnchannel.py#L961-L966

The process depends on the wallet, some have back button to return to the step where the fee is selected, some haven't.
But in any case, you can just cancel the transaction with undesirable fee that you're creating (haven't broadcasted yet) and you can make another with the preferred fee.

Anyways, the phrases "after consolidating" and "before sending" made me read your question twice.

Is it offline or just "Disconnected" in your channel status?
Because it's available at my end (mainnet).

Recent screenshot (just now):


Probably not, those are hand-picked by the devs, one thing for being active Lightning nodes.

Yes, in V2 or V3, it should be Blocktrail's.
Usually the backup has your two cosigner keys derived from "primarySeed" and "backupSeed", then one pubKey from Blocktrail.

It's unusual to see a second blocktrailKey for V3 backup,
but I'm not very familiar with it so I'd still suggest you to contact the (former?) Blocktrail representative here in Bitcointalk.
Here's the BTC.com/Blocktrail official thread: https://bitcointalk.org/index.php?topic=1572823.0

It doesn't matter.
Each output will be counted as one UTXO whether you sent it through the same address or not;
And those UTXO will always count as one input when used to generate a transaction whether it's received through the same address.

Just take note that addresses are just a way for your wallet to show balances and receive Bitcoins.
In the blockchain, your transactions create/spend UTXOs that has their own locking/unlocking scripts and their respective amounts.
So, for example: for ten inbound transactions that your wallet shows that received by 'bc1pxxx', those will be spent as ten separate inputs when you consolidate.
You'll get the same result if you received those 10 transactions with ten different 'bc1p' addresses.

You basically gain no advantage on using Nested SegWit today.
Its main purpose is to aid the adaption of SegWit without breaking compatibility with most clients which isn't much of an issue today.

You should switch to Native SegWit for lesser absolute fee because the major disadvantage of "not supported by others" was a thing of the past now.
Today, I rarely see any services or wallets that can't send to 'bc1q' addresses; if there is, it should be avoided for being 5-years outdated.
That's still subjected to the services that you're using though.

Additionally, since you're a newbie, you're not prone to sending Altcoins to a Native SegWit address compared to a Nested SegWit.
Since the latter may still be supported by some Altcoin clients or exchange, the former is Bitcoin-exclusive.

The explanation is simple.
Since adding a passphrase to the 'seed phrase' totally changes the 'seed' (more info), it will derive a different 'master private key'.
And based from the algorithm above, a different master private key will produce a different master fingerprint.

Trust wallet doesn't support coin control so manually sending certain amount of BTC wont cause it to spend a specific UTXO.
Since it shows the total amount from those two UTXOs, then your wallet must be missing your old transaction (as seen in the history) but their node's mempool still has it.

My suggestion above is to find a way to sync your transaction history to the blockchain so that your old transaction will show
and at the same time, its input wont be used in your new transaction.
And based from my test, they only have that scroll-down feature to refresh the wallet, try to find if there's any other way to rescan for transactions.

There's only one available UTXO aside from the one spent by your other unconfirmed transaction:
a40fa4553208a4f2f49d44aca8103762c895fbedf06ad0a3e6c79a172799b8d6:10 (0.00095895 BTC)

Since you managed to create a transaction with 0.00186771BTC amount, Trustwallet must have reused the same input as the previous transaction instead of only using your other unspent transaction outputs.
That linked transaction isn't marked as replaceable and Trustwallet's mempool doesn't support full-rbf that's why it rejected the new transaction.

Check your balance first; if it shows more than the correct amount, refresh the wallet tab or restart the app.
If it now shows the correct balance, 0.00095895 BTC, you can now send without that error.

He literally said "I sent the address" right there in the quote.
If it's the QR or a Bitcoin URI, he would've said something like "I sent the QR Code" or "I've shown him the QR Code".
For manual copy of URI with address, it is still vulnerable to clipboard hijacking malware.

Since it's certainly sent to a wrong recipient though malware (or not), you must investigate who's responsible for the lost amount.

Check your conversations for the actual address that you sent him and cross-check it to your Electrum wallet's 'Address' tab manually (don't copy).
("View->Show Addresses" to show the tab)

Then it's simple:

• If it's there, you've sent him the correct address, it's his liability.
• If it's not there, you've sent him the wrong address, it's your liability.

Confirmed Bitcoin transactions are irreversible so discuss who pays who.

Take note that providing screenshot of Bitcoin Core's main tab proves nothing since anyone can do that with any bought, given or tampered wallet.dat files.
Proof can be anything that involves the usage of that address' private key like signing a message or spending an agreed amount of satoshi at a given time.
So for now, we should just assume that it's his lost old wallet as he told. (being skeptical isn't bad either)

Also, the "balance unavailable" has nothing to do with the password since Bitcoin Core encrypted wallets can show balance even if it stay locked.

This will be your main issue.
That "balance not available" isn't too much since after you fully sync your blockchain to the network, that 'triangle ! icon' will disappear.

First of all, not even the developers can recover users' password from a server or some sort, only the owners know about their password.
Bruteforcing is your only option so you need to at least know something about your password: parts of it, some characters, etc. to limit the search space.
Without remembering any info, your only chance is if you've used a very short or simple password that can be bruteforced with 4~9 character combinations or "dictionary attack".
Since you tried bruteforcing already, I'd guess that you've already done those simple bruteforce attacks, if not, try them.

If you do not have the resources, I'd also suggest you to try the mentioned service by others above, the owner has quite the reputation.
He wont accept it though if you do not have the slightest idea of the possible password.

One thing's for sure, Blocktrail/BTC.com never issued P2PKH to their clients, it's always 2-of-3 MultiSig.
So, it's either what you're guessing or the funds are just sent to the derived P2PKH address unintentionally. (like imported the xpub to a wallet and used it to receive BTC)

Is your backup V1 (developer)? Since it has that extra blocktrailKey @m/9999'.
In that case, I'm afraid I'm not familiar with the developer version which may be different than V2 or V3 backups.
Try to contact neutraLTC to check if he knows if the V1 blocktrailKeys are recoverable from your backups mnemonics.

@others
Those mnemonic phrases in the backup aren't actually the BIP39 seed phrases of the MultiSig wallet.
Those are actually what is "labeled" but converted into a BIP39 mnemonic.
In other words, deriving the seed from it isn't the correct way to get the master key and extended keys, the source entropy must be derived from it instead.

Examples:
Encrypted Primary Seed
The source entropy is, which is the "Encrypted Primary Seed":
Backup Seed
The source entropy is, which is the "Backup Seed" (backupSeed - 256Bits):
Reference: https://github.com/blocktrail/wallet-recovery-tool/blob/master/src/libs/blocktrail-sdk/docs/KEYS.md#print-recovery-sheet

That's not the point of the instructions.
It's to explain that even if what he want to do is doable, there wont be any difference when it comes with the number of UTXO that his wallet will receive even if the change is sent to the same address or a change address.

And for some reason, OP is fixated on the thought of disabling change address will fix his high transaction fee issue.
At this point, I wont add anything that's already been explained here.

I wont point you to technical explanations like "there's no addresses in the blockchain" to keep things simple.

That's just clients lacking the use of change address, even if it's sent to the same address, it still the same as sending it to a change address.
That change will be a UTXO that your wallet will spend in the next transaction.
So you basically used 1 UTXO and gained 1 UTXO either way.

Seems like you're pointing your frustration to the wrong feature because having more UTXO to spend just means that you've been receiving lots of transactions.
More inbound transactions = more UTXO to spend.

I don't get it, in the first version of Bitcoin, it's already using the same UTXO model.
The only thing that's changed is the amount of transactions that you've been receiving.

Okay, there's a way to do that in Electrum  
You do that by importing a single WIF private key to Electrum by selecting the option "Import Bitcoin addresses or private keys" when creating a wallet.
You can click the "info" tooltip above it to indicate the address type.

But take note that receiving everything to that single address or receiving the change to that same address wont do any difference.
Each unspent transaction output (UTXO) still counts as one "coin".

That means that the 4-word mnemonic backup is invalid, as expected.

For the "wallet.aes.json" file, you'll have to download it from their server using "download-blockchain-wallet.py" script from btcrecover but it also requires email authorization since they wont just provide something sensitive without verification.
AFAIK, they provide that file to users in the old version after creating a wallet, try to search if she still has a backup/email of it.
You'll also see the contents of the 'wallet.aes.json' file if you put your wallet ID in this URL: https://blockchain.info/wallet/00000000-0000-0000-0000-000000000000?format=json (replace 0's with your Wallet ID)
But then again, it will only work with accounts without a linked email address or it will show something else if the session (IP & browser) isn't verified yet with your email.

Anyways, they have issues with authorization email most of the time.
Try their support if they can verify that you have the correct email address and it's just their system that cannot send the email.

That's still good news, since you have the password.
The '2FA code' only comes after that 'email authorization' if she enabled it.

I'm not using it so I can't give elaborate answers
but that's a payment processor, not an Electrum server implementation like ElectrumX, electrs, Esplora or Fulcrum.

The connection of Electrum wallet to BTCPayserver isn't the same as the connection between Electrum client to a server (Network setting).
It requires your master public key since it needs it to generate new addresses for you.