umbrel I've started work on Trezor integration, but it'll require a fair amount of changes to their firmware since they don't have the same concept of "apps" like Ledger does. It should definitely be possible, though!

    Update about signing arbitrary transactions.

    My plan for the way to support arbitrary transactions turns out not to be possible. The Nano S only has 10Kb of RAM available in total. Not all of that is even available to the individual apps running on the device because part of it is used by the OS. So sending arbitrary size transactions to the device is impossible. A small test shows a transaction containing only 10 payment operations that include a memo is already more than 2Kb.

    So after deliberating the options I've come up with a new plan to support arbitrary transactions. I will have two signing operations. One "super safe" signing operation that only takes a transaction that contains at most one simple payment operation. This method of signing a payment is able to show payment details on the device screen for confirmation. A second, less secure, signing operation that takes only the transaction hash (initially proposed by @dzham ). This second operation will show a warning on the device screen that no data is available.

    It is up to the wallet to choose either one of the methods to sign transactions. A simple payment wallet can use the operation that displays the transaction details for the user to confirm. A more sophisticated wallet can use the operation that signs the hash alone but shows no transaction details on the device.

    The advantage of this approach is that it remains possible to sign arbitrary transactions while xdr transaction parsing can stay very simple, only having to deal with a single payment operation. The alternative would have been more complicated (and thus error prone) xdr transaction parsing while still not being able to support arbitrary transactions.

    Thoughts?

      Hi umbrel , I was talking to one of the devs at stellar yesterday to propose adding the Nano S support to the account viewer [1]. Incidentally he had already had the same thought. This could be the perfect showcase while also being functional at the same time. It would initially be made available in the stellar laboratory [2].

      1. https://www.stellar.org/account-viewer/
      2. https://www.stellar.org/laboratory/

        dupe Why restrict the "super safe" option to a single operation and why the payment operation specifically?

        I may be misunderstanding but you say that 10kb is about 10 payment operations. If so, you can surely support a couple of arbitrary operations in the "super safe" method can't you?

        Actually, why can't you relegate the restriction to the javascript library. In other words, the js library could parse the transaction as JSON (or some other human readable format) and check the size of the transaction before passing it on to the ledger. If the size is to big, it could just return an error to the caller. Otherwise, if the size passes inspection, it could pass it on to the ledger.

        What happens if you pass too much data? Does the device crash?

          istrau2 I've not tried to pass too much data. I suppose it would crash.

          In my initial thinking I was set on displaying all transaction info without allowing simply sending a transaction hash. That would involve a substantial effort to display all the info. Now that I have to let go of that goal because it would mean arbitrary transactions would not be supported the payoff for the effort to display all the different types of transactions does not seem worthwhile anymore. In my mind it would only have been worthwhile if I thereby gained the extra security.

          Actually I think it's a good thing. Looking at the ledger UI logic it seems it would have become too complicated to display all the different stuff, especially if you don't know in advance what will be in the transaction. That also means too much risk of things going wrong and possible endless source of bugs. It might become a nightmare to maintain.

          The way I propose now also means much quicker availability. What I describe is mostly done, whereas otherwise I don't know how long it would take me.

          Hope that makes sense.

          More stuff done:

          • base32 encoding bug fixed
          • added keypair validation
          • xdr parser knows how to skip memos, parse custom assets for display, deal with operation-specific source account
          • added u2f browser support
          • lots of small stuff such as guarding against sending transactions that are too big and detecting more error conditions and displaying more user friendly feedback instead
          • javascript api tests can now be run in the browser (see README for details)
          • officially submitted app to ledger for review

          To be done:
          - create stellar dashboard display glyph icon
          - more manual testing
          - document javascript api usage

          cheers

            dupe

            A bit unrelated to what you're doing, but maybe you know.

            How do the Nano generate the priv keys for other cryptos? I just bought two of these, and I hate their guts already because they don't work with the system I have in place.

            • dupe replied to this.

              dupe

              Gotcha! So you just define a coin type for Stellar, and that's it?

              • dupe replied to this.

                dupe But you probably want to use the same account for all Stellar-based assets I guess.

                That was also my assumption.

                Very nice app,thanks so much!

                • dupe replied to this.

                  @dupe

                  Was able to compile the app, and load it, on MacOS.

                  Trying to communicate with the Nano gives me this though:

                  MacBook-Pro:stellar-ledger-api Johan$ npm run script testGetPublicKey
                  
                  > sledger-api@1.0.0 script /Users/Johan/Code/vendor/stellar-ledger-api
                  > node test/runScript.js "testGetPublicKey"
                  
                  running: testGetPublicKey
                  =>0101050000001ae002010115058000002c8000009480000000800000008000000000000000000000000000000000000000000000000000000000000000000000
                  <=bf00018d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
                  Invalid channel;

                  Any idea?

                  • dupe replied to this.

                    dzham Might be related to Virtual box environment. It is a known issue. The virtual environment locks out the USB port on the host machine. I'm guessing you are trying to run the scripts from the Mac OS host environment after you loaded the app from the virtual box environment. If you want to do that you have to halt the virtual box environment again: 'vagrant halt'. And you may or may not have to reconnect the device. What I did for developing is install nodejs in the virtual environment as well and run the scripts from there.

                    Alternatively you have enabled browser support in the device. I think you can only use either u2f ('browser support') or node-hid at the same time. In that case, you need to disable browser support again to run the node js scripts.

                    HTH

                      NgocTri You're welcome, I'm glad you like it. I'm still applying some finishing touches but it's now more or less done.

                      dupe Alternatively you have enabled browser support in the device. I think you can only use either u2f ('browser support') or node-hid at the same time. In that case, you need to disable browser support again to run the node js scripts.

                      That was it, thanks!

                      publicKey: GAVTL6QDYNTCMAJP2PDRECXINBI4PPZNXXX37CIEZPOCE2KNVMQFIUFM

                      Oh, I guess I need to order ledger now ? Do you know if Ledger Blue worth it and coming any time soon?

                        umbrel Ledger says the Blues are shipping at the end of November.

                        In Trezor news, today I was able to generate a public key and sign a transaction with my custom firmware that implements a generic ED25519 signing method. My next step is to put together a PR so it can hopefully make it into the official firmware!