You cannot separate the coinbase rewards from the transaction fees because they are contained in the same UTXO. If you consider the TX fees to be tainted, then the block rewards are also tainted. Then, we would have no such thing as clean coins. Most do not consider transaction fees as "tainted" and are thus as good as clean or virgin coins.

5000 satoshis per vbyte isn't particularly unreasonable 8 months ago. Though they obviously could've paid lower fees. It can be intentional, or not. There is no point speculating on this.

This topic has been discussed so rigorously and the conclusion is always that no reasonable state or adversary would spend so much resources on trying to stop something so insignificant. Unless you're looking for any sorts of profits, 51% won't work. You are bound to spend a few billions in both the hardware, facilities, electricity and various other miscellaneous costs for such an insignificant attack. The money could be better used in other areas. You COULD diminish the confidence that people has in Bitcoin but another crypto would simply rise again and the cycle continues. Not to mention that ASICs are not that easy to obtain or operate in bulk.

Each node in the network runs their own specific set of rules. If someone runs a node that doesn't follow those set of rules, the other nodes would consider those transactions/blocks,etc violating their set of rules and will not. Majority of the network runs the reference client (Bitcoin Core), for which the rules are defined in the client.
Most high level changes involves quite a bit of discussion either on the IRC or the mailing list. The procedure is outlined in the link below.

https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md
Neither. Each node runs their own set of rules. If a new protocol code change that affects compatibility with older clients is implemented, then the older clients wouldn't recognize the new rules and simply wouldn't follow them, ie. a hard fork.

In the excerpt, the child transaction does not signal opt-in RBF (nSequence of 0xff_ff_ff_ff) while the parent transaction signals opt-in RBF (nSequence of 0xff_ff_ff_fd). By the virtue of the parent transaction being replaceable, the child transaction should also be replaceable.

This means that without your child transaction also signalling opt-in RBF, reference client do not consider inheritance signalling and thus you cannot execute an RBF with that child transaction. You can see how it affects the various clients in that email as well. It isn't really a "critical" vulnerability in Bitcoin Core, it is just a policy that was defined in BIP125 but never actually enforced. It can be problematic for the applications outlined in that email.

---

Just to add. For normal transactions, most users in general either wait for a single confirmation before accepting a transaction. Even if they don't, then there isn't a problem because the vulnerability doesn't allow non-replaceable transactions to be replaced. PR has been merged in the main branch, so should be included in the next release.

I'm currently solomining for fun, with my USB ASICs, connected to ckpool. Just hooked up a packet sniffer and I observed roughly a single mining.notify packet from the server once a minute. The server has no requirement for the miner to discard their current work until the nonce is exhausted. List of merkle branches changes every time the packet is sent to my miner. Take it with a grain of salt though, it might be different for various pools. It is possible for pools to enforce a mandatory change in the merkle branch though it would entail a slightly larger bandwidth and having the miners to discard the work that they've done.

Units of evil applies to the IP range. That would probably result in most IPs being tainted, as long as a few of the IP within that range are blacklisted. I highly doubt you would be able to find any free proxies from a scraper that would allow you to register without any units of evil. They are abused to death and needless to say, I suspect a huge bunch of them are honeypots, intended to log and track those who don't know any better. If we've reached the stage where even IP ranges belonging to residential ISPs are being tagged, then it would be far more difficult to find clean proxies.

I second the sentiments above. Electrum deliberately chose not to implement BIP39 generation into their wallet but only supports importing it. It is designed to dissuade people from continuing to use that as well, either intentionally or not. That is also a reason why SLIP39 support was added, but not the generation of the shares. Shamir Secret Sharing suffers from several shortcomings and it is nothing a simple Multisig can't do, Taproot would make this even better. We've discussed SSS several times on the forum and the conclusion is that it isn't particularly useful for most users.

Which is also a problem. Certain users prefer to have some sort of anonymity when browsing the internet, moreso for Bitcoin related sites. The problem is prevalent in both the IP ranges allocated to regions which is infested with spammers or just Tor exit nodes. From the top of my head, I've seen a few threads where certain users has had difficulties registering without triggering it even with IPs allocated by their ISPs. Neither of which is good and I also don't believe that there would be a better idea than enforcing some sort of payment to stop spams like these.

They aren't. You're looking at the timestamp only. The timestamp of a block is almost always inaccurate because the network allows it to deviate significantly. The blocks that you've highlighted are relayed only a few seconds apart.

Miners won't try to artificially inflate fees. Trying to inflate the fees at the current stage won't work, none of the pools hold a significant portion of the network. Intentionally mining empty blocks would result them in losing out more fees in the long run. Fees are fairly demand inelastic right now, so people are more likely to put off making transactions when fees are high.

Sidechannel attacks like those are quite stupid, if you think about it. Most side channel attacks requires direct access to the device, at the point which the user interacts with the hardware wallet. Your EM probe must be directly on the device at the point of interaction or you risk interference from other electronic devices. Those are POC which realistically wouldn't apply in the real world and are no better than a $5 wrench attack.

