Tor isn't just useful for hiding your IP address, but also your browser fingerprint. Your browser fingerprint includes everything unique about your browser, from what version it is, to what fonts it has installed, to what resolution you are running it in (which is why Tor opens in a window and you should not maximize it), to what extensions you have installed (which is why you should not install any extensions on Tor beyond those which come pre-installed), and so on. By using Tor, your fingerprint matches tens of thousands of other users and makes you impossible to track. By using a Brave, you probably have a unique fingerprint (or share with only a handful of other users) and therefore you are much easier to track.

And then of course there is the issue with cookies, which Tor either refuses or deletes by default, while Brave will store and again will be used to track you. And all the other issues with Brave's awful privacy policy, ads, code injection, and more. Last I checked there was even code from Binance embedded in Brave!

---

Looks like Microsoft have confirmed this was a false positive and have updated Windows Defender definitions: https://forum.torproject.org/t/torbrowser-12-5-6-no-longer-flagged-by-windows-defender/9522/. So you should be safe to update the definitions and then remove Tor from quarantine.

This is poor advice. Using Tor via a browser which is not Tor negates like 95% of the reason you would use Tor in the first place. Not to mention that Brave is terrible for privacy, allows trackers from companies which pay them enough, still collects your data to serve you ads, and more.

I would echo that you shouldn't use Windows, and again, you are not going to get much in the way of privacy regardless if you use Tor if you are running Windows. However, one of the Tor devs is reporting that this seems to be a false positive from Windows Defender: https://forum.torproject.org/t/tor-exe-detections/9508/2. I wouldn't suggest removing the file from quarantine just yet until it has been confirmed that it is a false positive, and more importantly, why it's being flagged as a false positive. However, he also says the 32 bit version is unaffected, so you can just use that.

It's also a good thing for zkSNACKs, since they are using it to attempt to attract investment or even acquisition, and therefore once again line their own pockets at the expense of all their users and indeed at the expense of bitcoin's fungibility itself. Who cares about attacking the very fundamentals of bitcoin when you can make profit from doing so, am I right!?

This whole thread is pretty eye opening: https://nitter.cz/SamouraiWallet/status/1708064789388304815#m

Also:

Lmfao. Same kind of reasoning as "If you don't use Wasabi you have zero privacy." Are the zkSNACKs team actually insane?

Can't wait to see zkSNACKs take a big investment from a blockchain analysis company and then come and gaslight us all about how this great for privacy and great for bitcoin.

So you can confirm that it is currently impossible to withdraw coins from this apparent "decentralized, non-custodial" Mixing Safe?

So I take it they never released this tool they promised to release after I identified this big red flag?

Correct. Although note there are not two separate sliders as the GitHub post you linked. Rather, there is one slider, which affects both Tx0 and the premix UTXOs: https://github.com/sparrowwallet/sparrow/issues/895#issuecomment-1477389172

Also correct.

Yes. There are three fees you need to consider altogether. The first is the fee to Whirlpool itself, which is a flat fee depending on the pool you are joining. This fee is dependent only on the pool you join and does not change with the amount you are coinjoining, so becomes cheaper overall if you coinjoin more in one go. The second fee is the network fee for Tx0, which splits your initial input(s) in to the necessary size to join the pool in question. The more premix inputs you create the larger and more expensive Tx0 will be, but it will still be much cheaper to create one Tx0 creating 20 premix inputs than it would be to create four Tx0s creating 5 premix inputs each. And then the last fee is the additional amount attached to each premix input to pay for its first mix. This is the only one that doesn't get cheaper the more you coinjoin, and will scale linearly with the number of premix inputs you create, as each one needs to pay for its first coinjoin.

But then of course once you've done all that, you get unlimited free remixes.

Let's see.

You can generate a 12 word seed phrase with a valid checksum and use that as the first 132 bits of entropy for your 24 word seed phrase. Concatenate another 124 bits of entropy, and then calculate the 8 bit checksum to give yourself a valid 24 word seed phrase. Take the last 12 words of this seed phrase. Given 12 words have a 4 bit checksum, then there is a 1/16 chance that this checksum is valid. So it won't take long at all to bruteforce a valid combination.

Here's one I just made in just a few minutes:

Both the first 12 words and the last 12 words are valid seed phrases on their own:

---

