Topic: Foundation Passport Official Thread - page 9. (Read 4649 times)

Just to clarify and alleviate some concerns, no solution we come up with for backups would lock a user into our ecosystem, it would always be portable in some way.

Magic Backups for Envoy's mobile wallet (not applicable for Passport) are a perfect example of that, where a user can use Envoy and never realize there is a seed phrase behind it, but can *always* recover funds in any wallet through the settings, where they can find a standard seed phrase. We also will be adding in prompts for users after a certain time period to back up the seed itself for maximum sovereignty, but we want options that allow users to start in a seedless manner.

But nothing we ever build will lock users into a walled garden, and will always have industry standards under the hood and accessible to users in an emergency (like BIP 39).

With seed phrases, you always have the freedom to recover your coins elsewhere for any reason. With a "Foundation Passport Backup System X", you are stuck with that one product because no one else supports your recovery scheme. Unless, of course, you can get some other wallets to implement it as well. And if there is a bug or it malfunctions, you will be required to wait until the devs find a way to fix it. Not to mention the devastation if they completely abandon it or it breaks down for whatever reason.

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.

I might be a bit old-fashioned but I have always been of the opinion that if it isn't broken, don't fix it. I think that users who aren't capable of writing down and storing 12 English words in paper format are too spoiled and crypto might not be suitable for them. If they can't even do that, I see them struggle with other essential elements of the game.

Still, it's good that you trying to simplify an already simple process. How is that going btw? What would you like to replace seeds with but still not impact the security of the new storage method?

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.

Spot on with the analogy!

The user experience of seed phrases can be quite poor, so we're continually looking for ways that we can abstract away the seed phrase experience for new users especially. Not an easy problem to solve, though!

Well, since Bitcoin private keys have 128 bits of entropy, you aren't improving the security of those keys by increasing the entropy of your seed. That's the gist of it. It's like making your wall stronger without realizing you have a glass window that is easier to break through. The security of Bitcon private keys isn't comparable to glass windows, I am just trying to make a point.

What did you mean when you said the following in your blog post:
Do you not like the term "seed" and would like to see a different one? Or, do you not like the seed itself, as in the 12/24 words we use for backups?

Thank you, those are excellent corrections! You're correct that they're all technically true and I was oversimplifying a bit to make it approachable, but took your advice and found ways to integrate it without overcomplicating the messaging, I think.

Can I suggest some corrections? I suspect you already know these things, but it is better to be precise rather than to attempt to simplify things and end up presenting inaccurate information.

The range is not 1 to 2²⁵⁵, but rather 1 to just under 2²⁵⁶. If you wanted to be really precise, 1 to 2^{255.999999999999...}. By saying 2²⁵⁵, you are actually cutting the number of valid private keys in half. 2²⁵⁵ also doesn't match with the 115 quattuorvigintillion figure you then use (which is indeed 2²⁵⁶).

That's not accurate either. If we assume all private keys are generated randomly, then half of them will have a leading zero and therefore be at most 255 bits. A quarter of them will have two leading zeroes and will be at most 254 bits. And so on. These keys aren't any less secure. If you force all private keys to be 256 bits long (i.e. start with a 1 rather than a 0), then again you are excluding half of all possible private keys.

I think you mean "fully functional public key" here. That one number is your private key. The private key does not need to be generated from that number, only the public key does.

This should read "private keys".

This isn't strictly correct since with a 12 word seed phrase, 15 of every 16 possibilities on average can be immediately discarded due to an invalid checksum. The number used should be 2¹²⁸, not 2048¹² (which is 2¹³²).

I think that this kind of commentary is fair to the topic of any product that has competitors (and if they are similar or sharing code), and very well and seemingly fairly presented by RickDeckard.. as usual RD provides sources for his assertion and seems to describe what is going on in a mostly reasonable way - even if some of it might be tied to his opinion, too.

