No harm trying, really but from my experience the bottleneck wasn't with my disk. My Pi decided to throttle severely before I slapped on a heat sink on it. The only time I saw any significant changes to the speed was only with the SSD and the HDD on my desktop, really had no other bottlenecks other than the disk in that case.

Again, no harm trying but the bottleneck is *definitely* not the disk.

You can increase your dbcache for the time being and it'll help with the synchronization a lot more significantly as they're cached in the RAM.

I've got a RPi 4 B and it runs at 75 deg C at stock, not too sure about RPi 400 but do be careful with the temperatures. Keep in mind that the synchronization will get slower as you're approaching the current blocks.

Phishing attacks are always possible, regardless of your wallet.

None of these would have happened if people religiously seek to validate their download. From what I understand, that phishing attack was a popup box from a website and is social engineered to made it seem like it was downloaded from Electrum. Electrum does not display any messages from the servers in rich text anymore.

Bitcoin Core has a parallel download during the IBD with the headers-first synchronization. The speed shouldn't be solely limited to a single peer as the blocks can be downloaded in no specific order, as long as the block hashes are in the headers on the best tip.

Now, with Raspberry Pi, there are several bottlenecks, the USB port (for the external HDD) and the CPU speed. The CPU speed is probably your main problem; Raspberry Pis are very underpowered and it would take days for a completely synchronization without assumevalid (in my case) but some script validations are skipped with assumevalid. Bitcoin Core still has to validate the blocks, transactions, etc and also build the chainstate and index the block. These are heavily reliant on your CPU which is unfortunately not an area Raspberry Pis excel in.

What I've done when I ran a node on my Pi is to synchronize on my actual computer before transferring the entire directory to an external HDD and point my Raspberry Pi's Bitcoin Core datadir at it. This skips most of the heavily validation on the Pi and reduces the time taken for it to be up and running.

From what I can tell in the process, you don't need special skills to hold a heatgun and extract the chip (heck, kraken even dropped the chip!). It's very different from the laser glitching demonstrated on the other secure element. People buying hardware wallets aren't that interested about the difficulty of extracting it but the possibility of doing so.

I agree with HCP. As a HW wallet manufacturer, whose sole purpose is to aim to protect the consumer's security to their fullest extent, it would probably be better for them to highlight this weakness instead of just ignoring it. It would be more irresponsible to downplay something like this by creating an article to say that consumers aren't attacked using these kinds of attack. Given that you're making a hardware wallet which encompasses the physical security, it would be better for them to highlight this. After all, they're still selling these aren't they?

You're actually searching the hash of the scriptpubkey.

There's no compressed public keys back in 2009 and the payments should've been in P2PKH as well; P2PK was predominantly used for the mining rewards and payment through the IP(CMIIW).

---

Electrum did have plans to make descriptors a thing and thus allowing for P2PK transactions as well. I don't think this is implemented yet but its no big deal as well. The difference between P2PK and P2PKH is also the way the  scriptsig is arranged which I doubt Electrum is compatible with as well.

You can't have a dbcache of 160GB when your RAM is only 16GB. I doubt that the client is actually writing anything to the disk especially when it is still starting. Dbcache is flushed when it reaches its limit or during shutdown, hence why if you have a huge dbcache, your shutdown will be much slower.

Replaying blocks is actually the client validating the blocks, evident by the little disk activity and the relatively higher CPU usage.

I assume both of the Electrum clients are on the same version?

It's hard to tell which part of Electrum is throwing that error and what is causing it. Could you go to Tools>Preferences and check "Write Logs to File". Afterwards, restart it and do the same QR code signing again. When it throws an exception, go to your data directory (usually %appdata%/Electrum for Windows) and go into the Log folder. Open the log file with the latest edit and check the contents for the exception. There should be certain files and lines referenced. Omit all the sensitive information (shouldn't be too much) and share only the specific part.

I can't replicate your error no matter how many times I've tried.

Electrum used to use .dat format. The wallet file is called electrum.dat and it was changed with version 2.0 which shifted to a newer format.

