The user goes by the name "jon", while the current main developer is "goatpig".
It was updated to the latest version quite late but it's an unnecessary worry since Armory has been stuck in that version (0.96.5) for some years.

BTW,
Here's the official source: https://github.com/goatpig/BitcoinArmory | Go to "Releases" and download the source code.
It also contains the build instructions for Linux: https://github.com/goatpig/BitcoinArmory/blob/master/linuxbuild/Linux_build_notes.md

They are talking about mobile Electrum which is the Android version.
Its GUI looks and works different than the desktop counterpart.

Have you tried to use your "Portable Wallet" (the one you've already set-up) on other Windows PC?

Coinomi uses the local appdata folder to store the wallet files and other data
so your wallet isn't even a portable one, but only an executable that runs on a pen drive, the wallet files are actually in the PC where the wallet is created.
Gifting the USB Drive wont give the receiver the funded wallet, at their end, Coinomi will start like it's the first time it's launched.

---

In that specific use-case, you can use Electrum instead.
I has a "Portable" executable which saves the data directory (including the wallet files) in the same drive where the exe is located.
So if you save Electrum-portable in the USB Drive, the wallets that you'll create with it will be saved there as well.

I don't think that's how IQ test works.
The number of characters in the user's posts should be fed to the algorithm, post with at least 500 characters is a good indication of high intelligence.

It's weird because in OP's other thread posted 1 day later, he said that he successfully installed and opened his wallet using 4.2.
Perhaps it's a different machine or a niche case where it works in some W7 versions.

His other thread: /index.php?topic=5390871.msg59609307#msg59609307

So Bitcoin Core is working normally until you replaced the wallet.dat.

Try to open the wallet.dat instead of replacing the current wallet.dat file.

To do that, create a copy of the wallet.dat and rename it into something else like "old_wallet.dat", paste into 'wallets' folder, then use the UI's "File->Open Wallet" menu to open it.
If there's no 'wallets' folder, create one inside your bitcoin data directory.
Also, before doing so, clear the loaded wallets by deleting "settings.json" file from Bitcoin's data directory.

Both are plausible for a standard wallet because it's stored in the drive itself.
Although a strong password may help, the hacker may be able to get it during the times when you type your password.

Do you plan to spend from that wallet or just use it to receive funds for hodling bitcoins?

If the latter, then you can delete the wallet right after saving your "seed phrase", it's all you need to restore the wallet once you decided to spend the funds.
But I'd recommend you to create a "watching-only" copy of the wallet to be able to get new receiving addresses or in case you want to monitor its balance without the risk of your funds being hacked.
Here's how to create a watching only wallet: https://bitcoinelectrum.com/creating-a-watch-only-wallet

If the former, there's a cold-storage option: https://bitcoinelectrum.com/creating-a-cold-storage-wallet-in-electrum
Or create a 2FA wallet that's generally safe even if your Mac is hacked/stolen, but it comes with a fee: https://trustedcoin.com/#/faq#fees

Since you've posted this in Bitcoin Techinical support, I assume that the wallet.dat is from Bitcoin Core.
Then, you said that you "already moved them before the fork" so there is no BCH to claim from that wallet.

If there's no bitcoin in that wallet before the fork then there's no UTXO that will be carried over to the other chain.

My guess is the client wasn't fully synced when you tried to send funds, it shown a balance based from its current height
but when it caught up to the tip, it sync past the point when you spent the Bitcoins which is before the fork so your balance is actually 0

Try to paste the contents to pastebin: https://pastebin.com/
After creating a new paste, link the URL here. You can remove the parts that you do not want to share like PC usernames.

Also, the first reply's question is very important since Armory requires a fully synced - not pruned Bitcoin blockchain and Bitcoin Core client itself.

Perhaps the 64-character hex string is the SHA256 sum of the "weird" alpha-numerical string, used as a checksum.
That wont tell what the weird string is, however, if it's true, then you can deduce that the 64-character string isn't a private key.

Try to turn this into a WIF private key through brainwallet, you might have used it: https://brainwalletx.github.io/
I'd recommend to use it offline.

Which address (script) types have you tested so far?
Have you already tried both compressed and uncompressed WIF?

Yes.
But please tell us the details, what solutions have you previously tried and other related info so that we can have clue about the situation.

As the usual, you can also post the logs for more accurate responses.
Logs are in your Armory data directory named "armorylog.txt" and "dblog.txt".

This has a similar dash positions as a blockchain.info "Wallet ID" (separating three sets of four characters between two longer strings).
But it's only as good as a username, you'll still need the password if it's a wallet ID.

I don't know what the secret is for though, looks like 'something' in BASE64 format to me.

Here's a personal example to show that it will work: 25e3fd298858abc6d5a0ef71d5df49a8c2c4bb96cc21b8c0cc7e49881bbc8252
The inputs are Taproot and P2SH-SegWit, the output is Native SegWit.
(those addresses are already in my profile so there's no privacy issue sharing them)

BTW, the term "address" shouldn't be mixed with "wallet", 'wallet' is your Trezor, 'address' is what you paste/type when sending coins.

That's possible, if the wallet was opened while offline, then it wont be updated with the latest transactions.
So, when you created that transaction, your wallet thought that all those inputs are still unspent but in the blockchain, those are already spent.

Now, it will fail to broadcast whether it's online or offline and failing to broadcast a txn wont automatically save it as a "local transaction".
It must be saved in the 'history' tab because you clicked "save".

Regardless of the reason, you should just remove it and don't expect your coins to return because you already spent those in these transactions:

• ee5ebdcc91311d6ed2e3bdac52e6213b741a60b68b636d2506ab21fbc0fefb81
• 01a967aeb984677593c18034404d64016c76bef641cedef87e8b6f61a6793b79
• c8c6c912285a61c99814aa8ae8081cb7bbbe2f15674fea0a6506804f64b9c3a3
• 2e93d070cb756516d7e9799d4d906bea04067a86d6fed05ed19a9b8ce5908ede
• 5612c98ebf191ca8a7f28cc7f5809d389ee13648fb201454dbf7b0bf7d4c9477

Should be among your latest transactions in the 'history' tab.

That depends on the reason why it's invalid in the first place.

Usually, if it's just a dropped or forgotten to broadcast transaction, then its input(s) will be useable again when removed.
Otherwise, there wont be any coins to "unlock" from that local transaction, for example, if the inputs are already spent by another transaction.

What's the error that you're getting when trying to broadcast it?

For those Windows7 users who want to try to upgrade to 4.2.0~4.2.1, try running Electrum directly from source.
The minimum python version is python v3.8 that's still supported by Windows7, only the bundled python dll to the Windows binaries (exe files) are python v3.9

Follow this guide to be able to run Electrum from source on Windows: /index.php?topic=5224252.msg53806954
But it needs an additional step because that was for old version of Electrum: now, it requires to build "libsecp256k1-0.dll" using "make_libsecp256k1.sh" in 'contrib' folder, however the script wont work on Windows.
There's a pre-compiled 64-bit 'libsecp256k1-0.dll' file provided by SomberNight here: github.com/spesmilo/electrum/issues/5976, but please read his reply first.
Extract it, then paste the file 'libsecp256k1-0.dll' in 'electrum' folder inside 'electrum-master'.

Disclaimer: I don't have a Win7 PC but I've tried running Electrum v4.2.1 with python 3.8 and it still works so it might work on Windows7.

I don't know what's the deal with the migration process but they mentioned this in their support page:

https://brd.com/brd-joins-coinbase
"Several hours to migrate"... If it's a straight-out non-custodial wallet, the funds should've shown-up within minutes.

The keyword is "just in case";
Which can be broken down to a number of sentences that start with "In case".

Examples: In case you need the historical data from the wallet / In case you've accidentally sent bitcoins to it.

That error is usually caused by signing the RAW Transaction with the incorrect private key or it's not fully signed yet (coib.in will show a result even if it's not signed by the key you've provided).

Since the tool is coinb.in, you should use the "verify" tab first before attempting to broadcast the transaction.
A ready-to-broadcast successfully signed Multisig Txn will show: a check symbol with the number of signatures under "Signed?".
You can also check the outputs(s) to see where the transaction is sending coins to (see if you're actually receiving bitcoins with that transaction).

---

However, that setup where you need to sign a MultiSig transaction in order to get a refund is sketchy unless explained why, you two are not the first to mention that.
I mean, why do you need to co-sign? Is their "refund MultiSig address" co-created with your public key? This doesn't make sense.

Here's another similar issue with OP sharing his discussion with the 'service': /index.php?topic=5387764.msg59399757