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

In my opinion, if other hardware wallet devs are able to add support for their device to Envoy without additional libraries or security concerns, Foundation could always merge it into their main branch.

But then you run into all these issues like a buggy implementation being blamed on Foundation. Would be totally understandable from a business perspective if Foundation Devices never merged third-party wallet support into the official version of their application.

Wise commitment.

I think that granting to other HW the ability to be paired  with Envoy  would require incorporation of the  third-party connectivity libraries  into app's code. Those libraries may have the flaws and thus, be vulnerable to malware or hacking attempts . Consequently , the security of HW + Envoy tandem would be  liquefied.

We plan on focusing only on Passport (and future devices) in Envoy as that allows the tightest UX pairing possible, and there are other fantastic multi-hardware wallet solutions out there like Sparrow Wallet.

As you mentioned, Envoy is 100% open source so anyone could fork it and make it work with other air-gapped hardware wallets, with those supporting the same UR/animated QR standards being the easiest to implement.

Is there a way for Envoy app to have support for other aigrapped hardware wallets, other than Passport?
Or maybe you have the tools available for other developers to help and work on that, since everything is open source code.

Love to hear that! We've done a lot of work to increase the size of transaction you can reasonably use QR codes for, but there is still a practical limit where it just makes more sense to use microSD, so I'm glad to hear this is already being an effective UX improvement.

Even more QR improvements and transaction signing speed-ups coming in 2.3.0 as well as we've rewritten the transaction parsing from scratch to go along with Taproot.

I should say that this is the most noticeable feature  which empowers  device to handle large transaction effectively. I have encountered in the real practice the difficulty to sign via QR the big transactions which made itself evident in the fact that the time required to complete the signing process was unbearably long (up to 10 minutes). Now, having the preliminary warning on the large transaction and opt to switch  on-the-fly from QR  to SD card  simplifies the signing process. Tested this myself with  2.2.0 beta a few days ago.

We're thrilled to get Passport v2.2.0 in your hands today 🎊

With this latest version, you can:

📷  Seamlessly switch back and forth between signing via QR and microSD
🌱  Restore from SeedQR

We've also improved the user interface on Founder’s Edition and added many quality of life improvements across the board. With the number of new features we included in 2.1.0, we took this release to focus on refining our unified firmware between Founder’s Edition and Batch 2, as well as paving the way for full Taproot support in 2.3.0.

Update today directly from Envoy, our mobile app in just a few taps, and read the full changelog in our release notes blog post below:

https://foundationdevices.com/2024/01/passport-version-2-2-0-is-now-live/

If this is your first time updating Passport or you'd like a refresher, we have docs and videos that walk you through every step of the process:

https://docs.foundationdevices.com/firmware-update

I didn't saw this posted here, but looks like guys from Passport Foundation are a bit scared about recent changes in US, so they are dropping plans for Whirlpool support in their Envoy app.
Only way to use Whirlpool is going to be with Sparrow and Samurai wallet, or by forking their open source Envoy app.
New version of Envoy app was released few days ago:
https://github.com/Foundation-Devices/envoy/releases

I fell in love so much with this Passport thing.

Is there any plan for official Monero support?  Passport would be the PERFECT Hardware Wallet for a combination of these two Currencies and I am pretty convinced that most of your customers are or end up being Monero users too.  Like, how many Bitcoin users are paranoid enough to move further from preaching to ACTUALLY using Airgapped Hardware Wallets?  For the most part only some paranoid weird people like me would!

Anyway.  The last version of Passport looks amazing.  You have done a beautiful job at designing the Hardware Wallet AND creating the perfect Wallet for the paranoid.

-----

Edit.  Do you have a plan for an uglier but more affordable version of this?  Maybe a chunky plastic Wallet that is focused on affordability while offering the exact same more important components such as quality buttons, quality screen et cetera?

Well, probably by card he meant a paper one rather than SD card. 20-digits-long code is used to encrypt zip file which holds SEED and Passport's settings. They advise to write down that code on the  paper card that accompanies Passport.



Probably now they are thinking of splitting somehow that code into a few parts to hold them on different paper cards.

I might have had been confused about what I had heard Zach say on the podcast, and since i don't currently have a Passport device, my ideas of how it works are not as much experiential - and I had not really understood very well how the SD card back-up works.   

