This can work. Cash used properly can be untraceable, just like monero. However, it is much harder to organize and perform anonymous bitcoin/cash trades than it is to perform anonymous bitcoin/monero trades.

There is absolutely nothing private or anonymous about Binance. Their so called "P2P" function is not peer to peer at all since Binance acts as a trusted middleman, and as such can complete monitor and surveil all your activities.

He could still download the new blocks I'm feeding him. Or he could throw away my chain and download a different chain from another peer. But since he isn't verifying anything, how does he know which chain is correct?

Yeah. In pruned nodes, the blocks are downloaded, verified, and then the changes to the UTXO set written to chainstate before the blocks are pruned. In this "don't bother verifying any old data" model, then I can just slip my fake transactions in there and he would be none the wiser.

Assuming I am performing such an attack in order to scam the user in question, then I can fill my fake blocks with real transactions taken from the real blockchain, thereby padding them to full size and padding the UTXO set to full size as well. In fact, I could probably just use the last x number of real blocks and add in the fake transactions - without running a full node he isn't verifying anything anyway. Or conversely if he does want to verify but only the most recent x number of blocks, then I just do the same thing but add my fake transactions in to a historic block he isn't going to verify.

Either way, it's possible to fool anything less than verification from block 0.

There are two main options to anonymize your bitcoin.

The first is mentioned above, and is to swap it for monero. Use one of the peer to peer exchanges or automatic swap services listed here: https://kycnot.me/search?q=&type=exchange&xmr=on&btc=on. Swap it to monero, move that monero around to a couple of different wallets at different times, and then swap that monero back to bitcoin in different amounts in to different wallets using different exchanges/services.

The second is to use the Whirlpool coinjoin implementation via a wallet such as Samourai or Sparrow. You'll need to be running your own node first, though.

However, with both of these options, the centralized exchange in question will still have a record of how much bitcoin you purchased linked to your KYC. Although they might not be able to track what you do with your bitcoin, they will still know you have it. If you want to remove this link altogether, then your only option is to send the bitcoin back to the exchange in question, sell it, withdraw your fiat, and then take your fiat to one of the peer to peer exchanges at https://kycnot.me/ and buy fresh non-KYCed bitcoin.

You connect to my server, and I show you 500 fake blocks with a difficulty of 1 which I just generated a minute ago. How do you know my blocks are fake unless you verify them yourself?

You can actually have 18 outbound connections in total - 8 automatic full relay connections, 2 automatic blocks only connections, and up to 8 manual outbound connections using the addnode command.

I do agree that adding more nodes will make no difference to the speed of the IBD, though.

Rolling a die 500 times to look for bias is grossly insufficient. You need thousands of flips to exclude a small bias from a coin which only has two possible outcomes (which is why it is faster to not bother and just use a Von Neumann approach). For a die with (presumably) 6 possible outcomes you are looking at tens of thousands of rolls.

You're sure about that? As soon as you deviate from a uniform distribution, then min entropy becomes more import than Shannon entropy. What's the min entropy of your biased die? If you don't know what I'm talking about, then how do you know your system is safe?

Ian Coleman did not create BIP39. You might also be interested in this discussion of bias on his GitHub: Bias in dice based entropy

A Von Neumann's coin flip method is better because it is faster, it is simpler, there is no possibility to introduce various biases such as modulo bias, and most importantly, it is verifiably random.

It's been a long time since I last performed an IBD, but I thought transactions were not downloaded or added to your mempool until your node was full synced (since your node will be unable to verify if a transaction is valid until it is fully synced). If that's the case, then blocksonly=1 should make no difference to the speed of the IBD, since you aren't syncing transactions anyway.

We have to trust you on this before downloading the files. And if you make a mistake or accidentally upload corrupted files, then the end user could waste hours or days downloading useless data. This isn't a risk when syncing the blockchain normally.

As I explained above, torrenting then verifying is less efficient than simply using Core to download and verify simultaneously.

Again, trust.

How does torrenting compared to regular downloading make any difference to users with limited bandwidth? They still need to download the same amount of data (more if your torrent is inaccurate for any reason).

Bitcoin mining is a Poisson process. See this previous post of mine:


Given that in two hours you would expect to find 12 blocks, then the chance of not finding any blocks in two hours is 0.000614%. This works out to a chance of 1 in ~162,755. Given that we get ~52,560 blocks per year, then we would expect a delay of at least 2 hours to happen roughly once every 3 years, on average.

In short, bitcoin is functioning as normal.

Loyce is correct. The blocks folder will be ~550 GB. The chainstate, however, is what is constantly being read and written to.

