Right, just the receiving address since there's no blockexplorer that accepts multiple Master Public Keys to get a MultiSig wallet's entire balance.

By saying "internet", do you mean via blockexplorer?
And by saying "balance", do you mean the entire wallet's balance?
If so, most of them do not accept multiple master public keys to check for transactions of your MultiSig Electrum wallet.
It'll only work on standard wallet's master public key.

Otherwise, just paste your MultiSig address and it'll search just like in SingleSig addresses.

Yes, even though it's labeled as "sat/Byte" the actual computation done is actually "sat/vByte" which is what miners use for transaction prioritization.

Or do you mean the transaction slider's estimation?
Because since it's an estimation, it's not 100% accurate, just close to the target block or mempool range.

It can't be done in the GUI but doable in the command line or console.
Just learn to use send command, then to add an OP_RETURN output, simply add a "data" key with the value of your hex-encoded message.

Example command:

---

You can also manually create the transaction via createrawtransaction command to be able to create a transaction with an OP_RETURN output.
Like in "send", it should be added as the value of the "data" key in the outputs.

Example command:

Since it's a manual process, the fee should be computed from the difference of the input's amount and the total amount of the output(s).
On a side note: This method is where the "or it'll be set a fee" warning should be.

In your Electrum version 4.0.2:
It means that you've clicked "Pay" but if "Advance Preview" is enabled, it'll show you the transaction's advanced details instead of sending the transaction,
And if you close that window without finalizing the transaction, the invoice will be labeled as "paid" even though nothing is sent or locally saved.

What this mean is there's actually nothing wrong with your wallet, just an incorrectly labeled invoice.
Always refer to the history tab since it has the actual transactions that count toward to your final balance.

Yes, that is one implementation of Electrum server.
And I'd recommend it if your end-goal is not to use it for personal use, but public.

Plus it's fork is maintained by same developers of Electrum: https://github.com/spesmilo/electrumx
For the set-up, you can refer to its official documentation: https://electrumx-spesmilo.readthedocs.io/en/latest/HOWTO.html

Yes.

Basically the same as: https://coinb.in/#newTimeLocked
Tick "blockheight", then set 7140000 in the blockheight box below it.
As the matter of fact, it produces the same script which uses pubKey in contrary to others which uses pubKeyHash.

Yours is actually standard in the current protocol but your nLocktime isn't less than the LOCKTIME_THRESHOLD which made it "lock-by-blockheight".
So you'll have to wait for block height 7140000 or the Bitcoins locked in that script cannot be spent.

It's a different scenario this time since they do not have to change anything in Bitcoin to include the "uncompressed SegWit" transaction in their block.
All they had to do is accept that said transaction to their mempool to be included to their block.

Only miners with nodes before BIP-65 implementation may consider your transaction non-standard but valid;
But AFAIK (CMIIAW), the block will be rejected by new nodes.

Unfortunately, the "7140000 locktime" isn't the transaction's locktime but the locking script's.

For reference, here's the input's Redeem Script:

So it's just a simple "fix" to a corrupted block.dat file.

Bitcoin Core already has a feature that can detect corrupted blocks or other data and may start with an error.
Running command line option at start like -reindex (depending on the error) is the usual solution to this, no need to change a line code or anything.

What everyone explained is if you want to change in the protocol, because it is what OP sounds like.

That will still allow Electrum to pick other nodes to connect to.

What he meant is same as the "oneserver" setting or command line option which will keep your Electrum connected to a single node, your selected server.

It still accounts to the wallet's total balance, it's not good to tell the user that it's cancelled.
And that would be more confusing since local transactions aren't all dropped transactions.
Some are simply not broadcasted which wouldn't fit to the "cancelled" category.

Lastly, Electrum has a tooltip that explains to the users that the transaction isn't broadcasted yet, both in Android and PC.

The real issue here is if you left an unconfirmed transaction with low fee to pay someone, assumed that it's "sent" then closed Electrum;
That may be that transaction which got dropped from mempools, basically, the recipient didn't receive his bitcoins.
So check if you made a recent deal with anyone.

It could also be caused by sending but instead of finalizing it, you clicked "Save" instead.

You can click each test wallet's "keystore 1" and "keystore 2" to see the cosigners' derivation paths.
You'll just see that Wallet1's 'keystore 1' is Wallet2's 'keystore 2'.
The derivation path isn't the concern since it's based from each cosigner's derivation from the "master private key" to "extended/master public key".

Like in your test, it generated the same wallet since Electrum automatically arranges the public keys in "lexicographical order" when generating redeem scripts so it's not an issue.

That warning is quite exaggerated though,
because Electrum will not let you create the transaction with "0" amount OP_RETURN alone.
And if it has a non-dust amount and you forgot to set a custom change address, Electrum will automatically dedicate a change address if there's an excess amount from the selected UTXO.
And if the custom change address amount is set too low for the input, Electrum will also use an actual change address.

He might have though of it because of his approach on using coin-control.
Notice that even though he set 2.3sat/B (356sat) in the advanced preview, his total fee is 500sat which is the excess from the input, (the excess is added as fee because it's dust)
But if he selected an input with higher amount or lower the amount of the change address, Electrum will use one of his change address to receive the excess, not set it all as fee.

What he/you need to do is to set the custom change address' amount to "!" to send all of the selected UTXO's amount to it in consideration of the fee rate that you'll set.

The rbf setting and the relevant code were all removed from Electrum.
So there's no current way to disable it, forcing it in the config file is useless since it wont point to a valid setting.

AFAIK, for the wallet, it'll only mark it as RBF and show a warning that it can still be replaced by the sender.
I recommend to test it with a small amount first though.

For BIP70 payment requests, I don't know how it'll handle it.

That screenshot shows a different wallet from your previous thread, seems like you have a lot of discovered old wallet.dat file, hmm...
Why is there are URL in the description? And archive shows that it's not an old website.

Anyways, the bottom part is cut off but your other thread shows that your Bitcoin Core is not fully synced.
Wait for Bitcoin Core to sync before declaring that you've found bitcoins or you'll just waste your time recovering the passphrase.
Also do not enable "prune block storage" setting so it wont have to resync everytime you load another wallet file.

You can also use other open-source clients that connects to Electrum server as reference.

Example: BlueWallet - github.com/BlueWallet/BlueWallet/blob/master/blue_modules/BlueElectrum.js

Uhm, but you just posted it.

Anyways, the wallet must have an auto re-broadcast feature since it's "transmitted" by itself without your intervention.

Based from its absolute fee of 460satoshi and the average transaction size (since yours isn't displayed),
your transaction must have been dropped from the majority of the node and your wallet's server's mempool.

You can "rebroadcast" or "delete" it depending on your choice or if it's available in the wallet's option (check the transaction's menu).
The former will resend the transaction as it is but you can only do that once its fee rate is enough to be included to the bottom of the mempools.
The latter will remove the transaction from your history so you can resend another one. (but only if an option like that is available in your wallet)

I have a reply in the link below your reply, but that's only for scanning a raw transaction's QR code.

For the master public key, you can scan it in 'install wizard' menu: "Standard wallet->Use a master key" via the camera icon [] below the area where you normally type/paste the master public key.
For the offline wallet's master public key QR Code, you can display it in the "Wallet->Information" menu using the QR code icon: []