This is incorrect. The largest block had 12,239 transactions and was mined by F2Pool in block 367853: https://blockchair.com/bitcoin/block/367853. 4075 is nowhere near the maximum number of transactions that can fit in a block, you can fit far more if you only include Segwit transactions with all the transactions having 1 input and 1 output.

Again, this is incorrect. If you want to determine how filled a block is, you're going to have to look at the block size as miners will always attempt to maximize that. Transaction counts are not relevant in this case. Pretty much every single block has been filled with the maximum size, even if it only contains 800 transactions.


Ps. The transaction volume is actually one of the lowest in recent months. Note that the block referenced is quite special, just given to show how meaningless transaction count in a block actually is.

51% attack is possible in practice, just that there isn't any incentives in doing so, for now. Quantum computers are limited in terms of the things that they can do and it won't literally break Bitcoin.

This is incorrect.

The dependencies or the components of Bitcoin Core can still be susceptible to RCE. If you really want to hack some nodes, there are a bunch of possible attack vectors. Limited in effectiveness though, I'll probably just run a few Sybil nodes and that would be far easier.

If you were to break consensus, most people probably won't notice. Nodes would just reject the blocks or transactions.

---

Suffice to say, the thread is becoming filled with more misinformation and some of them don't understand what they're talking about. OP, you'll be better off trying to search about the forum than to continue in this thread.

Just to clarify, I don't mean all of them are inaccurate. There are several decent posts with valid point.

I'm almost certain that there isn't any laws which governs Bitcoin mining? Certain sanctions might prohibit firms based in the US from handling certain transactions but I don't think they have yet to implement it on Bitcoin mining, because it's just ineffective. Seems like they were just doing so to appease the US government. Do CMIIW though.

Anyways, doesn't matter. There isn't any reasonable way to prove that they're not censoring transactions anymore.

It is frankly quite pointless. They are not legally bound to the council nor would they face any repercussions by not being included in it. Having something like this is about as useful as the climate change accords that we've signed so far, though environmental concerns has little to no importance to the miner.

Like it or not, major miners could very well have established a consortium of some sort, that isn't public. It won't be implausible to assume that there is already some degree of centralization even within the mining pools or there is already some influence on them. The proposed council just serves as a PR move, IMO.

No one would be buying encrypted files. There is no way to verify if that is the only copy of the encrypted files or if the wallet file is actually inside.

If you don't want to spend some money or resources to try to crack it, then I would advise you to just leave it at that.

Take a look at the whitepaper: https://bitcoin.org/bitcoin.pdf.

It'll be sufficient for basic understanding of the network. If you need more information, there's plenty on the forum as well. Just Google it.

Segwit was a soft fork.
They recently had a press release to state that they're not censoring transactions anymore and are progressively upgrading their servers to signal for Taproot. I'd give them a bit more time for that. There isn't any politics involved this time unlike for Segwit.

Nodes cannot be attacked to influence the network the same way as miners do. Nodes only enforces the rules locally and does not affect the protocol rules being enforced by others. Even if the other nodes accept a Bitcoin block with a million Bitcoins in block rewards, your node won't, as you're still enforcing the rules yourself, unaffected by what others are doing. As long as your own nodes is enforcing a set of rules, no one else can make your node violate those rules.

That being said, Sybil attack doesn't require any proportion of the nodes to be compromised and that is practically the only attack which uses the nodes. You're confused about 51% attack, I'd recommend you to do up more reading on this matter before posting any further.

First of all, there is no way to verify how they did it. They can simply say that they had a $5 wrench attack on one of their perpetrators and there is no reason for people to not believe it. As long as their story is remotely plausible, then there is no reason to believe otherwise. The most you can do is to eliminate the most unlikely scenarios and narrow it down further.

Tl;dr: Whatever reasoning that they will give can potentially be fabricated, I would take anything that they say with a pinch of salt. There is no reason to prove that they did seize a server or if they did coerce a certain exchange to give back the funds.

Are you having troubles seeing the image in the second post by any chance?

UTXO doesn't get returned. Change is returned to a change address within your wallet.

Using heuristics to determine the wallet owner or whoever it is associated with is fundamentally flawed. They guess the sites that the addresses belongs to by analyzing the transaction paths, for e.g. consolidating them into a single address used by a known service. Mimicking certain behavior of wallets or exchange can mislead the websites into grouping it into the same category as those services. I would take the results with a grain of salt.