The total size of the chainstate will only be ~9 GB once all is said and done, but it is updated after every block to remove all spent UTXOs and update all newly created UTXOs. Ideally this would be stored entirely within your RAM and only flushed to disk when you shutdown your node, but few people are running Core with a big enough dbcache, and so the chainstate file on your SSD is constantly being updated, especially during the IBD. Once you are fully synced and running, then Core will cache as much of the chainstate as possible in your RAM (up to your dbcache limit), and will optimize what it can cache to RAM (i.e. will preferentially cache newer UTXOs which are more likely to be spent rather than ones which have been dormant for years, specifically to minimize how much needs to be written to the chainstate file).

The more RAM you allocate, the less your chainstate will be written to. The less often you shutdown your node, the less your chainstate will be written to.

You don't need an account - just go to https://mempool.space/ and look at the left side of the screen for the section on transaction fees, and pick an appropriate fee.

If you want to get a bit more complex, then try looking at https://jochen-hoenicke.de/queue/#1,8h. This site shows you a graphical representation of the mempool, which each colored band representing transactions of a given fee. Knowing that each block will remove roughly 1 vMB of transactions from the top of the mempool, you can choose exactly where you want to place your transaction in the mempool and the appropriate fee rate to do so.

Which statistical tests are you going to use? What degree of bias are you trying to exclude? What p value are you happy with? How many rolls does that require?

This method has always "felt" like the best way to turn dice rolls in to bits to me, but I am not a cryptographer and I cannot rule out some bias or other flaw of which I am unaware. And this is why I always recommend that people don't come up with their own ad hoc schemes and instead stick to the tried, tested, and verified methods.

It will be far quicker using a Von Neumann approach to flipping a coin to generate a provably random stream of bits than it will be to even begin to test the fairness of your dice.

You cannot cancel a bitcoin transaction. Once it has been broadcast, it remains valid until the coins are spent in a different transaction, and could be mined at any time (although this won't happen for a long time given your very low transaction fee).

What you can do is remove the transaction from the sending wallet, which will allow you to spend those coins in a new transaction. If the transaction is showing as local, simply right click on it and delete it. This will indeed reset your balances, and you can then make a new transaction sending the same coins (plus any other coins you want to send) with a higher fee.

You don't want to rebroadcast the same transaction. It won't achieve anything and it still won't be mined any time soon.

Both wallets are great. Both offer a lot of what you want from a light wallet, such as coin control, RBF, and so on.

I would say Electrum is probably simpler to use. Sparrow provides a lot of more advanced functions that Electrum doesn't, such as descriptors, which makes the interface a little bit more complicated (but you don't have to engage with these things if you don't want to). Sparrow is easier to connect to your own node, though, and therefore easier to use privately. Sparrow also integrates Samourai's Whirlpool, giving you direct access to coinjoins. Electrum supports Lightning, which Sparrow doesn't.

For most people it will come down to personal preference, but if you want the simplest way to connect to your own node then Sparrow is the way to go.

For the majority of people, the rate limiting step for the IBD is the validation, not the download itself. If you sync via Bitcoin Core normally, then it validates as it goes. If you download this torrent, then you will have to download first and validate second, and it will probably take longer than if you had just used Core to download and validate simultaneously.

There is also zero risk of downloading malware by syncing via Core than there is from downloading random torrents.

Literally the only difference between an inbound and an outbound connection is which node initiated it. Once the connection is made, they function identically.

His node will still relay all transactions and blocks to the nodes he initiated an outbound connection with.

On the newly restored wallet in Electrum, go to the console and enter the following commands:


This will generate another 100 receiving and change addresses.

This is only necessary if your seed phrase is BIP39. If it is, then when you recover it in Electrum, you simply click the box "Detect existing accounts" and it will (probably) find the right derivation path for you.

The only way to know if you used a passphrase is to remember using a passphrase. There will be no indication from the seed phrase or the wallet it recovers that you used an additional passphrase. The only hint will be if your wallet is empty and you expected to find some balance, then maybe (but not necessarily) you are looking for a different wallet with the same seed phrase but an additional passphrase.

Recover your seed phrase on Electrum. In the box that you enter your seed phrase, after you type it it will show up "Seed Type: legacy" or "Seed Type: segwit" underneath if it is an Electrum seed phrase.

I agree this won't make a difference, but you don't need to shut down and reopen to change peers. In the GUI, just go to "Window" -> "Peers", right click on any of your peers, and click "Disconnect". After a few seconds Core will fill the gap with a connection to a new node.

You can also check what kind of download speeds you are getting by going to "Window" -> "Network Traffic".

For SPV wallets like Electrum or Sparrow, the risk is very small. This is because an SPV wallet still downloads headers, so an attacker would still have to have the ability to fake a valid header which involves mining a fake block (and therefore losing the block reward), as well as have the ability to control the multiple nodes these wallets connect to. I'm also not aware of any such attacks on such wallets.

For wallets which depend entirely on one company's servers or nodes though, or closed source wallets that could be doing anything at all, like Trust wallet, Coinomi, Atomic, and so on, then the risk is significant. We have seen endless numbers of users losing coins from using these wallets, and it would be near impossible to prove that such an attack was responsible for any of these losses.