.
.
.
.
.
.
.
.
.

Seriously guys?! Your posts should be a few inches away from each other!

I think I'll lie low for now.
As much as I want to help with other tech support boards, I can't do that now because someone has been spreading the pandemic there unintentionally.

At least, I'm protected... sniff.

.
.
.
.
.
.
.
.

Yes, That's most likely the case.
Samurai's passphrase is actually "BIP39 passphrase" which will change the derived addresses and keys depending on it.

@LolipopCash if you've used a different passphrase than the one you've entered before and previously sent bitcoins there, that is the issue.
You have to enter the same passphrase when restoring the seed phrase, the PIN however can be different.
If you've sent the bitcoins to your Exodus wallet that doesn't support BIP39 passphrase, then leave the passphrase blank when restoring the seed to Samourai.

Do you have an antivirus?
Some AV are blocking your connection to most/all of the servers and flagging them as "coinminer" or similar threats.

If manually selecting server didn't worked, consider adding an exception for Electrum.

You can use iancoleman's BIP39 tool to generate the keys of a specific index range like 1,000,000+
but that requires you to export your Electrum's "master private key" (the same level of risk as exporting the seed phrase).

If you're interested in the procedure, here it is:

• Download https://iancoleman.io/bip39/'s source code (Offline Usage - below the page) and run it offline to an air-gap machine (never connected to the internet).
• Open/Restore your Electrum to the same offline air-gap machine, open the console and type getmasterprivate() and take note of the result.
• Copy your master private key to iancoleman's "BIP32 Root Key" text box.
• Under "Derivation path", click "BIP32" tab for legacy or "BIP141" tab then select "P2WPKH" in the Script Semantics drop-down menu for SegWit,
  Scroll down to "Derived Addresses" and confirm the first 20 addresses.
• Now to generate the keys of the specific index, type the desired index in "starting from index" textbox
  and the number of addresses/keys in the "Show" text box, then click "more rows".

That's a painstaking manual procedure but if there are just a few used addresses (like 1000's) after each store's starting index, then it's doable.
Just make sure to do the safety instruction I described above (step 1).

Yes, aside from Python v3.8 or versions later than v3.6.1, just the other dependencies that you can install through pip like 'pyqt5'.
But earlier builds doesn't require "libsecp256k1", only when enabling Lightning (until Feb12).

It's WIF (Wallet Import Format), and AFAIK, vanitysearch doesn't have a converter command since it's already included in the result.

If you want to know how, it's not that complicated, you just need some tools for SHA256 computation (Hash online tool) and Base58 encoder/checker (Base58 online tool),
Then, follow these steps:

• 1. Get the private key hex,
  Sample: 4116A49CA05407397C159D9F8EFC32064E3165466173AA26D21DA11A169BF7FD
• 2. Insert 80 at the start of the prv key and 01 if you want the compressed prv key WIF (do not insert 01 if uncompressed).
  Sample Compressed: 804116A49CA05407397C159D9F8EFC32064E3165466173AA26D21DA11A169BF7FD01
  Sample Uncompressed: 804116A49CA05407397C159D9F8EFC32064E3165466173AA26D21DA11A169BF7FD
• 3. Get the SHA256 Hash of the string above (as HEX not text):
  Sample Compressed: 47aa53130b00c52fed1cf223a04bce7a2d083f111ed5b3dcb6a2a23f06dc3c78
  Sample Uncompressed: 1a75a1d066dcc407ac94a8e07042bb3fcf97f0c41b9d23c2ec9b54fc75b8e2c4
• 4. Get the SHA256 Hash of the SHA256 Hash above:
  Sample Compressed: 78a9182fdc5389e180d08702ac1ec0707221c861b08a7c0e3da56465c01104f9
  Sample Uncompressed: 7b376ba10130e9ae74f447847fbc5ae1c076d42efc932e8dc30ca64401835c8f
• 5. Get the first four bytes of the Double SHA256 hash from step4 (the first 8 characters), that'll be the 'Checksum':
  From Compressed: 78a9182f
  From Uncompressed: 7b376ba1
• 6. Then insert the result of step5 after the result of step2:
  Sample Compressed: 804116A49CA05407397C159D9F8EFC32064E3165466173AA26D21DA11A169BF7FD0178a9182f
  Sample Uncompressed: 804116A49CA05407397C159D9F8EFC32064E3165466173AA26D21DA11A169BF7FD7b376ba1
• 7. Encode to Base58 the strings above and you'll get the WIF format:
  Compressed WIF: KyQEYWYtkttfuaMGBqoBqtpkUJ4M8yHKVtQ3pBkXChBXbraGiS2z
  Uncompressed WIF: 5JJxBK2LRu5umY7rfFgTvfvsBGCBTGvYNx9Pqkfrtb2Un7BrosE

If you need to do this automatically, just paste it on bitaddress.org's "Wallet Details" link.

