There's an issue created here by another user previously: https://github.com/spesmilo/electrum/issues/6664.

It won't be difficult to do it, I'll see if I have the time in the future to do a pull request for this.

I ran Bitcoin Core with a -debug=bench flag.

I didn't try to build the benchmark from the git, doesn't seem to want to build on my server. I'll have to find a way around that.

Sigops stands for signature operations. Bitcoin transactions can contain multiple signature operations depending on the complexity of the script, P2SH output for example could allow you to pad to a fairly high number of sigops but keep in mind that current standardness limits keeps it under 15. Current consensus limits sets it at 80,000 sigops per block.

I saw your topic a few days ago but unfortunately I couldn't come up with any concrete numbers so I didn't comment on it. That being said, here is what I've experimented with so far, do take it with a grain of salt though.

I've run two instances of Bitcoin Core (0.21.0), and the results were fairly similar, this is from my run which I downloaded from scratch. From what I've observed, the timing will vary significantly if you choose to select assumevalid.

   - Connect postprocess: 0.00ms [1.67s (111.43ms/blk)]
 - Connect block: 8429.91ms [341.49s (22766.07ms/blk)]
   - Load block from disk: 5.00ms [0.01s]
     - Sanity checks: 1.00ms [0.00s (0.13ms/blk)]
     - Fork checks: 0.00ms [0.00s (0.00ms/blk)]
       - Connect 2075 transactions: 10465.00ms (5.043ms/tx, 1.571ms/txin) [350.14s (21883.62ms/blk)]
     - Verify 6661 txins: 10465.00ms (1.571ms/txin) [350.14s (21883.75ms/blk)]
     - Index writing: 3.00ms [0.06s (3.84ms/blk)]
     - Callbacks: 0.00ms [0.00s (0.06ms/blk)]
   - Connect total: 10470.01ms [350.21s (21888.03ms/blk)]
   - Flush: 4.00ms [0.08s (5.00ms/blk)]
   - Writing chainstate: 0.00ms [0.00s (0.00ms/blk)]

I think that the IDB download would be far more accurate considering that the transactions are not relayed first to the node but it's verified with the received block. The former would probably have majority of the transactions being in the mempool first and would have been verified already. The numbers can and will be misleading. A single P2SH input can contain multiple Sigops and I can't find a way to benchmark individual transactions or transactions with a single sigops only.

The results would vary quite wildly across different systems, considering the fact that the process is not purely CPU bound but would also involve your RAM with the UTXO set being stored on it, depends on how much dbcache you have. You can try running the secp256k1 benchmark as well: https://github.com/bitcoin-core/secp256k1.

No. Evil fees is accumulated with the number of bans associated with the accounts within the same IP range. It decays with time and it most commonly happens with rotating IP in those countries with lots more noticeable spam, VPN or Tor. You can create as many account as you'd like.

I assume that there is still a small portion, albeit tiny as compared to the transaction fees that would be paid to the miners for either including non-standard transactions and transactions with lower fees. The latter assumes that there are still "Transaction Accelerator" services operated by mining sites.

It doesn't, online or not.

Wallet is not an account. Wallets are just tools for you to spend Bitcoins.
Yes.
No. Your private key never changes.
No. You don't have to specifically connect Ledger to a computer. You can easily create a watch-only wallet by extracting the master public key, I think Ledger allows this and import it into a suitable wallet like Electrum. You only need to know the addresses which can be and will be generated by the seed stored inside your Ledger wallet.

Correct. Be sure to keep Replace by Fee checked.
Yes. Keep a backup of the wallet file from MultiBit just in case. There could also be coins from the other Bitcoin forks as well, Bitcoin Cash, etc. The value of those is quite small and might not be worth your time and effort.

Finalize there:

Sign and Broadcast. You'll only be able to broadcast after clicking sign.

The more you look into it, the more bizarre it gets. The reason why they decided to put $22Million is because some BSV supporter decided to make a tweet that was intentionally made to be out of context[1]. Well, instead of you know quoting someone more renowned within the field. They also decided to link some article on an "exploit" about RBF which is obviously known from the implementation of opt-in RBF. I don't trust CoinTelegraph to be reporting anything objectively considering that they cherrypicked the tweet.

It doesn't have to happen every 2 weeks. Here's a monitor from BitMex[2]. Stale blocks doesn't happen all that often due to the fact that the block propagation timing has decreased drastically, in the earlier stages of Bitcoin, stale blocks happens much more often. It's also to the miners advantage to have their pools as interconnected to the others as possible, FIBRE has reduced the propagation times for miner in this aspect.

I'm fairly sure it has happened before, just that it isn't documented. There can be a variety of factors, ranging from poor propagation, different mempool policy, etc for this to happen. It's rare in this case as Slush didn't see both of the replacement transaction and instead chose to mine the one with the lowest fee.


[1] https://twitter.com/justicemate/status/1352092084346339332
[2] https://forkmonitor.info/feeds/stale_candidates/btc.rss

Not completely wrong. It's important to note that everyone verifies the transaction that they see. The miner's job is to include them in a block with the required POW and thus making it financially and resource intensive to rollback by building another chain on top of that.
No. At that point, the miner's primary source of income will be from transaction fees. In 2140, the total transaction fees would be larger if the transaction volume increases. If it's less than proportionate, Bitcoin will be easier to mine and a balance will be struck between the difficulty and the cost of mining.