As I said to OP in another thread, his back up scheme is not great. He is planning to have some words written down, some words stored electronically, a variety of different encryption techniques, a variety of different passwords (are these being backed up too? Where? Or are you relying on memory? (Which is even worse!)), and more. It is far too complicated, and he runs a significant risk of failing to recover from his back ups and inadvertently locking himself out of his own wallets.

If you want to avoid a single point of failure, then you should use a standardized and tried-and-tested method for doing so, such as multi-sig or passphrases.

Yes, although the difference is generally not huge and the block subsidy still makes up the majority of their rewards. If you look at a recent block, for example, you'll see the mining pool earned 6.25 BTC from the block rewards and only 0.12 BTC from fees. Even if you look back a week or so to when minimum fees for the next block were 50 sats/vbyte or more, then the miner is still only earning 0.5 BTC from fees, so less than 10% of their overall block reward.

Yes.

It becomes lower, but not too low. As time goes on, thn miners are using more and more efficient hardware and source cheaper or even free electricity from renewable sources, allowing them to continue to make profits and operate despite their rewards falling. Indeed, global hashrate is currently at an all time high, around 410 EH/s.

Each Whirlpool coinjoin has two inputs which are brand new entries to the pool, and these are the two that pay that transaction fee for the coinjoin. In a 5-input-5-output coinjoin, then 3 UTXOs will be free remixes. In an 8-and-8 coinjoin, then it will be 6 UTXOs which will be free remixes. So yeah, if there is a majority of 5-and-5 coinjoins, then the relative speed of free remixes will be slower than if there was a majority of 8-and-8, for example.

Having said that, I don't know if it is these new larger coinjoins, if it is more and more people using Whirlpool, if it is just my own bias, or some combination of all of these, but I am getting more free remixes more quickly these days than I did, say, a year ago.

I've not heard this before - I'm pretty sure it has to have reached the set time or the set block height, with no adjustments. Indeed, I just tried to broadcast a timelocked transaction on testnet, timelocked both 1 minute in front of my adjusted network time and also 1 block in front of the current block height, and both were rejected.

You can see if we are mining blocks faster than average by looking at this page: https://newhedge.io/terminal/bitcoin/difficulty-estimator

At the moment, we are only two blocks behind the number of "expected" blocks. In other words, we are mining blocks at almost exactly a 10 minute average, and are only very marginally behind where we should be. The current predict length of this difficulty period is 14 days and 30 minutes, when it "should" be 14 days exactly. So no, no sudden surge in miners or hashrate.

You will occasionally see on that page that we are dozens of blocks ahead or behind of where we should be, and as a result we will then have large difficulty adjustments of several percent. Not at the moment though.

No. They are made by hashing the public key.

Pooya87 has explained the difference between hashing and encryption on the previous page: https://bitcointalk.org/index.php?topic=5468186.msg62907603#msg62907603

Encryption is a two way process, where anyone with the decryption key can decrypt the result and obtain the original message. Hashing is a one way process, which is not reversible, which outputs a message of a fixed size.

If you know an address, you cannot calculate the public key, because the address is hashed, not encrypted. It is a one way process which is not reversible.

Still, better to use real examples so OP can test the examples locally if they want to. For example, the valid public key based on your x coordinate is:

Take RIPEMD160(SHA256(public key)):

Add the network byte 0x00:

Take the double SHA256 hash of this:

Take the first four bytes of this string as a checksum (0x3F53E136), and append it to the public key hash:

Encode in to Base58 to get your address:

Then I go and recover one of my other back ups and use it to replace the lost back up. You should never only have a single back up.

Then use a passphrase or multi-sig. Then the theft of one back up is insufficient to compromise your wallet and steal your coins.

This is an bad idea. Overly complicated, zero redundancy, significantly increases the chance that you are unable to recover your wallets. And where are you planning to back up your strong password?

Even if coinb.in disappears and you don't have a copy, the addresses it creates follow a simple script in order to be timelocked. I explain the script in this post:


Given that, all you actually need to provide is a signature for the original private key and you will be able to sign transactions from this address, just as you would from an old school P2PK address. The rest of the script executes automatically.

Which makes no sense. It does not matter what order you put the transactions in, the space they occupy remains unchanged.