Uhh, why?
WIF private key is already included in the result, it's the second line "Priv (WIF)".
Just don't include "p2pkh:" when copy-pasting, most wallets do not support that address type prefix.

Your post is a bit unclear.

Just answer these questions:

• 1. Is it really "Important Addresses" or "Imported Addresses"? Because there's no Important Address section in blockchain()com site.
• 2. Does the tag after that address said "Non-Spendable"?
• 3. Did you sent bitcoins to that address before or just to your wallet's other addresses?
  (check the address' balance in the 'settings->wallets & addresses')
• 4. Lastly, what's the exact URL of that "blockchain" site?

Answering those will surely solve most of your dilemmas and questions.

Right, the wallet file doesn't contain your bitcoins, it has your keys to be able to spend your bitcoins that are stored in the blockchain.
Copying it over other/multiple nodes won't be an issue.

Yes, but make sure that Bitcoin Core isn't running while copying and pasting the file.
It's fine for non-HD wallet too.

It will trigger a 'rescan' that could take a while to complete though.
Also, do not do that if your client was pruned because it will sync from scratch unless you still have the blocks where your wallet's inputs are.

I arranged the three types based from my preferences (usage and fee criteria):
Actually, there are more. The other '3-prefix' address types are "P2SH multisig address" and other "P2SH scripts" for specific purposes.
And not worth mentioning: the older "non-address" outputs.

Best, Better & Good, in exact order (for me):

• 1. SegWit [P2WPKH-P2SH] '3' address - Because it's compatible with most exchange, payment processors, services, etc. while still benefits from SegWit's features.
  The tx size may be higher than native SegWit but the compatibility is what makes it my most preferred address type.
• 2. Native SegWit [P2WPKH] 'bc1' address - Because it's "SegWit" (as you/others described it)
• 3. Legacy [P2PKH] '1' address - IMO, if your client/wallet supports P2SH Segwit, use it since there's no real advantage on using legacy address instead of 3-SegWit anymore.

---

You might have ticked "Enable output value rounding".
It's labeled as a privacy feature because it may fool forensics on identifying which output is the change.

That's basically a brainwallet, "blue snow" is your passphrase in BrainWallet terms.

It simply computes the SHA256 hash of your text and use it as the 'private key' (HEX) thus,
the same text will always result with the same address and WIF Private key.

Type it here, it'll result in the same HEX Private key (Secret Exponent): https://brainwalletx.github.io/#generator

It depends on your preference, add that if you do not wan't to use your CPU.
Any additional argument after the @set command=vanitysearch -stop -gpu line should work.

Those characters are just the interpretation of whatever text editor that you've used to open the wallet.dat file.

If it's configured to use 'Unicode', 'ANSII' or 'UTF-8', then it will encode whatever it can find that matched the byte-representation of that characters.
Other parts that didn't have any "match" are the '
'.

In short: Your Notepad is guessing the contents of your wallet.dat file.

Yeah, that's a typo (my bad).
See that it's countered after the comma, otherwise, the purpose of that reply wont make sense at all  

It's not the miners who are dictating the transaction fee, it's the Bitcoin users as well as the "fee-rate priority" design.

Updates? Lightning network is now available for some clients (not popular ones) and now on it's way to more maintream clients like Electrum.
An official release should take at least a portion of the small-valued mainchain transactions (hopefully).
But after it made its way to Exchanges and others services (as a Deposit/Withdrawal option), then it will definitely decrease the average on-chain transactions.

Perhaps for now, if there's a maximum fee rate, the priority fee won't reach to a "greedy" level, what do you think?

I'm running it from source so, it's the same link of the 'zip' file you get from GitHub.

If you close your channel, the funds will be back to your mainchain balance;
if you force-close it, the funds will be back after a day.
(may be wrong)

---

I'm getting the same result when sending to a disconnected channel.
But it's not the same error when you try to send to a single PC with multiple instances of Electrum.


I'll retry it periodically or open another channel, might be a connection or routing issue.
Update: Eclair failed to send through lightning too, it worked for me, tried just now (maybe your client was closed for some reason?).

Try to open a channel with (node id): 0269a94e8b32c005e4336bfb743c08a6e9beb13d940d57c479d95c8e687ccbdb9f
I have noticed that Electrum has been using my channel that's connected to that node to purchase virtual coffees instead of the other ones.
That's a random node id result that I got when searching for channels using "suggest" button.

As for the settings, I set all lightning-related to default/blank.
I'm using the 2020 March 18 Build (today's latest available build).

---

At least keep your Electrum online while you're away so others/I can try to fill that invoice.
I've done some test too, I successfully received some satoshi from my Eclair Wallet. [Eclair->Electrum]

@all Try mine instead (use only Electrum):
-Edit-
After 10 hours of waiting, no one have used my invoice, I'm going to close Electrum for now.
BRB after 10-12 hours.

I received that error before when I was using the not-so-latest build, the latest build should show the "no path found" or a specific message.
Are you sure that your channel(s)' status are all Open?

---

I've just tested again, and it worked:
∙