I think the point to understand is that 128 bits of security will not be brute forced. The energy required to brute force a single key with 128 bits of security would boil all the oceans on Earth 16,384 times. So until we can construct a Dyson sphere to harvest the entire energy output of the sun, 128 bits is quite safe.

With that in mind, then all the additional security options we have - passphrases, multi-sigs, etc. - are not designed to increase this 128 bits of security (and indeed, as I've explained above, they can't. The final security of a bitcoin private key will never be more than 128 bits.) Rather, they are designed to protect against human error, compromised devices, viruses and malware, and so on.

I'm not aware of any straightforward way to detect whether one of your peers has full RBF enabled or not. The best option if you need to broadcast a full RBF replacement would be to manually connect to well connected nodes which are known to accept full RBF connections (such as https://petertodd.org/2023/why-you-should-run-mempoolfullrbf#full-rbf-peering), or to broadcast via a well connected service which is known to accept full RBF replacements (such as https://mempool.space/tx/push, http://mempoolhqx4isw62xs7abwphsq7ldayuidyx2v2oethdhhj6mlo2r6ad.onion/tx/push).

A press release quoting this moron is hardly conclusive proof of anything.

Regardless, let's take a look at the study itself. It shows that reverse transcription happens (in unstable cells in a Petri dish), which we already knew. It does not show the vaccine changing our DNA.

Here are what the authors of the study say about it:

You know very well from our conversations on other topics, such as about CBDCs, that I do not trust the government one bit. Getting vaccinated has nothing to do with trusting the government, however, but simply understanding the science of vaccines.

Correct.

An attacker brute forcing from scratch (not that anyone would ever do this) would either be generating 256 bit private keys or 128 bit seed phrases. But actually, every seed phrase can generate every possible address if you put in the "right" derivation path.

Yes. There will be literally trillions and trillions of scripts out there which will give the same script hash as your multi-sig script and therefore could unlock your coins. But just like standard addresses, the search space is so astronomically large that a collision will never happen.

The maximum security provided by a 256 bit private key on the secp256k1 curve is 128 bits. This is because the most efficient way to attack a 256 bit private key is not brute force, but by solving the ECDLP, which will take on average 2¹²⁸ operations. So all bitcoin private keys, regardless of how much entropy was used to generate them, will never provide more than 128 bits of security

You can see this in Standards for Efficient Cryptography. SEC 2: Recommended Elliptic Curve Domain Parameters. (Table at the bottom of page 4.)

No. The most efficient way to attack a 2-of-2 P2WSH multi-sig would not be to attack both individual private keys, but to find any other script which has a collision with the SHA256 of your P2WSH multi-sig script. Given the script hash is the digest of a single SHA256, then again, you would expect to find a collision in 2¹²⁸ operations on average.

Still 128 bits.

Yes. Unfortunately the URL o_e_l_e_oastic.space was already taken.

Yes. 10³⁰ is 99.66 bits.

Personally I would opt for 128 bits for obvious reasons, but 100 bits is probably secure enough.

Technically yes, but the final security of your private keys won't be any more than 128 bits.

If your writing is such that these characters are obviously different, then you don't need to. If you are concerned about confusing these characters, then by all means drop them from your character set.

I conclusively proved many years ago that 127.0.0.1 is actually BPIP's IP address:


Therefore korner = suchmoon = Vod = the King of England.

Also completely debunked:


Whirlpool works great. Yes you can be deanonymized if you do something stupid like linking unmixed coins to coinjoined coins, but that is the case with literally every coinjoin implementation or any other privacy technique.

So yeah, to answer OP's question, I would suggest either Samourai or Sparrow via your own node.

Yes, absolutely. Neither Whirlpool nor JoinMarket participate in any blacklisting, censorship, or coordination with blockchain analysis.

A single point of failure.

The main benefit of multi-sig over single sig plus passphrase is that multi-sig does not have a single point of failure. You can use three different devices to generate three different seed phrases, and only move the xpubs between devices in order to generate addresses. The compromise of any one device does not lead to compromise of the wallet. The same is true when spending from a multi-sig - you can keep each set of private keys on separate devices, and so one compromised device never has enough information to steal the coins.