Looking a bit more closely, the transactions in the invalid block are simply ordered in terms of absolute fee paid, from lowest to highest, which is why they are all out of order. Most (or even all?) miners usually order transactions from highest fee rate to lowest fee rate, with the caveat I explained above regarding parent and child transactions being packaged together as one. But the invalid block also contains a number of CPFP transactions, as I've outlined above. So at some point they picked a perfectly valid block template in the usual way, considering parent and child transactions as packages, but then prior to attempting to mine it resorted the whole block in to an invalid order. Makes no sense, and makes even less sense that they are experimenting with this kind of thing on mainnet and not testnet.

Here's the raw code of the invalid block: https://farside.co.uk/blocks/809478invalid.txt

The issue is that they included lots of transactions in the wrong order.

When a parent and child transaction are both confirmed in the same block at the same time, then the parent transaction must come earlier in the block than the child. Now look up the following string in the link I shared above, which is the first example of them messing up:

You'll see one of the first transactions in the block (the sixth transaction) uses an input from that transaction, but that transaction itself doesn't actually appear until about a third of the way through the block (as the 1,454th transaction). They included the child before the parent, meaning the child transaction tried to spend a UTXO which did not yet exist. And so the block was invalid.

Another few examples:

So for some reason their sorting algorithm totally messed up and didn't include transactions in the order necessary for the block to be valid.

There will be no repercussions. The nodes they tried to broadcast this block to all rejected it since it was invalid, and bitcoin continue to run as if nothing had happened. This is exactly what is supposed to happen. The real story here is why MARA are testing things on mainnet and not on testnet, but I wouldn't expect any level of competence from the same mining pool which is in cahoots with the US government and OFAC.

There's still plenty to worry about. Hardware is not perfect, and I've had plenty of devices over the years fail on me long before they "should" have. There are also plenty of other components in the hardware wallet which could fail before the storage. There are lots of reports from Ledger and Trezor users of the screens failing, for example.

It shouldn't be. It should be backed up physically on paper. Good quality paper and ink stored away from extremes of heat, humidity, etc., will last for decades. Laminate it and it will last even longer.

There is an open pull request which will fix the issue here: https://github.com/chris-belcher/electrum-personal-server/pull/289

Unfortunately the main developer of EPS (among other things, such as JoinMarket) - Chris Belcher - is suffering from long COVID and hasn't done any work on any of his bitcoin projects in over a year: https://gist.github.com/chris-belcher/ca5051285c6f8d38693fd127575be44d. I could fork the project simply to update the certificates, but if someone downloads the main version and gets as far as you have, then it's probably easier at that point just to apply the fix yourself than it is to download a fork and start the set up process again from scratch.

Anyway, glad you got it working!

If you would include the rest of my quote, then you absolutely can. There is no scenario where a given temperature will melt stainless steel, but aluminum would survive. There is no need to use multiple different metals for different scenarios, because for the things we are interested in stainless steel will always outperform aluminum.

Well, it depends. "Better" is subjective.

Yes, stainless steel will always survive any incident better than paper. But then it depends on your threat model and your individual circumstances. You can hide a tiny slip of paper in far more places than you can hide a metal plate. You don't need to worry about things like metal detectors. What if there is a hurricane, or a flood, or a fire, or an explosion? Perhaps I want my back up to be destroyed so it doesn't wash up on a street somewhere for someone else to find, or for someone else to find in the rubble. And what's more likely - I spend days or even weeks manually sifting through rubble or exploring the wreckage looking for my metal back up, or I simply go and retrieve my second back up from a different location?

Interestingly, pubkeyhash came before compressed public keys.

While addresses and public key hashes are mentioned in Satoshi's initial v0.1 announcement email, it seems that Satoshi simply didn't know that public keys could be compressed in the way that we do now. The size difference between an uncompressed public key and an address is obviously much greater than the size difference between a compressed public key and an address.

An uncompressed public key is 130 characters. If you want to encode that with Base58Check, then your resulting string is 95 characters.
A compressed public key is 66 characters. If you encode that with Base58Check, then your resulting string is 51 characters.
A standard legacy address is 33/34 characters.

A reduction in size from 95 to 34 (61 characters) is much more meaningful than a reduction from 51 to 34 (17 characters). Would we even have P2PKH addresses at all had Satoshi known about compressed public keys?

That does indeed look like everything is set up properly, so I suspect the issue now is the expired certificates bug. See here for an explanation and a fix: https://github.com/chris-belcher/electrum-personal-server/issues/286

If that doesn't work, then you could try sharing your log file here, as well as enabling logs in Electrum and sharing that too, to see if we can narrow down the problem any more.