Besides, most wallets in this day are not vulnerable to timing attack, because that is quite amateurish and most hardware are hardened against it. As compared to a malware attack, the possibility of you gaining any profits is far lower, because your targets are highly specific and involves you breaking into their house in the first place. It is fairly easy to counter most potential side channel attacks.

That is the trade-off of the current system. There isn't any other feasible way to deter spammers, and removing it completely only serves to worsen the current spams we're seeing. Those affected by this are unfortunately just collateral damage.

The actual purpose is mainly to control spammers, instead of those seeking to evade bans, IMO. There was a huge influx of spam SEOs at the start of the year, with them scraping other posts to try to blend it. Removing the barrier of entry for those IP ranges only serves to increase the spam on the forum and other than monetary disincentives, I don't think there would be a better way to reduce those spams. If you remove the fees completely, you'll most likely start to either see hoards of account farmers or bots every now and then and degrading the experience for everyone.

Most users probably won't care about using the forum, once they see that they have to pay a fee to use it. No matter how much you explain to them, they would probably just be put off by having to pay a fee just to post.

No. It is not a security issue. You'll probably have to see the post referenced below to understand what I'm talking about in relation to the Multisig and normal P2SH.

Collision attack is very different from pre-image attack. In trying to find a collision, we would be finding two of the same hashes when we're searching for the keys. The hash that will be found is completely arbitrary, and the theoretical attack scenario is better described here: https://bitcointalk.org/index.php?topic=5348160.msg57410551#msg57410551.

If you are looking for any specific addresses, you will need to do a second pre-image attack (2^160), so we're finding the inputs that would result in a specific set of addresses. Birthday probability doesn't apply here because we're not looking for random collisions, but inputs that would result in specific addresses.

Check the Tor and Electrum Logs.

Electrum logs are in the data directory, if enabled. Tor's logs are in Tor Browser's settings, if you're running it.

I checked your command again. I'm using this command: electrum-4.1.4.exe -s hsmiths4fyqlw5xw.onion:50002:s -p socks5:127.0.0.1:9150.

I'm not sure if it works for 4.0.4 as well, I don't remember any changes done to that. Do try it and let me know.

Try port 9150? Electrum works with 9150 but not 9050, believe the latter is for the Tor daemon, instead of the browser.

I confirm that hsmiths4fyqlw5xw.onion:50002 is accessible.

It affects multisig, where multiple entities are involved. By birthday paradox, the attacker can run through 2^80 combinations of their public keys with the other party's public key and produce a collision. The victim would be left in the dark, which is why we've pre-emptively introduced SHA256 with P2WSH.

Not really. The conditions are only required provided that the redeem script that you're providing in the transaction states so. If I were to somehow give a redeem script which hashes out to the corresponding hash in the UTXO, then the conditions in that redeem script is considered for unlocking those outputs. For example, if I were to somehow have a redeem script which is a 2-of-3 Multisig and its hash somehow is the same as another completely different P2SH with differing requirements, then by fulfilling the former redeem script requirements, I can spend the outputs tied to the latter P2SH script.

It is a totally hypothetical and incredibly unlikely scenario, but it proves that for a specific P2SH, we can define an alternative script to bypass the requirements in the first place completely.

We define being secure as something that is infeasible with current and future computational capabilities.
Multisig security isn't defined by that. We attack the weakest link; produce a pre-image by having a redeem script that is able to be hashed to the address we desire.** That is far less complex than having to find individual private keys. No matter what kind of requirements you include, if we find a pre-image of a redeem script that hashes to your address and is able to fulfill our own requirements, your security is compromised (don't necessarily have to know any of your private keys). P2SH at it's current form suffers many forms of limitations; requiring 6 signatures makes a transaction unnecessarily big, and computationally expensive.

It is not reasonable at all to demand security levels which leaves attacks *more than* astronomically difficult. That would just be paranoia and a waste of resources.

** This is quite difficult, even for now. I doubt that it would be more difficult than trying to find individual private keys through bruteforce and random combinations (if redeem script is not revealed).

There isn't a lot to hash. Anyways, I don't think ASICs hash merkle root. They only hash the block headers, any CPU can hash the merkle tree in milliseconds so it can be done in parallel.

If you only get the block header, then you can't validate the validity because you are unable to validate anything else in the block that is not within that block header. Then, you rely on the longest chain being valid and follow them, without being able to validate the blocks in that chain.

Merkle root can be valid, even if the transactions aren't.

It depends. There is almost practically no penalty to change the merkle hash of the block since miners should be fast enough to include an alternative merkle root as required. The server may request for the workers to change out the merkle root periodically through mining.notify on stratum for example.

Miners can include any transactions as they wish and it is not a necessity for them to discard the current block and include new transactions whenever they see anything.
No. The chances of you getting a valid block is not affected by the number of transactions or the size of the block. It's common for blocks to be mined within a few seconds of each other as some miners either don't include transactions at all after seeing a valid block on the network (to avoid the risk of including conflicting transactions, while they are validating the blocks) or if the miners are just slow at including transactions in the block.

It's the same.