Not just those, the hash also matched.
It just wont match with any browser's "find in page" feature because of a hidden whitespace between 'e' and '2' in his quote (forum issue).

Those are definitely the same wallet.dat file and "widely available" online  

We have a bit of an issue with displaying images from imgur that's why those images stopped showing, even after you edit it.
but a user created a community-accepted "official" Bitcointalk image hosting website, here: https://www.talkimg.com/
Reference thread: TalkImg.com - Image hosting for BitcoinTalk

It's fetched from the selected server's Bitcoin Core daemon via estimatesmartfee RPC command.
If ever, blame Bitcoin Core's fee estimation algorithm in "conservative" estimate mode.

To be fair, we can't really blame an estimate for being inaccurate since it's based from the available past and current data from blocks and mempool, not the future.

He specifically asked about using the npub (bech32 encoded) directly without mentioning the private key.
So I've explained that it's not possible with it alone.

Plus we already mentioned that it is possible with the private key.

Although the transaction fee that you've used is close to optimal, it has a series of 9 unconfirmed parent transactions.
Each has a parent with even lower transaction fee.

Here are the list:

• https://blockstream.info/tx/54eae74c1e61035fe290660c5a8125f6ff5355255e7c4f99d47865bae921052e?output:1
• https://blockstream.info/tx/9fc747030390e5a1bc4e5b69bdb41170152e5e6c268768fe150740e8cdb95c65?output:1
• https://blockstream.info/tx/2c761da1b8c933c00a00b7e03b623c0722567e12840fd3fe51d72d3a6bb05329?output:1
• https://blockstream.info/tx/559787a28c50e39ad8ed917aa35b8866b7a8b7eaf1926eb06ef268b1dbe94235?output:1
• https://blockstream.info/tx/707df7920753d837a8d51ecf6adb6e9e0379012800c0ddd5a8c5b36a5a0a8751?output:1
• https://blockstream.info/tx/ce15cfaaf44b1f4bef6c280e8daea43fae9742c57ad67d9fa13b918f5c257a30?output:1
• https://blockstream.info/tx/c5b3503988e6c76bd5fb8dd10b65da6707f2fcc8c1711a5ea076994731cedb9e?output:1
• https://blockstream.info/tx/20371bd71271b9fb2b07173d3a4c285b4be52ada99a5a259f02ccfb2cd49cfc3?output:1
• https://blockstream.info/tx/cd2c45416dceb7f5aa9d72b09905a3faecab00a36ff8cff124859a24b725aa5a?output:1

So, before your transaction can get its first confirmation, the parents should all be confirmed with it or one-by-one from the lowest.

I only managed to add the very first parent transaction to Viabtc's free accelerator since the next should have a confirmed parent first before it can get accepted.
If you want, you can add the next one after the last gets added to their block; otherwise, wait for the average tx fee to lower to sub 30sat/vB.

I did a few searches and it seems like it's not possible to get a standard Bitcoin address from the "npub" alone.
It appears that Nostr's public key (decoded npub) resembles the "compressed pubKey" of Bitcoin but without the 1byte prefix that identifies if the y coordinate is odd or even.
It's exclusively the x coordinate, so without any information on the y coordinate, you'll have to guess which prefix to use.

Not much of a difference if the reader knows the BIP44 standard which describes each level of the derivation path.
The extra zero is for the 'address_index' if going from seed to private key/address.
Link: github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#user-content-Path_levels

This is quite technical for newbies so I've just instructed him to change the "account" in BIP39 tool accordingly where he already successfully derived the address of "Ethereum 1".

The path you've given him should be correct without a doubt if it's his "Ethereum 23" wallet.
because as I've mentioned, each of those ETH wallets in the 'accounts' tab are derived with successive 'account_index'.

Turning Public keys into Bitcoin address involves hash functions that'll result with specific size which is encoded into an address;
So generally, any input can be turned into a valid address. The issue is you might not be able to spend from it using Nostr public key's private key pair.
I'm not familiar with Nostr so don't count on my words alone.