One of the matters regarding the creation of an "official thread" should have been to create this thread as "Self-Moderated," and so it seems that OP had made the mistake of not making this thread self-moderated (which I believe cannot be changed after the thread has been started as not self-moderated), but OP could make a new self-moderated thread if he believes that some of the criticisms and/or drama might be going too far, too distracting and taking away from the topic overall (or maybe his preference to promote the product without having some potentially heavy hitting contrary statements....and if he would like to have a more clean thread that he is able to control any kind of controversial commentary that might come into the thread, then he would likely need to create a new self-moderated thread (unless there is a way to change it to self-moderated after it had already been created, which I doubt.. I think that the forum does not like to change threads in the self-moderated kind of a way after they have already been started). 

Surely, I had heard some of the accusations that Foundation had stole the code from the cold card, and whether those are fair-game criticisms may well be taken into account in any thread that is not self-moderated...so long as there are attempts to otherwise stay topical.. and whether or not personalities might be relevant to the conversation, too.

FE does run the latest firmware, yes.

There are some high-level block diagrams on GitHub (of course also the actual schematics), but the general architecture has barely changed:

Founders Edition:
You have to look more into the hardware repos I linked to, but from what I recall, the new hardware is only very slightly different. The codebase is now identical for both devices.

We dropped a new blog post that I thought was worth sharing here, as we're coupling it with a commitment to transition Passport to 12 words by default in an upcoming firmware release and in new packaging (as well as any future hardware wallets):

https://foundationdevices.com/2023/06/make-12-words-the-standard/

Would love to hear all of your thoughts on the topic! We will of course never force anyone to transition an existing 24 word seed, and will always give the option of 24 words for those who want to use one. This will just affect the default for new users 

Nice work!
It's interesting that Coldcard also appeared on WalletScrutiny website, and I don't remember I noticed it before.
Cypherock X1 wallet also made it in top 7 list of reproducible HW.

I see Passport Founder's Edition is showing Discontinued note, but can they still be used with latest firmware updates, and what are the main difference compared with Batch2 in main board level?
Case is much better in new model, as well as display, but I was asking about chips, processors and code.

He would probably be terrible in role of Satoshi.  
I don't want to talk about NVK, and I don't know what is in his head, but I think he felt his business was going down after Passport appeared and he didn't like that someone else (other than him) is using open source code.
Let's get back on topic - Passport wallet.

Thanks for the info, but let's try to refrain from turning this thread into a "He said, She said" bickering match.  I know some members can't refrain themselves from stirring drama, but so far this thread has been steadfast in sticking to the topic at hand, and it would be disrespectful and shameful for it to get derailed.

There was a clash between the two some time ago. Zach (Foundation CEO and Co-founder) even made a post in his own blog about it[1]. It mostly started when Matt Odell (seen as an influencer within the crypto community I assume) posted a tweet[2] claiming that all what Foundation did was to clone NVK source code into their product. Besides Matt, even the co-founder and CEO of CoinKite (@nvk[3]) - the producers of Coldcard - was spreading that same information on their Discord channel - that not only did Foundation copied their code but that they were also closed source (you can read more about it on Zack open letter).

I don't know how the situation ended between the two, but I wouldn't be surprised if Foundation (and Zach team) ended up a bit frustrated against this "attack" by nvk and would keep communication on strictly what was needed. You can feel that on Zach closing remarks on his letter:

---

[1]https://www.zherbert.com/an-open-letter-to-nvk-and-coldcard/
[2]https://nitter.it/ODELL/status/1651220101721358336
[3]https://nitter.it/nvk

I know that Andreas A. owns both a Coldcard and a Ledger device. In one of his recent videos where he discussed the Ledger Recover feature with Jameson Lopp, he said he will continue using both hardware devices, but for different storage needs. It would be off-topic to discuss that here, but it's just something that I remembered now.

I seriously doubt it, and I haven't seen any interaction between the two.  Both outfits have handled their forum presence with professionalism and tact despite efforts by some to stir shit and pit them against each other.

I own wallets from both outfits, and it's my opinion that both are among the best hardware wallets currently available.

I know that you are throwing a punch at NVK and ColdCard (rightly so), but did I miss some drama between the teams of Passport Foundation and ColdCard? Did NVK question the verifiable or open-source nature of Passport devices? Just for the record, although I am sure you know, Coldcard not being open-source doesn't make their code not verifiable and nonreproducible. Even WalletScrutiny has marked it properly on their website.

I personally prefer to enter addresses when needed, rather than risking getting an xpub compromised, due to the related privacy and security issues.

Also, I have to agree with comments in that discussion which point out that address reuse can still happen if you start entering xpubs in different Bitcoin applications. Even checking addresses for balances does not exclude collisions, due to the 'TOCTOU' nature of this idea combined with asynchronous Bitcoin transactions; only emphasized by a full mempool with long confirmation times.

It's also correct that mediation and support in general will only get worse if people use all sorts of different wallets. By keeping the trade from beginning to end inside Bisq, the team should have a much easier time assisting in case of problems.

That reads really nice, indeed! Much better than before; everything in one file, nice and concise and with one less dependency. I will try it out myself and also use it to debug my own script.
Amazing to see that it was already updated on WalletScrutiny now, that's a pleasure to see.

Pretty cool news, both Passport "Founder's Edition" and "Batch 2" are now updated and properly marked as verified for the latest firmware, v2.1.2, on the Wallet Scrutiny website!

https://walletscrutiny.com/hardware/passport/
https://walletscrutiny.com/hardware/passportb2/

Note that if you ever want to reproduce the firmware yourself you can do so using our guide here:

https://github.com/Foundation-Devices/passport2/blob/main/REPRODUCIBILITY.md