You'd probably be looking to incorporate nLockTime in the transaction as well, so the service or anyone else cannot broadcast the transaction before the preset block/unix time. You'll probably be looking at something like GreenAddress, they sign the raw transactions for 2-of-2 account and send it to the user with nLockTime so they can sign and broadcast it if GreenAddress ceases to exist.

There could be some potential privacy concerns with such implementations though, but I assume most users wouldn't really be concerned about that.

If it's that like the image, then it's probably BIP38 encryption. That's the encryption method used for bitaddress.org.

There is if it's above 500 sat/byte or more than 5%, as said in the issue.

The current fiat values isn't turned on by default and actually requires the user to enable an it manually and show the source. I'd think the issue with the fiat accuracy would be the issue that encompasses the entire client, instead of the fee rates only, when enabled, you can put the fiat value and the BTC value would be converted automatically.

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.