Pretty much sure. If it hasn't changed radically in the past 24h. It's mindless. "You should run a full node, because ... 'privacy'" - which actually is an outright lie.
In what way is that an "outright lie"? Running a full node protects your privacy. It also makes your wallet more secure, which it does talk about as well. The article does not just talk about privacy.
It talks about how beneficial full nodes to the network are and then gives advices how to run a crippled "full node" (pruned, limiting connections, bandwidth targeting and disabling listening, -blocksonly, ...) which isn't a full node anymore - ofc.
How are those not full nodes anymore? None of those things (pruning, limiting connects, limiting bandwidth) are part of the definition of a full node (
https://en.bitcoin.it/wiki/Full_node#What_makes_a_full_node.3F). The only thing that makes a full node "full" is that it has to download, verify, and validate every single block and transaction. Pruning still does that, it downloads every block and transaction. After it checks them, the data is deleted because it isn't necessary to store all of that. It simply won't be able to bootstrap another node, but that behavior is not part of what defines a full node. Limiting connections and bandwidth also do no detract from the behavior that a full node is supposed to have, validating blocks and transactions. blocksonly, same thing. Except it doesn't care about unconfirmed transactions, which is the only "crippling" that I see, but not that much of a problem as it still verifies and validates all of the blocks and the transactions in them.
So again, how are they not full nodes?
So? That's some faking that could skew statistics - or malevolently bind "good nodes" shortly. It's not a faking that could actually pretend in concrete data transfer a true full node. I do not care about faking statistics, I care about the robustness of the Bitcoin network.
Actually they could be used in a sybil attack against one node, where those fake nodes take up all of the connections of a node and serve that node an alternate blockchain.
Furthermore, there could be fake nodes that relay, but don't check. They could just be extra bandwidth that sends blocks and transactions around, but it isn't helpful if those fake nodes are not checking the blocks and transactions to make sure that they are valid. So they pretend to be a full node, but aren't actually doing the job a full node is supposed to.
WHAT? The "you" in de-anonymized is who exactly? The one sending the tx? The node operator? It doesn't matter - why is there a deanonymization you think? I didn't write the fingerprint would contain IP addresses. Fingerprint of a relaying node could very well point to a Bitcoin address (for the receiving funds). Are you telling me Bitcoin addreses break the idea of privacy?
Think before you dismiss something as terrible idea. You sure you want to participate in a technical discussion leading to some advancement or do you prefer a "technical discussion" where you can excel in thinking of ways how something doesn't work or why it's not possible?
The concept I'm talking about has several problems, but deanonymization isn't one of them. Blowing things out of proportion is.
Because as it stands, you would have n transactions (to relaying nodes) for every 1 transaction (which makes it into the block). And who should relay these? ... This is something that probably should be addressed with a sidechain - actually IMHO the perfect use case candidate for that.
There is a deanonymization because there is a list of nodes that have relayed the transaction. The issue comes in with the node that created the transaction. That node would be the first node to attach its fingerprint to the list. Thus all of its peers, when they receive the transaction, can see that only one node has relayed that transaction. It will also know which peer relayed that transaction with one node on its list so it knows the ip address of the person sending the Bitcoin in that transaction. Now those peers know that that node can spend from certain addresses, and because they have the ip address of that node, they can further deanonymize the owner of the node and the addresses in his transactions.