Thanks for the confirmation Zach. I suppose you would have to be crazy to implement any such system given the fallout from the recent Ledger debacle.

Can you provide clarification on the question I asked above? I don't have a Google or Apple account and have no intention of ever creating one, but is it really as simple as if someone accesses your username/email and password, then they can recover your Envoy wallet and steal your coins?

I also use this on all my drives, but of course remember that this only protects the disk at rest. If the drive is in use, such as it would be if you are running Core, then it is obviously decrypted and susceptible to physical or electronic intrusion. This is why, like you, I still password protect/encrypt all my individual wallet files as well.

Lmfao. "Use a different service to make your coins private before using them with Wasabi" is the best take I've heard yet.

Or, you know, just skip that second step and just use a different service altogether.

Although some VPNs bundle some anti-malware capabilities, VPNs shouldn't be relied on to prevent your computer being hacked or targeted with malware. If you want to do other bitcoin related things on that computer which you don't want your ISP to know about, such as use this forum, use block explorers, check fees, etc., then a VPN might be worthwhile, although Tor would probably still be better.

I see. In that case the concern is a privacy one, rather than a security one. If someone hacked your device or physically accessed your device, password protection on your Sparrow wallets might prevent them from viewing your wallets, addresses, transactions, etc. (This could of course directly lead to a security risk if the attacker then decides you own enough bitcoin to make you a target for further attacks.) Personally, I password protect/encrypt everything, even watch only wallets.

No, it wouldn't make any meaningful difference if you are already doing everything over Tor.

The descriptors that Sparrow creates only contain xpubs, and therefore are watch only and cannot be used to sign anything. You should definitely still password protect your wallet files which contain your seed phrases/private keys.

That's right. The descriptor file will contain the xpubs for all your co-signers. Personally, I would still back up the xpubs alongside each seed phrase back up though, in the manner I describe here which maintains your privacy at the same time: https://bitcointalk.org/index.php?topic=5456975.msg62443533#msg62443533

So just to confirm - if your password is hacked, leaked, keylogged, haveibeenpwned.com, etc., then all I need to do is take any old phone, log in to your Google account, sync your back ups to this phone, and now I have your seed phrase and can empty your wallets?

This is the finite field over which secp256k1 is defined. It is more commonly given the symbol p. Any calculations done in secp256k1 need to be done modulo p.

So to invert a y coordinate over the x axis like this, you simply do -y = p-y

This explains why the difference between your two y coordinates is p.

Yeah, this is an awful way to generate a seed phrase. You definitely shouldn't be manually picking words, you definitely shouldn't be manually picking words from publicly available texts, and you definitely shouldn't be manually picking words from publicly available texts which are intrinsically linked to bitcoin.

It wouldn't surprise me at all if the addresses you generate through this method are already on one or more lists of addresses being monitored 24/7 by bots waiting to steal any coins which are sent to them.

Just generate your seed phrase properly and stop risking everything with such harebrained schemes.

I've never had either an Apple nor a Google account, but I know both used to be accessible only via an email/password combo. If they both now mandate 2FA, then that is somewhat better. However, I suspect both still have procedures in place which would allow someone who has lost their 2FA device, be that their phone or a hardware key, to recover access to the account via some kind of social recovery or KYC, which is highly insecure. Happy to be proven wrong again.

That's what I was hoping for clarification on as I asked above. That this is completely confined to Envoy and there are no plans for anything remotely similar on Passport? I was a little concerned that Magic Backups were brought up in response to a discussion about Passport implementing something different to seed phrases...

It obviously can't. If your coins are refused, you have no idea if it is due to Sybil attack or if Coinfirm has simply decided your coins are naughty and are not allowed to be coinjoined. And Wasabi obviously won't tell you:


Absolutely. The blockchain analysis is awful, but the lies and gaslighting are a close second. If they were determined to go down this path but still actually cared about privacy or their users in any way whatsoever, then they should have come out and said "Here is the blockchain analysis company we are using, here is the criteria for what we will be blacklisting, here is how the process works, here is how much it is costing us per UTXO, here is how much information said company is gathering on you and your UTXOs, here is how that data is stored and transmitted, here is the list of third parties that data is being shared with, here is the list of governments/entities forcing us in to this decision, here is how best to avoid being subjected to this mass surveillance, here is a one-click set up to run your own coordinator, here is a list of coordinators which don't do this..." etc,. etc. I still wouldn't be using Wasabi, but the fall out on Reddit, Twitter, here, etc. would all be much less. Instead they flat out lie, gaslight anyone who points out the obvious, and dox their competitors.