Anyways, if the private key's size is 256bit, then just encode your private key into WIF (Wallet Import Format) so that it can be imported to almost all Bitcoin wallets.
The wallet will do the job of deriving the bitcoin-compatible public key and address from it.
In that regard, it doesn't matter if your Nostr public key is incompatible as long as your private key is valid.

I doubt it since it's not a good idea to use the same private key on different platforms, it has the same security risk as reusing passwords.

Only if the required storage is accessible and affordable.

For example, the whole 2^65 range would require about 1.2Billion Terabytes of storage to create a database of all the scanned private keys from puzzle1.
If we would include the already-scanned ranges to 2^66, it'll add about a quarter to half Billion or more Terabytes. (depending on their progress)
If there's a company that's able to procure that amount of storage capacity and willing to use it for that sole purpose, then there's a chance.

Note: It's a very rough computation based from the size of raw private key (32Bytes) the amount of keys in the said range (2^65).

The issue is if you do not have an existing channel opened, you'll have to open at least one to be able to send through lightning.
Opening a channel incurs an on-chain transaction and requires confirmations before the channel can be established.
So if you do not have an open channel yet, you'll need to spend as much fee or more to open a channel.
And lastly, the receiver should've an active channel as well with enough inbound capacity to receive your funds.
It's only convenient if you already set these all up while the fee is low.

If you want to experience the workflow, I'd suggest you to test it in testnet. (available only on Desktop)
Start Electrum in testnet mode (instructions), get some testBTC from testnet faucets (links) gather about 0.002tBTC and more for fee.
Then enable lightning in "Wallet->Information", after that, create a new channel in "Channels" tab (View->Show Channels if it's not displayed).
Use "Channels->Settings icon->Submarine swap" or purchase virtual coffee with tBTC from starblocks.acinq.co to gain inbound capacity on the receiver side.

I'd rather create a watching-only wallet in Electrum connected to a public server that I trust than using various blockeplorers and notification tool to monitor a single address from my wallet.
It's less convenient and possibly has worse privacy.

The main purpose of that watching-only wallet is to be a 1:1 copy of the air-gap wallet that can generate all the addresses that it can create.
That way, he'll never have to open the air-gap Electrum wallet whenever he need to create new addresses.
And also, to be able to conveniently create transactions whenever he needs to.

You already informed him that but he's insisting, even willing to add another input with it.
So it may be important like his own non-rbf transaction imported from somewhere using the change's private key.
Without the TXIDs, we'll never know the whole story.

For privacy reasons, Electrum will only use the related coins to the child transaction so it wont link your other UTXO with it.

The option you have is the "manual method" via coin control linked above.
The disadvantage is you'll have to manually compute the total fee of the child and parent transactions by yourself.

Computation is basic math though:
Before that, get the to-be-bumped (parent) transaction's size and absolute fee (electrum displays the size in bytes but it's actually already in vbytes, 'fee' is the total fee, not the 'fee rate')
For example: '250vbytes' and '0.00002500BTC' (2500satoshi)

• Firstly, Create the child transaction as instructed in the link and take note of the pre-computed size in the 'New Transaction' window but do not finish/send it yet.
• Secondly, to get your target fee rate the total size, get the sum of the parent and child's sizes, for example: '250vbytes' + '150vbytes' = '400vbytes'
• Thirdly, with your target total transaction fee rate, '50sat/vbytes' for example; multiply it with that total bytes to get the required absolute fee: 400' x 50 = '20000 satoshi'
  Then, Deduct the parent's absolute fee from the above to see how much you need to add to reach that target, for example: 20000sat - 2500sat = '17500satoshi'
• Finally, set that as the fee of the child transaction or a few sats more if the final size ends up higher, tick "Edit fees manually" in the setting icon (upper-right) to be able to set an absolute fee.

Be careful on that though, since the transaction that you're trying to bump with CPFP may also have an unconfirmed parent (or more) with even lower fee rate that'll make your child transaction useless.
That's because your child transaction has to pay for those too to be able to bump the transaction that you're trying to bump.
So check if its input(s) are all confirmed or if unconfirmed, should have good fee rate.

