Add Ledger Nano S to hardware wallets

[EricLarch]

Ledger has launched its new generation hardware wallet Nano S, which features a screen and buttons to validate a transaction directly on device.

As this is a major addition of our product line, we feel relevant that it is proposed here.

[jubiju]

Is ledger open source like trezor?

[EricLarch]

All apps are Open Source. Everything is available on our Github.

Regarding the firmware, the source code will be available for all the non secure (STM32) part and some of the secure (ST31) part. Ultimately it'll be available for most of the ST31 with a minimal binary blob implementing the chip functionalities only available under NDA. It'll also not be possible to reverse engineer this binary blob, but it'll be possible to check that it's not performing any other functions than those which are documented.

We have elaborated on our vision for Open Source development on Secure Elements on a blog post.

[jubiju]

So there is a closed source part.

The problem is that you don't make that clear enough. This listing leads me to believe it is fully open source when it isn't. I think all Ledger listings should be updated.

Is KeepKey also closed source? I think only Trezor is open.

When did you launch the "S" model?

[EricLarch]

The S is being developped since October 2015, has been launched in beta in March 2016 and launched officially in July 2016.

[jubiju]

My suggestion is to wait 6 months (from July) and update the description of all other Ledger wallets to include "Closed Source"

[btchip]

Hi Jubiju, and welcome to Github.

The problem is that you don't make that clear enough. This listing leads me to believe it is fully open source when it isn't. I think all Ledger listings should be updated.

I'm not sure there's a category for that, and the previous listings state very clearly

While not open-source, it can be deterministically validated.

so I'm afraid you missed that part. I have absolutely no problem adding that the product has parts that are Closed Source and are in the process of being more open, pointing to our architecture and vision as Eric did before.

If this leads to a healthy debate on whether it's preferable to produce something which is fully Open Source but complex to validate for the end user, or something which is partly Open Source but based on secure hardware which has been successfully used for mass production of tamper resistant products in the past 40 years I'm also all for it - we're not really in a hurry to get listed, and there's a need to review the categories to support new products such as Opendime anyway.

Also in my understanding the 6 months period related to the Transparency score in our scenario refers to the client, or would otherwise be in contradiction with the previous statement specifically made for Hardware Wallets

Provides source code and/or detailed specification for blackbox testing if using a closed-source Secure Element

But again, we can take our time.

[jubiju]

I contribute to private projects on github for years under a different user.

What brought me here (I normally don't comment on public projects) is I bought a Leger Nano thinking it was open source. Was not happy with the surprise.

[btchip]

I bought a Leger Nano thinking it was open source. Was not happy with the surprise.

The Nano S is more suitable for developers if you plan to extend it. I'm sorry about your disappointment regarding the Nano, but the product description is quite clear on that point, and it fits into the project submission guidelines as far as I understand.

[jonasschnelli]

utACK.
The only point I'm not sure about is, if we want to list all Ledger products (maybe more to come) on this page or if we should try to keep it at a minimum by ?

[Mendeleyef]

Yes, a Trezor device, a KeepKey device and two Ledger devices won't be fair.

I think you should replace the Ledger Nano with Ledger Nano S.

[EricLarch]

We didn't add the HW.1 nor the Unplugged, but the Nano S is a real innovation, as well as will be the Blue. Nano, Nano S and Blue are three very different products, targeting different use cases, markets and budgets.

Would it be fair to us to have to limit our offerings because the competition is focused on only one product design?

[jonasschnelli]

What about having something like a dropdown or layer-unfold in case of multiple "sub"-products?

[btchip]

Yes, that's quite acceptable as long as it's easy to list different capabilities in different products (for example code availability wise the Nano, Unplugged and Nano S are pretty different)

[crwatkins]

I personally view the bitcoin.org wallet listings as a service to folks looking for a wallet to use. I don't view its purpose as a marketing tool for wallet vendors nor as a storefront or marketplace. As long as a vendor is reputable, it really shouldn't matter which vendor produces any particular wallet. The Ledger Nano and the Ledger Nano S are significantly different hardware wallets, despite having confusingly similar names and being from the same vendor. I believe that our users would be ill-served by combining these two different products in some manner in the listings.

Our current wallet listings UI is being stretched in many places, but the hardware wallet area is not one of them and I'm not concerned about creating any confusion by adding a fourth listing to the existing three. We currently do not have any "vendor parity" criteria that constrains how many listings a given vendor can submit, so I have a hard time justifying the design and implementation of a new and potentially confusing interface at this time.

I'm fine with listing the Ledger Nano S separately from the Ledger Nano.