New answers tagged


The blockchain is not determined by a majority vote and does not necessarily change if a significant portion of nodes claim an alternative chain is the main chain. Rather the main chain is determined by each node independently, and all nodes arrive at the same conclusion independently because they all are following the same set of rules. So even if an ...


What you are describing is an eclipse attack -- if the city ran enough nodes with the "faulty" blockchain they could make a node connecting to the network believe that that blockchain was the reality. This chain however would differ in the hashes that it contains so clients would reject it. There are checkpoint hashes within that are hard-coded ...


From the Wasabi docs: There are two ways to confirm that your Wasabi client is connected to your own full node. First, in the Wasabi logs. Once you receive a transaction Wasabi downloads the block containing that transaction from your node, and in the logs you should see: Block acquired from local P2P connection. Second, by checking the connected peers ...


You can't ask for UTXOs from arbitrary nodes on the networks, because there is no way to verify that information. You need to ask for blocks. And a pruned node cannot provide those.


what happens to (those nodes) if they were offline or down at that moment? When each of those nodes comes back online, it will re-connect to other nodes on the network, and request data from those nodes about the most recent blocks. Each node will then validate that data for itself, and once that is finished, the node will be back in sync with the network.


If you're positive your /var/lib/tor/onion_auth/zerotobtc.auth_private file on your client is correct (a single line, containing: {replace-with-your-onion-url-without-the-extension}:descriptor:x25519:{replace-with-your-base32-encoded-private-key}) then the most likely reason it isn't working is your file permissions aren't allowing Tor to read the file. Try ...

Top 50 recent answers are included