Witness data is just computed 4 times lower in "vBytes" (Virtual Bytes) than non-witness data, not all parts of the transactions are Witness data even for SegWit to SegWit address transaction.
And transaction prioritization is based from vBytes not the raw size of the transaction, so SegWit transactions are "virtually" smaller than legacy.

For the confusion, as far as I know, it wont be based from the outputs at all.
So only SegWit inputs counts, Sending to Segwit address while using a legacy address wont count it as SegWit transaction.

I searched the apple app store and there is a "bitWallet™" app (link) that have a "ledger" tab and reviews shows that you can indeed delete keys just like deleting texts.

There are other variations (online and app) that doesn't look like affiliated with each other.
Namely: bitwallet™ (online) and BitWallet (App/online - link), perhaps you've registered to one of these.

You must be talking about the fee-slider when you selected "ETA".
Then it was based from your selected server's node's result for the optimum fee for the target block;
according to ThomasVSomberNight, it's based from this command: estimatesmartfee (you can run it online, the result is in BTC/kB)
Ref-comment: https://github.com/spesmilo/electrum/issues/2447#issuecomment-381366160

I suggest you to switch to "mempool" and use 1mB from tip + a few satoshis for priority transactions, because personally, I find it more accurate.

"Full confirmation" is '1' confirmation, means that it's "mined", the consecutive confirmations required by services are just for safety purposes.

If it wasn't for this thread, I wouldn't find that typo... thanks for that.

The user needs to tick "advanced preview" in the 'Tools->Preferences->Transactions tab' first to enable that behavior.
Otherwise, it will just show the fee slider, amount-to-be-sent, advanced (which will display the preview) and confirmation (send/cancel) buttons.

When did you installed and start mining?
What's your miner, the RPi's CPU?
More importantly, where did you downloaded this "BFGMiner"?

If you need support from those who actually use the software, here's the official thread: BFGMiner 5.5.0: CPU/GPU/FPGA/ASIC mining software, GBT+Stratum, RPC, Linux/Win64
Last update was Dec 2019.

No one will be able to help with those info. Can you describe what happened or the issue?

Is it a coinbase to coinbase account transfer using email address of the recipient (you)?
If it is, the transfer should be instantaneous without fees.

If it's an external transfer to a Bitcoin address, you have to wait for Coinbase to send the funds.
It may take a while since they are batching those withdrawals, plus the current fee is quite high, getting confirmations may take a while.

That's very hard to answer since it never happened to me; perhaps if someone experienced this, he can leave a reply on what happened.

My guesses based from the code: there's no transition from "CLOSING"/"FORCE-CLOSING" to "OPEN" so it's a no.
Channel State Transitions: https://github.com/spesmilo/electrum/blob/master/electrum/lnchannel.py#L98-L126

If it was force-closed by the other party, it will remain open in your client since there's no confirmed closing transaction.
Channel States (read the comments): https://github.com/spesmilo/electrum/blob/master/electrum/lnchannel.py#L83-L85

It's a permission issue then.
Have you tried to run the application installer as administrator as suggested by hosseinimr93 above?

Try Node: aranguren.org.
I can't vouch for the privacy/security but it's reliable enough, the good thing is they still haven't force-closed my long-opened channel unlike others.

Your "HIPS" rules (reference) might have been preventing any application/installer from changing files in your system storage.
You might need to add some folder or file exceptions.

Remember you other thread about the bitcoin.conf file? (/index.php?topic=5262146.msg54824582)
I have found out that you'll get that error if the file is read-only, similar when the app doesn't have write access to a file.

The moment that you've seen a server message means that you've just connected to that server.
It's displaying that message in repeat because you've been connecting to and disconnecting from that server again and again.

There's probably something in your client that keeps booting you out of the server.

Your logs (%appdata%/electrum/logs) should provide sufficient info about the issue (Enable in: Tools->Preference->Write log to file).

I'm getting a different error when the receiver's inbound capacity isn't enough, so it can't be the other party's inbound capacity:


I second BitCryptex's first guess, "Payment Failed. No path found" is most likely an issue with your channel's remote node's liquidity.
And I've been getting that error in testnet before when I have only one channel, probably because not all of the suggested nodes are reliable.

You can use the "Export->for CoinJoin" and "combine" feature.

First, you need to enable "Advanced Preview" in the settings so it will open even when using RBF.
Create a new transaction spending the "other UTXO", send to your desired output (same address or others).
Show the advance preview, set the fee and finalize, click export->for conjoin (copy), do not sign and close the window.

Then hit "increase fee" to the previously unconfirmed tx and set a higher fee, after clicking "pay", advanced preview should open.
Click "combine->join inputs/outputs" and paste the other partial transaction and click load.
Next, click sign (double-check the outputs!) and broadcast it.

The problem is: it will produce two outputs of the same address instead of one since it's basically two transactions merged as one.

If it's a desktop computer, a 1TB hard drive is a lot cheaper than external drives with the same capacity.
Plus it will be faster since it's internally connected.

Why don't you switch the machines?
The capable one as the online computer and that older one as the offline computer.
Because you don't need to sync the offline Armory, it only needs the keys for signing purposes.

For reference: I've successfully reproduced the issue by setting the bitcoin.conf file as "read-only":


If it's missing, core will make one, once he clicked the "open config file" button without errors; if the whole folder was set to read-only (or a permission issue), core fails to launch at all.
So BlackHatCoiner might have set it to read-only for some reason or the file became inaccessible.

The client/wallet have limitations on how many queries it can send without producing issues with the servers.
So if you're expecting "hundred and thousands" of transactions per day, consider BTCPayServer instead.

Or you can run your own server and edit the parameters;
follow this thread's solutions if you prefer Electrum: /index.php?topic=5261764.0

Do you have enough space in your disk? About 300GB+ more free space.
If so, you can consider disabling pruning if your node is pruned ('Settings->Options->Main' tab->Uncheck "Prune block storage to").
Because it might have been downloading the blockchain again instead of just reindex (and may repeat everytime you see that error).

If not pruned, -reindex will work.

Bitcoin core will only change the master key if you encrypt a non-encrypted wallet.
It wont if you've just changed the passphrase.

Does your Bitcoin core's wallet.dat contains the prv keys of your funded addresses in Electrum?
If you have imported random keys from Electrum, then it shouldn't work unless you're lucky to pick the right ones.
If those funded addresses' keys are the ones affected by the corruption, then there's nothing else you can do with that corrupted wallet file.

The other option is to look for the original wallet.dat from Bitcoin core where those prv keys were extracted from, you can import that back to Bitcoin core instead.
Aside from that, I'm out of ideas.

Yes, but not all types of addresses created using vanity address generators.
It's exclusive to SegWit addresses generated from an "Uncompressed Public key".

And yes, now, you cannot import 'uncompressed WIF prv key' as SegWit to Electrum.