This wont help you since you already created the wallet via GUI;
But for others who have no access to the GUI, it can be circumvented by using --named arg to set the non-default required name=value pairs after passphrase while skipping the passphrase:

You'll just lose access to coinb.in's server that retrieves inputs for you through that "Load" button as well as its native broadcast, otherwise the offline version will still be functional.
While offline, it wont be able to preload the necessary data in the inputs and set the correct parameters of a valid OP_CLTV input.

Since you're not a tech person,
I'll just provide simple but detailed instructions on what data to add and change in coinb.in for your transaction to be valid while offline.

In "New->Transaction", "Inputs" tab:

• It's should point to the unspent transaction output that you want to spend.
  Both "Transaction ID:" and "N:" have a tooltip that briefly explains what it is by hovering over them.
  First is the "Transaction ID:" which is the TXID of the transaction that funded your timelocked address.
  Next, the "N" (output index) that starts with '0', if your address is the first output, it should be '0'; if it's second, it should be '1' and so on.
• The "Script" is the "Redeem Script" provided to you in "New->Time Locked Address" when you created the address.
• The "Amount" is the amount that you've received.

In "Outputs" tab:

• Just the recipient and amount.
  However, be careful on setting the amount since you wont be able to set the fee manually.
  The fee will be computed based from the input's amount and the output's amount, the fee rate will be computed manually from the final raw transaction's size so leave a reasonable amount for the fee.

Most importantly, expand the "Advanced Option":

• Under "locktime", the value should be edited from '0' to the value of the locktime that you've set or higher.
  If you've used the date and time format, you can decode your redeem script in Bitcoin Core via decodescript command to see its locktime; or use epoch converter.
  If left with default "0", the transaction will be rejected by nodes during broadcast by not following one of these conditions: BIP-0065.

Then proceed to 'Sign' and Broadcast the signed raw transaction to other push transaction services/clients.

Do you mean the "Welcome Screen" or the actual Bitcoin Core installer?
Because the directory indicated in the latter is where the binaries will be saved, it's not the data directory that Bitcoin Core will use.

On the other hand, you can indicate the data directory in the GUI's "Welcome Screen" but it will only be used by bitcoin-qt.
bitcoind will still use the default unless indicated in -datadir arg on in the default data dir's bitcoin.conf file.

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.