They intentionally separated the 'Node' from the 'Wallet' when referring to each because those are separate modules of Bitcoin Core.
For example: If the user want to run a node without a wallet, it has an option to do so.

Also, "Bitcoin Core" is the name of a software, the reference client for running a Bitcoin Node and a Bitcoin wallet.
So if they used that name in an article, they are referring to the whole software,
if they used the term "wallet", they are referring to the wallet,
if they used the term "node", they are referring to a Bitcoin node (may be anything aside from Bitcoin Core).

It's very specific though, the link is just for verifying file signature of Electrum binaries.
But it's generally the basic steps so it'll work in other binaries as well with the necessary modifications of course.

For message encryption, here are the steps (since I can't find any for Termux to link):

• After installing GnuPG as described in the first reply, create a new text file somewhere in Termux directory, for example in "Termux/Storage".
  Edit that text file to write the message that you want to encrypt, save.
• Open Termux and enter the command: gpg -a -r <recipient> --encrypt ~/storage/<filename.txt>
  (the recipient can be the email, uid or fingerprint, without the "<>", you can get it from your key-list: -k)
• Then, a "<filename.txt>.asc" file will be created in the same directory containing the signed message.

For anyone who's only interested on only using PGP on Android without GUI, Termux is enough to install GnuPG.
So only the first few steps and a very little amount of storage is required in this use-case.

Simply install Termux, and follow Steps 1 to 4 in the instructions to update and set the necessary permissions.
Then install GnuPG via: apt install gnupg (current version 2.4.3)

After that, it's a matter of using GnuPG in the command line which has an abundant number of tutorials like: /index.php?topic=5240594.0#post_CmdInstruct
Example final result of the tutorial above in Termux:

I've tried the latest release and it does have an option to add a password with "fitting" notes of a BIP39 passphrase.
Reference screenshots:

• 
• 

However, upon testing to create a new address (legacy, since it won't let me until the first SegWit is funded);
I found out that it is still generated without the password that I've set prior to generation of that address, I've tested the seed phrase in various wallets and tools.
And also, below the "Wallet Info" menu, the keypool seems to be unaffected after setting a password.
Lastly, the wallet and its seed are still auto-generated the first time the app is launched.

The former, it'll keep on deleting older blocks to keep the size set by the user.

Bitcoin Core already saved the related transactions in the wallet.dat file so your wallet wont need to rely on the raw blockchain to view the balance or create transactions.
Besides, the "UTXO set" and "block index" aren't deleted with pruning so your node still know the unspent transactions in the deleted blocks.
The issue is when it need to rescan and verify them from the raw blockchain which is needed when importing an address which will cause issues if it has txns from the pruned blocks.

A node with pruned blockchain doesn't have that limitation, it's only applicable to newly imported address(es) or wallets with transaction history contained in the pruned blocks.
The user can still create new "fresh" addresses whenever he wants.

Another correction is it doesn't select the blocks where the related transactions are, it deletes the oldest to the newest blocks depending on the set size.

Those are already public data stored in every Bitcoin node's blockchain.
If it's possible, then all Bitcoins including those owned by everyone can be "recovered" with that method.

Here's some basic information about how Bitcoin works: learnmeabitcoin.com/beginners/keys_addresses
(you can also go further to "technical" tab to get a deeper understanding on the inner workings of Bitcoin)

Basically,
The data that the wallet needs to own funds is to have the necessary private key(s) to be able to unlock the locking script of those unspent transaction outputs.

As for the seed phrase, the master key that's derived from it (where the private keys are derived from) is computed in a one-way function (HMAC SHA512).
Then from the master private key, the wallet derives the private keys at specific derivation paths (check in each address info in the addresses tab).
By having the wrong seed phrase, the wallet will derive an entirely different master key that'll derive a different set of private keys to addresses.

Then using the info in the link above, you can see that it's not possible to get the private key from the address or public key since it's the very nature why Bitcoin is secure.
And lastly, the transaction's data doesn't contain anything that'll reveal the private key.

He said in first page that the restored wallet is empty.