What error is shown when you try to restore the wallet? Can you try opening it (with any text editor) and see the contents?

Read the topic again.

Mempool min fee not met means that the transaction isn't accepted or broadcasted by the server as it violates the pool's mempool min fee. The transaction is not in the mempool in the first place. No transaction accelerators*  will work, it isn't in the mempool.

* Unless there is an accelerator which accepts the raw TX, not really sure about this.

You need to create another transaction with a higher fee if you need the transaction to be confirmed now. That is impossible without the private key.

Since you've already destroyed the private key, you have to wait for the minimum mempool fees to be lower than the fees that you've paid for it to be in the mempool. Might be a good idea to have a backup of the raw transaction.

If you don't understand how it works, then Electrum would be the best for you as it simplifies the process by integrating it into the GUI.

Create an Electrum wallet on the offline computer, get the master public key and import it into the online computer. Create a transaction as usual, save the file as a PSBT or use QR code to transfer it to the offline computer, import it and sign it then transfer the signed transaction back into the online Electrum and broadcast it.

You'd be able to do the same thing with coinb.in as well, using the online instance to load the transactions and generate an unsigned transaction, transfer it to the offline computer to be signed with the private key on it.

Dumpwallet was introduced in 0.9.0. You'd have to update your client to do so. If your goal is to find the keys, then you can probably make a backup and upgrade your client.

It is a payment URI.

It contains the information for the payment and it will fill up the details automatically for the user; scanning the QR code with Electrum will result in the payment details being filled automatically, you can specify expiration as well as the amount. The time is in unix, and it is the time for which your payment request is created.

No. Chrome extensions are why people are getting hacked.

Please DO NOT key your private key into any website.

Storing your private keys offline doesn't make anything more secure. You'll probably be looking at making an air-gapped wallet in this case.

2FA is not perfectly bulletproof against malware attacks. There are many variants of malwares which seeks to exploit the user differently and the most common one is a clipboard malware which your 2FA won't protect unless you double check your transactions.

Are you using TrustedCoin's 2FA wallet in Electrum?

.

I believe that decoding your redeem script would help you to see the public keys required for a valid signature and possibly aid you in finding the correct keys to use. Let me know if you don't understand anything about this.

If done correctly, this should be shown on your verify tab:

1000 satoshis/vKB is far from the standard, in fact it is lower than the minimum fees to enter the mempool.

As mentioned, miners have to prioritize the fee rates over the total fees in order to maximize the profit from their very limited block size. It doesn't make sense for them to prioritize total fees, just won't be a good way to maximize the amount of fees collected.

Different wallets/exchange has different fees estimation. Certain exchange tends to overestimate the fees to err on the side of caution as there would be a huge influx of complains if the transaction doesn't confirm within a reasonable period of time due to various external factors. If you're using Coinbase as an exchange (there is a wallet which is non-custodial), it would make sense for them to take a portion of the transaction fees as well; depositing into any exchange/services will require them to move the funds from your deposit address and that could incur a fee as well. Doubt that this is actually the case though.

Fees are not dependent on the value of the transaction. It is dependent on the amount of data within that transaction, you're essentially paying for the data that you're storing on the blockchain. Hence, more inputs/outputs = higher total fees and vice versa.

The fee rate is what you should be looking at. Certain services can provide various subsidies for the user's transaction fees to incentivise them to keep their funds with them or they can afford to do so as they're sending to multiple recipients in the same transaction; (ie. Transaction batching) total transaction size is effectively smaller. Spending 1 inputs to 10 addresses would be far more efficient than 10 different transactions each.

With non-custodial wallet, the fees are defined by the user and with respect to the fees of the transaction in the mempool (paying more in terms of fee rates would likely net you a faster confirmation). I'd probably be looking to do regular consolidation transactions if I were you, by sending the funds back to yourself periodically during period of low fees. This effectively consolidates your multiple inputs into one and if you were to spend it the next time the fees are high, the transaction size would be far smaller as you'll only include one input.