Nonetheless your suggestion of not pegging the code to any specific SD card seems helpful, but then that could be problematic if the code would be totally open.   I was presuming that there might be a way to have a back up code and then perhaps to have it pegged to 3 SD cards that use the same code, so it is like having 2 back ups of the SD card in case the primary SD card gets lost, stolen or broken.   

Can not get this at all. Could you elaborate a bit more his frame of thought. In the current implementation the backup code (consisting of 20 digits) can be copied to any quantity of SD cards. Pegging code solely to the  specific card is not a wise approach, IMHO.


As to me, I prefer to backup SEED phrase rather then digital code.

A few hours ago, I listened to Zach being interviewed on the Simply Bitcoin podcast that just came out today (Zach participates in most of the podcast, yet their discussion of Passport and/or hardware (self-custody) user-friendliness ideas is mostly in the second half of it).

They were largely talking about user-friendliness, and even talking about how many users are likely intimidated from various kinds of user-friendliness aspects of various kinds of wallets.

They may have also mentioned that sometimes there is a certain reluctancy that individuals have in terms of changing from their current practices into different practices, or maybe not even recognizing and/or appreciating various vulnerabilities that might exist in their own ways of custodying their coins.

At one point zach mentioned the physicality of the SD card, so that the back up code could be secured in places that might not be 100% secure because the code has to be matched up with the SD card, and so I probably still would prefer to camloflage the code and even to divide it up, but then I also started to consider whether there might need to be 2-3 SD cards, and how such a process would work.

So my point is that I hate to merely rely on one back up, and I understand the potential complications of having back-ups stored in too many places and/or even complications (and confusion) that might come from that, and I am pretty sure that my current process is ideally having three back ups, even though sometimes when in the process of getting some new private key or password or other kind of private security information, I may well only have one or two back ups until that information gets put into a more systematic longer term system in which there are 3 back ups..

oh and by the way, I frequently will just suggest 2 back ups, so I might even be overly doing my own self.. while at the same time I get nervous when people tell me that they ONLY have 1 back up.. which is surely better than no back ups, which is also a pretty common practice for real world and non-technical normies. they frequently have no back ups at all and they look at you as if you were an alien if you are asking them about how they back up their information (whether value related information, such as bitcoin, or any other information for that matter).

Although I haven't gone through the whole code but from what I've checked I don't think they have ever implemented that part of the code responsible for computing the sig-hash (digest) for other sighash flags. You can see that elsewhere too. For example in the below link you can see the method that is computing sig-hash for SegWit outputs according to BIP-143, it is clear that this is not a full implementation of the BIP as it skips other sighash types and only supports SIGHASH_ALL (no _NONE no _SINGLE and no _ANYONECANPAY).

https://github.com/Foundation-Devices/passport2/blob/3d570fba50b40d65a04087127138426c2570e5a0/ports/stm32/boards/Passport/modules/psbt.py#L1588

Thanks, I know this. However I was asking about the presence of the "hidden"  opt in the wallet settings (I have perused all available menu's opts , but didn't find it )that would allow to override that default response and sign transaction with any SIGHASH flag.  In fact,  I doubt whether I would ever need the other response, thus, that was just a thought-provoking  question (to officials, which still holds on).

If you are importing a PSBT file for signing, the code rejects any sighash types that is not SIGHASH_ALL and there is no option to override that as far as I can tell from the source code:
https://github.com/Foundation-Devices/passport2/blob/3d570fba50b40d65a04087127138426c2570e5a0/ports/stm32/boards/Passport/modules/psbt.py#L512-L514

Following this thread I have checked how Passport2  responds to SIGHASH_NONE  transaction and got the positive  result  in the sense the device has refused to sign it. (In my understanding,  If Passport signed this transaction,   the outputs could have been  spent to any address without changing the signature. )



Anyway, just of my curiosity. Is there menu's opt that makes possible for device to sign transactions with  SIGHASH flags other than SIGHASH_ALL?

I can confirm that I have received this Foundation Survey to my email associated with Foundation and/or its newsletter but I never purchased anything from your company. I understand that it might be time consuming to apply manual filters and only send the survey to actual hardware wallet users. I haven't clicked on the link to see the content, but can even those who don't own the device participate and possibly win or won't they be able to finish it without proof they own one?

Absolutely! Please just send us a message and we'll set you up with the link 

It probably doesn't matter how you got it as long as you own the hardware device. If you can't show a receipt, purchase order number, shipping ID, or other proof, I am sure they will accept a picture of some sort that you have it or just take you for your word based on your forum trust.