Your Ledger device is used to store the seeds. Ledger uses BIP39, a mnemoric standards to convert your seed phrase into a long string of letters called the seed. The wallet uses the seed to derive the private keys using a child key derivation. Wallets do not store your Bitcoins.

Wallets are a way for you to make and sign transactions. They do not contain any Bitcoins. Transferring your seed phrase to another wallet or device merely means that you're transferring your seeds and thus your private keys into another wallet so you can make and sign transactions from there.

Adversary can modify the chainstate as the client does not verify the pre-existing chainstate for it's correctness and allows the malicious party to insert phantom UTXOs, which can result in fake unconfirmed transactions which are directly relayed to them being accepted by their node but will never get a confirmation. Attackers probably won't stand to gain much by modifying the blocks only.

SPV wallets can probably meet your needs and even provide a greater level of security while being way less time consuming and resource intensive. If you want to run a full node but omit the verification part, then there really is no point running one at all.

Yes, they'll be burned and no one else will ever have access to it.

It's not a provable burn though, so outsiders can only assume with some doubt that those funds were abandoned and lost.

The magic bytes are prepended at the start of the blocks on the disk and are in a sense delimiters for the blocks represented on the disk. The magic bytes are not related to the block itself but it's included with every block in the blk.dat[1]. They are not a component in the blocks itself, per se.

It doesn't mean that the magic bytes can only appear at the start of the block though, they could also appear in the middle of the blocks as some arbitrary data.

[1] https://en.bitcoin.it/wiki/Block#Block_structure

Can't see how that's an argument at all. Unless you bring your phone around to dunk in the ocean and lakes, I don't think phones are that unreliable. There's a reason why the wallet always asks the user to write down the seeds on a piece of paper and to keep it safe. In the event of any hardware failure, the user can just restore it to another phone or device.

Old laptops are fairly cheap nowadays, if you purchase one, it could be a good investment and would probably serve as a decent airgapped wallet if you run a LiveCD using a USB flash drive.

At that time, Bitcoin was pretty pseudonymous and there weren't any centralized exchanges. This means that the transactions looks similar to one another and wouldn't provide any clues to which transactions were involved in any exchange. Even now, if you do a P2P exchange, there is no way to tell that the transaction was used in an exchange. It skips the middleman and avoids being mixed to known exchange/services address.

It's relatively easy to bruteforce brainwallet addresses as most of them are hashed with SHA256 once without any additional key stretching. Being able to generate large keyspace at once and given that humans are inherently bad at generating secure passwords, I'd say that brainwallets exposes the user to unnecessary risk for a little convenience.
That probably won't happen. You can't really send Bitcoins to the void unless you intentionally do so and/or the wallet is flawed which is unlikely

Electrum generates a 12 word seed and that would probably suit your use case. You don't have to generate it offline unless you want to make an airgapped wallet, which provides tons of security at a little inconvenience when spending the coins.

No. Electrum is open source and there is bound to have a script to convert the seeds into the BIP32 key easily to extract the private keys. It won't be difficult at all.
Depends. Remember, with the wallet files they can have unlimited attempts till you move your funds. In the future, when you access your wallet, they can also have a window of opportunity to steal your coins. If your password is predictable or reused, it won't be safe. There is also no guarantees that your computer isn't infected with malware already, with antivirus or not.
No. Relying on your memory can be a bit risky though. If you somehow end up with amnesia or just forgetting it, it would be pretty terrible. It's better to keep it on paper somewhere.
They are hardware wallets. They are designed to secure the funds with the most convenience. You can explore air gapped wallets with LiveUSB or an old computer as well. That'll be far more secure than what you have right now and fairly easy to do with the guides around the forum and on Electrum website.

The seed should tell Electrum what kind of seed it is, well assuming it was generated with Electrum. For the master public key, xpub and zpub are different and will result in legacy and bech32 addresses respectively.

@OP, can you see if the xpub on your tails and xpub on the wallet with your master public key is the same? It's located in Wallet>Information. The addresses should be the same for the same xpub, it cannot deviate without a deliberate change in the derivation path.

Public computers infected with malware is not uncommon. Even with LiveCDs, I wouldn't rule out the possibility of side channel attacks especially when everyone has access to it, a seemingly harmless USB at the back of the computer, a VGA splitter, an additional connection between the keyboard and the computer, etc. I don't consider this paranoia as you're supposed to be at least this paranoid if you have to generate a wallet that could possibly contain your entire year worth of wages.

I don't consider public computers safe precisely because it's public. The loopholes for a bunch of vulnerabilities is unlimited. Wiping the entire OS might not be sufficient, especially if there is a persistent rootkit within the public computers. If it's public enough, then I wouldn't believe that there is a chance that it wouldn't be infected. As with your reference to condoms, I don't think that's a fair comparison at all. Small computers like Raspberry Pis are cheap and would probably give you some reassurance. If you're handling Bitcoins that you can't afford to lose, I don't think you would settle for anything less than that.

A cold storage is supposed to be secure anyways. If you consider the wallet being created as a normal wallet then I assume it's alright.