Okay, so this is the reason why there's always a "The swap server errored or is unreachable" error whenever I try using submarine swap.
It would've been great if this info is mentioned in the release notes, though.

If you decided to follow the initial instructions in the first reply,
it should be noted that a newly opened lightning channel in Electrum doesn't have any inbound capacity.
And opening a channel requires a minimum amount of Bitcoins that you'll use to fund your channel's initial sending capacity.
(depends on the remote node: 0.002BTC+ and on-chain transaction fees)

In other words: you'll need on-chain funds in Electrum and you cannot immediately send your bitcoins from Breez via LN
without spending your sending capacity first or by using Electrum's "submarine swap" feature to gain inbound capacity.

Yes, it's related to Lightning.
It's a plugin that enables the user to set a custom "swapserver" by adding the lines below or by using "setconfig" commands via daemon:

•    "use_swapserver": true,
•    "swapserver_address": "swapserver_address:swapserver_port",

By default, Electrum uses Boltz for submarine swaps.
I can't find any official documentation on how to set up the swapserver though.

-edit-
"swapserver_address" changed to 'port' after this commit (in v4.5.1): https://github.com/spesmilo/electrum/commit/f30d81a98fe8d7cde6daae4e15eba7b4852e43d9

Some people claim that they have an account with access after becoming a sponsor so it must be working.
But reason for the waitlist is unknown.

Okay, so one of his option is to wait for the average fee rate to drop below 44sat/vB.
Last week, transactions with even lower fee rate than his got confirmed so he just needs to be patient.

Or if he want it to confirm faster, paying for a legit accelerator services will be expensive for 1000vB+200vB (approx) transactions.
He will have to pay about $500 to those pools.

Issues in the developer documentation such as this should be reported to developer.bitcoin.org's GitHub repository.
But use the search feature in the issues page first for any possible duplicate issue.

Here's the link: https://github.com/bitcoin-dot-org/developer.bitcoin.org

It's his own transaction from 'Wallet A' to 'Wallet B';
Wallet A used the UTXO from the received txn from the tumbler to send that transaction, effectively bumping its effective fee rate.

mempool.space's accelerator needs an account and it need to be activated by them,
mine which was registered about a month ago is still in their "waiting list".

They don't usually drop transactions in that online wallet, even after the 14days default nor even after it reached the bottom of a default mempool size.
Don't expect it to be dropped without any intervention from the sender, they'll have to spend its input to effectively "cancel" it.

You can just create a CPFP transaction to the unconfirmed transaction that's sent to wallet B.
The issue is if Wallet B supports it or if you can at least export its seed phrase (12/24 words) to be able to import to a wallet that can do it.
Example, if you can a manage to import it to Electrum: all you have  to do is to right-click on the unconfirmed transaction and select "Child pays for parent"
to create a children transaction with very high fee rate, then 'sign' and 'broadcast' it.

The incoming unconfirmed transaction from Tumbler to wallet A may not be the only unconfirmed parent of the transaction to wallet B.
It may have an unconfirmed parent as well.

If you're willing to use a blockexplorer to see the "effective fee rate" of all the bundled unconfirmed parent and children transactions,
Use mempool.space and search using the txid of any of the transactions.
There, you'll be able to see if there are even more unconfirmed ancestor transactions and the important effective fee rate of the CPFP txn bundle.
Click "CPFP !" to see how many unconfirmed transactions are bundled with yours.

If there are lots of transactions in the list, that's the cause of the issue and performing (expensive) CPFP to the last transaction is your solution.
Depending on the wallet, steps to perform CPFP may be a simple feature or a complicated manual procedure.

You should click the link to release notes below the quoted message to see all the changes under "Android" and "General".

There are reintroduced features in the new QML Android GUI version that was available in the old Kivi Android GUI.
There also various bugfixes.

The reference "(012ce1c)" next to it points to this commit: 012ce1c1bb6fad43e55ab18e92f85ec7514e96e6

Basically, it's what's described.
It removed "ssl_certfile" and "ssl_keyfile" options in the config file and related code in various features and plugins.

