Foundation Passport Official Thread

[foundationdvcs]

I don't believe there would be enough storage space to have both firmware installed at the same time, but installing firmware + restoring backup from microSD would only take a minute or two max. Please note that if this Monero firmware becomes reality it will still not be official or endorsed by Foundation and purely driven by the Monero community.

Yeah, I get that. Also, having thought about it, I actually don't want to be installing software from a community fork on the same device as I use to store my bitcoin. I'd rather use two entirely separate devices for security reasons.

I expect this will be the route most will take who want support for both.

@foundationdvcs
Here are a few notes for using the beta version for a few minutes, as someone who doesn't own a Passport device ^[yet]:

• It'd be nice to have a list of used/unused addresses in conjunction with the ability to sign a message directly from the app.
• Support for other address types ^{[e.g. Taproot would be nice]}.
• I noticed going back and forth between Envoy and any other app would result in a black screen that sometimes lasts around 30 seconds!

1. We have a roadmap issue internally for this and already have UX built out for it, so I wouldn't expect that to be too far down the pipe!
2. You can pay to Taproot addresses already, actually, but receive support will come alongside Passport full Taproot support in the near future. That also is currently a WIP and a high priority for the next major release of both Envoy and Passport.
3. Very odd! We have seen this very infrequently coming from the lockscreen and are working on a fix, but you see it also coming just from multitasking in other apps? If possible, could you record this happening and share details on your OS (as much as you're comfortable with) in an email to hello@foundationdevices.com? We'd love to help you get to the bottom of it, and your help would make it a faster process 

[1713550248]

1713550248

[1713550248]

1713550248

[1713550248]

1713550248

[SFR10]

3. Very odd! We have seen this very infrequently coming from the lockscreen and are working on a fix, but you see it also coming just from multitasking in other apps?

Yes, I also experienced it while I was multitasking yesterday, but no matter how hard I tried to reproduce it today, it didn't recur ^{[a bit strange]} so it must be connected to the other rare issue that you mentioned...

• If possible, could you record this happening and share details on your OS (as much as you're comfortable with) in an email to hello@foundationdevices.com? We'd love to help you get to the bottom of it, and your help would make it a faster process 
  

  Sure... I'll do it as soon as it happens again, but until then, all I can share is the details of my OS ^{[Android 13 (One UI 5.1)]}

While I was using it with the "Testnet earlier", I noticed we can only copy the transaction ID, but not see the other details ^{[I'm not sure if this is also part of the roadmap or not]}.
^{BTW, a customized fee option (apart from the Standard and Boost options) would be nice as well.}

[foundationdvcs]

While I was using it with the "Testnet earlier", I noticed we can only copy the transaction ID, but not see the other details ^{[I'm not sure if this is also part of the roadmap or not]}.
^{BTW, a customized fee option (apart from the Standard and Boost options) would be nice as well.}

Thanks for the info, will pass that on to the support team 

As for your other requests:

1. We have another big feature set WIP for hot wallet that will include a detailed transaction screen, but you're correct that for now it just allows copying the TXID.
2. It's likely we won't offer manual fee selection in the short term as the wallet is geared towards newer users and we want to keep things simple and easy to understand, but we are reworking the way that fee selection works a bit and giving clearer options in a coming update.

[foundationdvcs]

We're happy to announce that the public beta for version 2.1.0 is available now on Github:

Passport v2.1.0 Firmware (Beta 6)

NOTE: This is a Beta version of Passport firmware. You must install the beta pubkey (attached in GitHub) using the Settings -> Advanced -> Developer PubKey menu item before you can install this beta. If you are not comfortable with this, please wait for the official release, which should be available shortly. Detailed instructions for this process can be found here.

In version 2.1.0, we’ve leveraged all of the background work in recent versions to build out some amazing new features for you, including back-porting v2.1.0 firmware to Founder’s Edition, sending to Taproot addresses, a Key Manager Extension for BIP-85 and Nostr key support and export, and BIP 85 SeedQR exports.

It would be especially valuable to get detailed feedback from anyone willing to help out on the new features and on the general firmware for Founder's Edition as this is a huge jump, bringing parity to our original device.

For the full change log you can visit Github.

Please test it out (if you're comfortable with a beta release) and report back with any issues, feedback, or suggestions you have! The official release should go live in about 1wk, pending any issues that are discovered in the public beta testing.

[n0nce]

We're happy to announce that the public beta for version 2.1.0 is available now on Github:

Passport v2.1.0 Firmware (Beta 6)

NOTE: This is a Beta version of Passport firmware. You must install the beta pubkey (attached in GitHub) using the Settings -> Advanced -> Developer PubKey menu item before you can install this beta. If you are not comfortable with this, please wait for the official release, which should be available shortly. Detailed instructions for this process can be found here.

In version 2.1.0, we’ve leveraged all of the background work in recent versions to build out some amazing new features for you, including back-porting v2.1.0 firmware to Founder’s Edition, sending to Taproot addresses, a Key Manager Extension for BIP-85 and Nostr key support and export, and BIP 85 SeedQR exports.

It would be especially valuable to get detailed feedback from anyone willing to help out on the new features and on the general firmware for Founder's Edition as this is a huge jump, bringing parity to our original device.

For the full change log you can visit Github.

Please test it out (if you're comfortable with a beta release) and report back with any issues, feedback, or suggestions you have! The official release should go live in about 1wk, pending any issues that are discovered in the public beta testing.

This is exciting news! In my original review of Passport FE, I mentioned it was important for me that the device would keep getting updates for years to come. Great to see that it's finally happening - I was almost getting worried..

GitHub has no repository for the new firmware, which makes me hope they run the same one; thus reducing codebase to maintain + elongating FE update support.

However, it seems to take longer than expected to back-port Passport v2 features to FE? Or did it only take this long to get them to feature-parity in the first place, but they'll be in sync from now on?

I'm referring to...

Note that there might be an initial delay of a few weeks in releasing the first FE version of this new code, but after that my intention is that new firmware versions for the two devices get released simultaneously.

[foundationdvcs]

However, it seems to take longer than expected to back-port Passport v2 features to FE? Or did it only take this long to get them to feature-parity in the first place, but they'll be in sync from now on?

The long lead-up for this was due to synchronizing the code-base, moving forward they'll both use the passport2 repo and share firmware releases, features, etc.

Total parity from here on out is the plan now that we've laid the groundwork!

[dkbit98]

Someone decided to fork Passport code and enable separate support for monero, and I don't see anything wrong with that, unless it takes away dev time from working on improving BTC code and fixing bugs.
This all resulted in one more of NVK episodes, but I think you guys nailed it with latest blog post from Zach Herbert, so I have to post it here, as An Open Letter to NVK and Coldcard:
https://www.zherbert.com/an-open-letter-to-nvk-and-coldcard/

Maybe people with old version Passport devices (like n0nce) can test this unofficial firmware when it gets released:   
https://github.com/mjg-foundation/passport2-monero

[foundationdvcs]

Someone decided to fork Passport code and enable separate support for monero, and I don't see anything wrong with that, unless it takes away dev time from working on improving BTC code and fixing bugs.

Yes, and just to be clear this is a community fork and not officially from us. No plans at this time to have an official firmware for current devices, but in theory this will end up being unofficial firmware for at least Batch 2 (and maybe Founder's Edition) if enough devs rally around it! Beauty of true free and open-source projects is they can spinoff in many directions 

Maybe people with old version Passport devices (like n0nce) can test this unofficial firmware when it gets released:   
https://github.com/mjg-foundation/passport2-monero

I believe this will be focused on Batch 2 devices, but it may also end up supporting FE as well. Unclear at this point.

[n0nce]

This all resulted in one more of NVK episodes, but I think you guys nailed it with latest blog post from Zach Herbert, so I have to post it here, as An Open Letter to NVK and Coldcard:
https://www.zherbert.com/an-open-letter-to-nvk-and-coldcard/

Good read, thanks.

Maybe people with old version Passport devices (like n0nce) can test this unofficial firmware when it gets released:   
https://github.com/mjg-foundation/passport2-monero

Sure, I can give it a shot, if there's interest for it! As far as I can tell, they only just started with this fork, so it should take a while. Many aspects of Monero are quite different (the cryptography in particular), which should require massive changes.

In the meantime, I downloaded v2.1.0-beta-6-founders and give it a shot on the weekend.

[DireWolfM14]

No plans at this time to have an official firmware for current devices

That's too bad.  I really love my Batch 2, and I am very much a bitcoin maximalist, but I do end up holding several thousands of dollars worth of monero from time to time.  I promise, that will be only altcoin I ever ask you to implement!

[foundationdvcs]

The latest version of Passport firmware, v2.1.0, has been released!

Please note that this is our largest release in some time and also brings Founder's Edition up to date with Batch 2 devices, unifying our firmware. As this is such a large update, we'd love for you all to test it as much as you can before we announce it more widely.

Highlights of this release:

- Backporting v2.1.0 firmware to Founder’s Edition
- Sending to Taproot addresses
- A new Key Manager Extension for BIP 85 and Nostr key support and export
- BIP 85 SeedQR exports

For the full release notes, browse Github or read our blog post below:

https://foundationdevices.com/2023/05/passport-version-2-1-0-is-now-live/

NOTE: Since we are now releasing both firmware files from the same repo, the file naming has changed slightly. "Batch 2" devices use the same naming scheme for firmware as before:

Code:

v2.1.0-passport.bin

but Founder's Edition is now named explicitly to avoid confusion:

Code:

v2.1.0-founders-passport.bin

[dkbit98]

- Backporting v2.1.0 firmware to Founder’s Edition

I think owners of old Founder's Edition will be happy hearing this.
Do you still have some of those old outlet devices in stock?

- Sending to Taproot addresses

Is Passport wallet now fully supporting Taproot format address both for receiving and sending?
If you can confirm that I can move on and add it on my topic List of Wallets supporting Taproot:
https://bitcointalk.org/index.php?topic=5371499.0

This would be fifth hardware wallet with Taproot support after Ledger, Trezor, BitBox02 andOneKey.

[foundationdvcs]

- Backporting v2.1.0 firmware to Founder’s Edition

I think owners of old Founder's Edition will be happy hearing this.
Do you still have some of those old outlet devices in stock?

Sadly no, though I think a few resellers still have a small quantity in stock last I checked!

https://foundationdevices.com/resellers/

- Sending to Taproot addresses

Is Passport wallet now fully supporting Taproot format address both for receiving and sending?
If you can confirm that I can move on and add it on my topic List of Wallets supporting Taproot:
https://bitcointalk.org/index.php?topic=5371499.0

This would be fifth hardware wallet with Taproot support after Ledger, Trezor, BitBox02 andOneKey.

No, in this release it is just p2tr (spending to Taproot addresses) but does not support receiving to Taproot addresses or spending Taproot outputs. That is slated for our next major release and is already actively in dev! We'll combine shipping that with full Taproot support in Envoy (which currently also has simple p2tr support and not full receive/spend).

[satscraper]

Can not get why Foundation has decided to not  store the 25th-word-extension for SEED and forced users to enter that password each time after rebooting device.

I am using that password as the second security layer for my funds and seeing such solution as very inconvenient approach.

In this regard, what is the press-number-expectancy for buttons on  the board of Passport? In other words, how many pressing does the button  endure   before it goes to out-of-commission state?

[foundationdvcs]

Can not get why Foundation has decided to not  store the 25th-word-extension for SEED and forced users to enter that password each time after rebooting device.

I am using that password as the second security layer for my funds and seeing such solution as very inconvenient approach.

This is so that it actually provides an additional layer of security for your funds on Passport. If we stored the passphrase on the device, anyone with the PIN would be able to steal funds and the extra security of your passphrase would be pointless! It's a very intentional security decision to require it on each bootup.

In this regard, what is the press-number-expectancy for buttons on  the board of Passport? In other words, how many pressing does the button  endure   before it goes to out-of-commission state?

I don't have a hard number for you, but AFAIK we have had zero units with failed keypads due to use to date and did extensive in-house testing before shipping the first Passport.

[satscraper]

Can not get why Foundation has decided to not  store the 25th-word-extension for SEED and forced users to enter that password each time after rebooting device.

I am using that password as the second security layer for my funds and seeing such solution as very inconvenient approach.

This is so that it actually provides an additional layer of security for your funds on Passport. If we stored the passphrase on the device, anyone with the PIN would be able to steal funds and the extra security of your passphrase would be pointless! It's a very intentional security decision to require it on each bootup.

Obvious thing that  SEED+password must be hidden behind the second PIN. Make it 12-digits long and left 3 valid attempts to enter and I am sure no one will  pass through the barrier.

Is this so difficult to implement?

Ledger did it. Why Foundation did not?


I have 20 characters long password and beside the burden of entering it each time this is one more point of frustration for me when even single wrong character infiltrates the  typing.

[n0nce]

Obvious thing that  SEED+password must be hidden behind the second PIN. Make it 12-digits long and left 3 valid attempts to enter and I am sure no one will  pass through the barrier.
[...]
I have 20 characters long password and beside the burden of entering it each time this is one more point of frustration for me when even single wrong character infiltrates the  typing.

Why don't you just use a 12-digit numeric passphrase then?

Ledger did it. Why Foundation did not?

Ledger did many things; not all of them are great. I can't answer this for you, but I assume it comes down to their explanation above (i.e. security).

The BIP39 passphrase is meant to add a reliable amount of extra security. If we now start implementing what's basically a PIN-based passphrase 'bypass', suddenly something built-in into Bitcoin that is universally seen as a very strong extra layer of security, may suddenly be quite insecure depending on wallet implementation used. One wallet may allow you to bypass / 'unlock' the passphrase through a simple numeric 4-digit PIN, another may require you to enter it completely and so on.

Personally, I find the Passport keypads and form factor very comfortable for entering even long PINs and passphrases, so I like the current implementation.

[satscraper]

Obvious thing that  SEED+password must be hidden behind the second PIN. Make it 12-digits long and left 3 valid attempts to enter and I am sure no one will  pass through the barrier.
[...]
I have 20 characters long password and beside the burden of entering it each time this is one more point of frustration for me when even single wrong character infiltrates the  typing.

Why don't you just use a 12-digit numeric passphrase then?

12-digit numeric passphrase  is not equal to mix of 20   characters consisting of digits, caps, small letters and special characters.

Personally, I find the Passport keypads and form factor very comfortable for entering even long PINs and passphrases, so I like the current implementation.

My experience with Passport is  not so long as yours. Only two days have passed since the moment when I got it into my hands.

First impressions.

Form factor is good but sure not for frequent travelers  like me who has to pass through customs borders a few times a month, I am still afraid of custom controls. I would prefer to have it even not in the form of  the old-style cell phone. Maybe something like ordinary calculator with in-front functions to calculate would be better to disguise real thing, who knows.

I am gradually began to adopt myself to their implementation of password feature and see at least  one positive moment in entering password each time after rebooting , namely,  such procedure will stamp firmly  that password into my memory.

If we now start implementing what's basically a PIN-based passphrase 'bypass', suddenly something built-in into Bitcoin that is universally seen as a very strong extra layer of security, may suddenly be quite insecure depending on wallet implementation used. One wallet may allow you to bypass / 'unlock' the passphrase through a simple numeric 4-digit PIN, another may require you to enter it completely and so on.

No one prohibits Foundation to implement  PIN-based passphrase 'bypass' option  alongside with already existing one-time passphrase choice. So, what you said is not really an argument.

I like the current implementation.

 their clients base is more wider than a single person.

[n0nce]

Obvious thing that  SEED+password must be hidden behind the second PIN. Make it 12-digits long and left 3 valid attempts to enter and I am sure no one will  pass through the barrier.
[...]
I have 20 characters long password and beside the burden of entering it each time this is one more point of frustration for me when even single wrong character infiltrates the  typing.

Why don't you just use a 12-digit numeric passphrase then?

12-digit numeric passphrase  is not equal to mix of 20   characters consisting of digits, caps, small letters and special characters.

Correct. But if you use a device that allows you to access a wallet which is supposed to be protected by a 20-character BIP-39 Passphrase by just entering a 12-digit PIN, you've essentially reduced the security level of your wallet to the security of a 12-digit numeric Passphrase.

I guess that further security measures on the hardware wallet (like a maximum number of attempts) can increase the security of the device again, whilst the 20-character passphrase secures your seed phrase backups, but modern attacks can actually defeat such counters. In the end, it all depends on your attacker model.

I am gradually began to adopt myself to their implementation of password feature and see at least  one positive moment in entering password each time after rebooting , namely,  such procedure will stamp firmly that password into my memory.

Interesting; if I think about it, I agree! Especially if you don't back up your Passphrase, you really want to make sure to memorize it well. There's actually no better memorization technique than frequent repetition.

[satscraper]

Obvious thing that  SEED+password must be hidden behind the second PIN. Make it 12-digits long and left 3 valid attempts to enter and I am sure no one will  pass through the barrier.
[...]
I have 20 characters long password and beside the burden of entering it each time this is one more point of frustration for me when even single wrong character infiltrates the  typing.

Why don't you just use a 12-digit numeric passphrase then?

12-digit numeric passphrase  is not equal to mix of 20   characters consisting of digits, caps, small letters and special characters.

Correct. But if you use a device that allows you to access a wallet which is supposed to be protected by a 20-character BIP-39 Passphrase by just entering a 12-digit PIN, you've essentially reduced the security level of your wallet to the security of a 12-digit numeric Passphrase.

I guess that further security measures on the hardware wallet (like a maximum number of attempts) can increase the security of the device again, whilst the 20-character passphrase secures your seed phrase backups, but modern attacks can actually defeat such counters. In the end, it all depends on your attacker model.

What is largely bothered me is the password brute-forcing if someone will manage  to get somehow my SEED but not physical access to my device.

In the case of  his  physical access, if any will take place, 12-digit PIN with 3 valid attempt will be enough to  protect   my security, the probability to break it will be as small as 3/10 ¹² and those probability will be tested by human hands not by machine/s as in the case of brute-forcing.