Yes, I mean the same key is on their device, but the distinction is irrelevant. If someone gains access to 2 of your shares, then it is trivial for them to access the decryption key even if they don't actually know what it is (by simply using any Ledger device).

Although given that Ledger have said it will be possible for users to replace Ledger and perform the entire process manually so as to not rely on any third parties, I presume the decryption key will have to be made public knowledge at some point (if someone doesn't extract and publish it before then).

Yeah, I had no idea this was a "feature" Envoy offered...


I'm sorry, but this is horrible. You reduce the security of your seed phrase, and therefore all your coins, to the security of your Apple or Google account, which in many cases is only a simple password (and often a leaked or reused one at that!) or an insecure 2FA method which can be fairly easily
intercepted such as SMS. I would also wager that the subset of users who feel they cannot use a seed phrase properly and would back up their seed phrase to the cloud overlaps pretty heavily with the subset of users who have substandard account security or general security practices.

Is this in any way usable with a Passport, or is it confined to Envoy only?

Yes. It's a scam.

There will be absolute chaos in around 86 years.

Assuming early coins are truly lost, then even with a very conservative estimate of the bitcoin price being $100,000 in 86 years, each block will be able to claim 50 BTC in unmoved coins from the first several dozen thousand blocks. With blocks currently netting around $200,000 in total block reward, a reward of $5 million per block will be more than enough for every miner on the network to constantly attempt to reorg the chain many blocks deep for their own benefit. The same thing would happen every time a large enough cache of coins became eligible to be reclaimed.

This is something I theorized earlier and have obviously now been proven right. Given that you can recover your seed phrase on a brand new device, the key either had to be common to all devices or backed up alongside the shares. Turns out it is common to all devices, meaning the encryption is utterly useless. Any attacker can trivially access your decryption key. Every Ledger owner in the world already knows your decryption key. The encryption adds nothing and the safety of your coins is completely dependent on trusting the third parties.

If it's an inside job at one of the three companies, they only need a shard from one other company. That's a very low bar to clear.

The problem with coming up with your own system is exactly that - it is your own system, which no one else uses. You therefore lock the user in to your ecosystem and entirely dependent on your products if they want to recover their coins in the future, which is a dangerous scenario to be in. If you give users the option of using a seed phrases alongside your new system, then there are two possibilities. Either the user ignores the seed phrase and just uses your system in which case you are back in the same scenario, or the user uses both systems in which case your system hasn't removed the need for seed phrases at all.

Happy to be proven wrong, but I just don't see how this would work.

If I'm importing single private keys, then I am pretty much exclusively doing it on an offline machine to sign a transaction created from a watch only wallet. The wallet on my airgapped machine will never connect to my node. It's simply easier to use a light wallet such as Electrum (or Sparrow, if it had this function) on your airgapped machine than it is to use Core.

I would say the built in coinjoin, stonewall, and stowaway transaction functionality is a significant feature that Electrum does not have, if this kind of thing interests you.

The reason I've seen given on their GitHub for this is to discourage address reuse. I can appreciate that, but conversely I occasionally have the need to import a single private key and I won't reuse the address, such as sweeping paper wallets. It would be nice to have this feature even if it was hidden behind "Advanced Options" or similar.

128 bits of security. Their bits of entropy will depend on how they were generated, for a maximum of 256 bits.

My only concern with using 12 words is you cap your entropy at a maximum of 128 bits. If your entropy is generated properly, then your private keys will have 128 bits of entropy and 128 bits of security. But if your entropy generation process is flawed, you can reduce the entropy and therefore the security of your keys below 128 bits.

If you use 24 words and your entropy generation process is flawed, you can reduce your entropy much below 256 bits while still keeping 128 bits of security.

You'll get one eventually: https://support.startpage.com/hc/en-us/articles/4521350590996-Why-am-I-receiving-a-CAPTCHA-verification-page-

Occasionally solving the captcha doesn't work for me, but switching to a new Tor circuit does.