They'll have to update their documentations after this version.

You may have a list of "Transaction ID" and their respective amounts instead of an ECDSA Private key.
Because it's rare to have a backup of a private key that's not in WIF these days, unless it's from the very old wallets.
In case those are TXIDs, the list is useless as a backup; it's more of a transaction history export.

But do not test if it's TXID yet until you've confirmed that it's empty if imported as private key.

OP, your transaction is now confirmed without any intervention or acceleration required.
It's included to a block mined by Foundry USA Pool while it reached the tip of the average mempool.

If someone claimed that they've accelerated it for you, it's may be a lie unless they used an accelerator that's using that pool or the user himself is working for that pool.

Doesn't matter if you can't uninstall it, it'll get overwritten once you install the latest installer version.
Problem will occur if any of the file is launched in the background when you try to start Electrum, so try to restart Windows before installing the latest version if did so.

You can also try the "Standalone Executable" version.
It doesn't have any loose files and should start without requiring you to install it. (but verifying its signature is still recommended)

Yes you can check if your pruned (full) node successfully switched into an archival (full) node, <-use those terms next time.
Enter getblockchaininfo command and look for "pruned": false, in the output.
You can also check it before disabling any prune-related settings and it'll show as "true".

I've seen 3-4 topics similar to this one, they will actually ask the user for a "return address" where the bitcoins will be sent, though, the txn fee will be set by them.
In the older threads, the fee rate is even lower than OP's transaction.

Here are some examples:

• https://bitcointalk.org/index.php?topic=5477686.0
• https://bitcointalk.org/index.php?topic=5475891.0
• https://bitcointalk.org/index.php?topic=5465650.msg63376902#msg63376902

For that, refer to "policy.h": https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h#L26-L27C1

After SegWit upgrade, they've set the value in 'weight' instead of raw Bytes, that's 400000WU or 100000vB.
So, refer to the transaction's weight or virtual bytes instead.
Your example is still within standard range (if you meant 51.044 vkB).

Found the source: https://raw.githubusercontent.com/EAWF/BTC-Toolbox/3938785f186c76598989cc0aa017ad351483d3b1/Images/KeyDerivationTechnicalOverview.png

It was added to the repository with this commit: https://github.com/EAWF/BTC-Toolbox/commit/3938785f186c76598989cc0aa017ad351483d3b1
But is was removed by the uploader for a slightly insignificant reason, some surviving image copies in Reddit show that it's uploaded by the same user.
Link to the commit that deleted it: https://github.com/EAWF/BTC-Toolbox/commit/f75e2b352ec9facc8d2da52b5ec303fb280c3298

Check your peers' ping first if it's really the cause of your slow IBD:
Click the network icon below and select "Show peers tab", or click "Window->Peers".
Or via command: getpeerinfo

It'll only be slow if you're exclusively connected to very slow nodes which rarely happens;
Most of the case, it's the hardware and node settings.

The comments in "random.h" code conveniently answers that question.
Link: github.com/bitcoin/bitcoin/blob/v26.0/src/random.h

You can post that as a new issue as "Feature Request" with "Feature" label in Bitcoin's GitHub repository.
But make sure to search for possible duplicate issue first before posting it.

In their new wallet version, that would be the users' BIP39-compatible backup phrase that can be restored pretty much anywhere.

Yours, the old version, however do not have a choice but to rely on their support.
Your 17-word account backup phrase is just equivalent to your walletID and password.

The correct address should be the one provided by vjudeu from Bitcoin Core's decodescript command.

To spend it, you'll basically have to do the same as your previous transaction, but for SegWit:

Your previous transaction's scriptSig "0x0451027551" is used as Witness.
But in P2WPKH spend, the number of stack items must be indicated followed by those stack items with their respective sizes.

Transactions:
Spent by:   blockstream.info/testnet/tx/1b291f7cf57e827f6e8d1225657264fcee9ad4a8248e769c2788a8196a2bda6b (the example above)
Funded by: blockstream.info/testnet/tx/9ed2228e4ff5e8f50f4e81d3033f948932f508c19dc9965fe887c37c3fc652f0