From the amount being specified. The command accepts a floating fee with the confirmation target parameter or your own set fees. That is true for 0.21.0. Anything earlier than that doesn't expect a txfee being specified in the command itself, only the confirmation target.

If you set subtract fee from amount, the amount sent to the user is 1BTC - fees. Otherwise, it maintains the 1BTC as the amount and subtracts the fees from your other outputs/change instead.

Not with sendtoaddress, AFAIK. You can make your own rawtx for the purpose.

As far as possible, try to check the addresses on both your main and offline instances; just the first and last few characters will be sufficient.

Master public key will provide zero deviation from both your wallets provided the same parameters but as I have mentioned, nothing can stop a malware on your online computer to change the addresses on it. The addresses that is displayed on your cold wallet will always be correct, but there are still quite a few attack vectors present on your online computer. I'm not sure if I'm being overly concerned about this or not.

You might need to increase the gap limit on your offline computer if someday you don't see the addresses being displayed on your offline computer.

That is how some spy nodes operate. Simply by trying to connect to as many nodes as possible for the purpose of deanonymizing them.
You can... Assuming that you actually can do something with that information.

By and large, transactions has no effect on Bitcoin price or at least having immediate knowledge would have had zero difference. It would be good if you could state something that actually affected Bitcoin's price and was advantages to someone who had that information 8 seconds before the others.
Because most of the people have zero use for it. They're just wasting extra resources for something that is so trivial to them. They don't want to saturate their bandwidth and resources by having to respond to every message that their 10,000 nodes send.

Besides, I probably wouldn't recommend anyone to connect to 10,000 nodes. There reaches a point where your node either runs out of resources or starts to have significantly diminishing benefits to that.

The others are all answered well except for this. Generally, it is okay for someone to assume that the address corresponds to the one that you control. That is, assuming nothing is actively changing the address you're seeing and/or your clipboard. I would assume the worst and attempt to cross-check the address on my cold wallet as well, just a simple validation to check if I'm really sending to the correct address.

The purpose of your online wallet is to check for balance as well as to create a transaction. There is no protection if you've downloaded a malicious version on your online computer or if a malware can change the addresses in your online Electrum instance.

It is not milliseconds in terms of the total time for propagation. It is the milliseconds of difference.
The network is quite robust and there is little to no resource strains when we're met with higher transaction rates;  mempool would simply start to reject lower fees transactions in favour of those that has a higher fee rates. Transactions are fairly small in the first place, so there is nothing with regards to that. There has never been any connection problems within the network, it is extremely robust.

It is simply pointless for you to whitelist nodes, you're giving up the builtin DOS protection as well as your privacy as you're having no delays with transaction relaying. What you want to do, is to establish a direct route to the miners as they're ultimately the ones that decide whether your transaction gets included in their blocks or not. Having faster propagation within the node would only be somewhat faster if your exchange or whoever you're sending to actually cares about unconfirmed transactions, which is pretty much never the case.

Preferred peers are whitelisted peers or outbound peers. I believe the reverse would be simply just inbound peers, makes sense as the purpose of doing so is to enhance the privacy.

Good point. But again, OPAC blocks by Marathon was an experiment that backfired catastrophically so I don't expect people to start openly following that route.

If we were to define coins that way, then we're going to label even the new coins as being tainted (albeit to different extent). Block rewards are considered as a single unit as the fees. It would just be ridiculous to assume that the miners were intentionally laundering the Bitcoins as well. If exchanges were to also label taint on newly mined coins, then it wouldn't make sense at all. If we get to a point where a majority proportion of the coins are "tainted", then Bitcoin is just not fungible anymore or everyone would just give up on the concept.

Both will propagate to a similar extent and be seen by a miner. The premise of a faster propagation comes with the fact that your peers must not be spying nodes and are not interconnected to a huge extent. It does nothing if you're going to relay to nodes that are mostly interconnected to each other; you might as well just propagate to a few nodes and they'll probably achieve roughly the same rate as well. There is no reason to assume that sending your transactions to more nodes would bring about a faster confirmation as the time it takes for it to be propagated to half of the network stands at 3s in 2017, as seen in a research paper.

So long that you can propagate the transaction to a miner within a reasonable period of time, there is no reason to believe that your transaction will always get confirmed slower. There are still various delays even when it reaches the miners; validating your transaction, pushing your transaction to the miners in the pool, (re)assembling the block headers. The inherent delay would already lower the significance of having 1-2 second advantage over the others. Unconfirmed transactions don't mean much to most exchanges anyways.