With single sig plus passphrase, you must bring the seed phrase and the passphrase together on the same device both to create the wallet and also to spend from the wallet. If that device is compromised, then your funds are also compromised. The best way to address this is to use either a permanently airgapped computer running an open source OS, or use an open source airgapped hardware wallet such as Passport.

In terms of back ups, then the security and redundancy is comparable between a single sig plus passphrase with two back ups of each component and a 2-of-3 multi-sig. In both scenarios you can lose one back up and still recover your wallet, and in both scenarios an attacker needs to compromise two back ups to steal your coins. The single sig plus passphrase is actually slightly safer in this arrangement since you might be able to lose two back ups and still recover your wallet, and an attacker might need to compromise three back ups to steal your coins, depending on which back ups are involved. The down side is you need four back ups instead of three.

You shouldn't need to explain either descriptors or derivation paths. Back up your three seed phrases along with one xpub, so the recovery of any two back ups provides two seed phrases plus the third xpub, as follows:

Back up 1: Seed A, xpub B
Back up 2: Seed B, xpub C
Back up 3: Seed C, xpub A

Then your family member can simply follow the instructions on a wallet such as Electrum to recover the multi-sig.

As an addition to hosseinimr93's answer above, although you cannot change the derivation path for Electrum seed phrases, you can always add a passphrase to one or both seed phrases which will result in a brand new wallet being generated when you combine them in a multi-sig.

Exactly, which goes back to my previous point that, just like when people throw their KYC around everywhere and then end up with their details being stolen, by the time they realize how terrible CBDCs are it will be too late to do anything about it.

Card payments are definitely less bad than CBDCs. Your credit card provider refuses to let you make a payment? You can at least try another provider, or a bank transfer, or some other option. A government refuses to let you make a payment with their CBDC? Nothing you can do about it.

Most people still use cash a bit, and some people (like me) still use cash a lot. Just because a majority of sheep won't notice any difference doesn't mean we should roll over and accept CBDCs. And just because a majority of people won't be affected by OFAC censorship in bitcoin doesn't mean we should just roll over and accept that either.

What the majority are doing is a very bad metric when it comes to privacy, as most people simply don't care until it affects them personally.

That's not what that means. It means it's not fully compliant with FIPS requirements (which are controversial to begin with), but they still say it can be used.

Don't forget that NIST previously promoted functions containing backdoors, so I wouldn't put too much faith in their rankings.

The goal of CBDCs is to eliminate cash and have everything electronic, and therefore have everything 100% traceable and 100% censorable. This is definitely worse than the current system, where you can at least escape some surveillance and retain some control by using cash.

Sparrow uses Java's SecureRandom function to generate its entropy, which sources entropy from /dev/urandom. This is similar to Electrum, which uses Python's randrange which also sources from /dev/urandom.

There are plenty of people on this forum who cheer regulation since it means bitcoin "is going mainstream", who cheer KYC since it means bitcoin "will be safer to use", and who cheer governmental control because "institutions will make the price moon". Those same people will be quite happy with CBDCs. After all, the government only want to protect the children, right!?

Exactly. So this Monero "ASIC" is barely better than a CPU, which is exactly what is supposed to happen. ASICs on bitcoin are many orders of magnitude more efficient than CPU/GPU mining.

You also said people aren't the sheep we think they are. But then you said they all use credit cards not understanding the money is not real (which I agree with), and they will all use CBDCs because they are convenient (which I also agree with). But surely just going along with what the banks tell you to do (use credit cards, use CBDCs) is exactly what the sheep would do?

We are currently mining transactions at 23 sats/vbyte, so you might get lucky over the next couple of hours.

We are also around 23 blocks behinds where we "should" be in this difficult epoch, which doesn't help. Those 23 blocks would clear us out to around 11 sats/vbyte.

The mining pool still has to validate the entire previous block before adding even a single transaction to a new candidate block.

Let's say I validate the first 10% of the previous block. I then decide to add Transaction X to my new candidate block. How do I know Transaction X hasn't already been mined in the remaining 90% of the previous block? I don't. Is it worth risking the 6.25 BTC block reward for the few thousand extra sats I would gain from mining Transaction X, versus invalidating my entire block because Transaction X has already been mined?

Before adding a single transaction to my new candidate block I need to verify the entire previous block. It only takes a few seconds (or even less), but on occasion this is all that is needed to successfully mine an empty block.