It's a bit difficult to judge what this PR changes effectively. Can you create a screenshot? I gues the current state is visible in 881. Also pinging @moritzwietersheim to get some input on this.

Sorry! I took a screenshot and forgot to attach it. Now done.

Should be catched in https://github.com/cryptoadvance/specter-desktop/blob/master/setup.py#L40

but that's a valuable addition. Thanks for the PR!

setup.py is not referred in ./DEVELOPMENT.md

Should a developer use setup.py instead of the current described method?

Thanks for taking the time to try this.

I assume you have tried with an older version? If so can you please try with that one?

Checked with 1.0: PDF export correctly displays "native segwit" now, thanks!

It's a PDF backup from Specter printed out, so no option to animate it I'm afraid :D

It's a bit unclear to me though, should Ubuntu be able to just read QR codes out of the box? Or should I install additional software like Zbar?

I looked into creating snaps and tried to recreate a snap, had issues with creating the snap with the above yml. Adding this helped:

    stage-packages: 
      - libusb-1.0-0-dev
      - libudev-dev

However, i aslo realized that this snap is only creating a snap of a specterd. However what most people probably would expect from a specter-snap is more the electron-app than a specterd: The full experience of a local app as easily installable than a snap.

Unfortunately i don't have the time to create that sort of snap but the dump-plugin mentioned later in the video is probably what is needed here.

we had an issue with the PDF saying nested segwit regardless of the actual address type which was fixed in v1.0.0

Confirmed fixed in 1.0 for me

This part is intentionally with xpubs only since it's in a specific export format for compatibility with other software using that same standard

Ok!

Updated the release-notes to prepare for new version

No longer relevant

also mention rate limiting

fixes #862

It seems like the document was written before specter had a user/password auth system?

At the moment the document just talks about using basic authentication via the nginx proxy

Yes, good pointl! Thank you very much.

It's a bit difficult to judge what this PR changes effectively. Can you create a screenshot? I gues the current state is visible in 881. Also pinging @moritzwietersheim to get some input on this.

Thank you, LGTM. Travis-CI-support is slower than usual to add you to the whitelist, though. Let's give them a bit more time ...

Should be catched in https://github.com/cryptoadvance/specter-desktop/blob/master/setup.py#L40

but that's a valuable addition. Thanks for the PR!

It is specified here: https://github.com/cryptoadvance/specter-desktop/blob/master/setup.py#L40

What's missing?

thank you, updated

Does specter DIY support cosigner XPUB validation?

I am trying to gather information for this: https://github.com/cryptoadvance/specter-desktop/pull/885

Thank you very much.

So I just ran the simulator to double check a couple of things but it looks like it can:

• Display own xpub on demand - yes
• Display cosigner xpubs - yes (on wallet import)
• Show Electrum Zpub... and Ypub... formats - yes
• Register xpubs inside the device - yes (on wallet import)

No, I just mean the camera probably too low-quality to scan the QR code, or there is not enough light in the room, or the QR is too dense for it, so you might need to get a better camera, or play with lighting, or if the QR is quite dense, try to animate it (if it's from Specter just clicking it should do it.)

@s-tikhomirov Hi, we had an issue with the PDF saying nested segwit regardless of the actual address type which was fixed in v1.0.0, I assume you have tried with an older version? If so can you please try with that one? Regarding xpub/ zpub, a PR for the next version was already merged to allow toggling between the xpub and zpub formats, making the xpub default everywhere for consistency, it'll be out in the next release.

@mmikeww This part is intentionally with xpubs only since it's in a specific export format for compatibility with other software using that same standard. It uses descriptors, which is a newer standard making SLIP132 (zpubs etc.) obsolete, so that part is just the xpubs. It is always possible to derive the zpubs from them, but these are anyway only useful for Electrum, which has its own export format you can export in the button at the bottom of that export popup.

After more thoughts on the matter, I'd like to propose some improvements.

To import new xpub keys from a device, the user must follow this sequence:

• Specify derivation paths
• Import extended public keys from ledger
• Save the public keys against the device to later create wallets from them

Currently, there are a number of confusing elements with the current screen.

In the device landing screen I can see 5 keys. From this screen I can delete individual keys. It also shows the wallets using this device. However, it does not show which key is used for which wallet. Knowing that a wallet uses a unique derivation path, it would make sense to put the wallet names and links directly in the table. Today, if I click remove I am uncertain whether I am removing a path related to an existing wallet.

Suggestion: In the device landing page, add wallet names/link in the table to correlate them to the derivation path they use.

Then, if I click add more keys, the new screen is pre-filled with 4 keys. Some of these keys were already imported, it is confusing that they are displayed in the "add key" flow. Also confusing that only some of the already imported keys are displayed, not all of them.

I understand these are the default keys that should be used for single sig/multi sig (segwit or nested).

Suggestion: The add keys screen should only displays derivation paths which are not yet imported.

Then, you have 3 buttons:

• edit
• get via usb
• add keys

If you click Add keys then you get an error: xpubs name must not be empty. If Add Keys is not a valid action then the button should not be displayed.

Suggestion: Do not display or grey out the Add keys button until all paths have their xpub loaded.

If you click Get via USB, it loads the xpubs from the device. Once done, you can click again on Get via USB even though all xpubs are loaded.

Suggestion: Do not display or grey out the Get via USB button if all displayed paths have their xpub loaded.

The Add account button allows you to add 4 new derivation paths: Single Sig nested, single sig segwit, multi sig nested, multi sig segwit. It adds all 4 of them. Is that what a user would like to do? I don't believe so.

As a user, I want to create a new wallet from my ledger. I want to setup a new segwit multi-sig wallet. When going through the Add new wallet flow, I realize that I already used all the ledger keys I imported. So I go to the device flow: Ledger Nano S > Add more keys.

I then have to click

1. Edit
2. Add account
3. Select the right number (by default, 0 is proposed even if I already have loaded all the keys for account 0)
4. Add account. This adds 4 new keys to the table.
5. I now need to go and remove the keys I don't intend to use. Maybe I only use multisig and don't want to encumber by device setup screen with useless single sig derivation paths.
6. Done
7. Get via USB
8. Add Keys

Step 3 is non-intuitive: I have to think/check for which account number I haven't yet loaded a segwit multi sig key. Step 5 is cumbersome and should not be necessary.

Suggestion: Do not preload default keys of account 0 in Add Keys screen

Suggestion: Replace the Add account and Add custom derivation buttons with a single (Add path?) button. This button should propose the following option:

• drop down list to choose between single sig nested, single sig segwit, multi sig ..
  • This should default to the latest unload path
• Advance option to pass a custom path

I hope this helps.

Does specter DIY support cosigner XPUB validation?

I am trying to gather information for this: https://github.com/cryptoadvance/specter-desktop/pull/885

fix #875

any improvements to text welcomed

@ben-kaufman @k9ert thanks for the reviews. I've added the requested documentation, but I am not sure if it is in the expected format or level of details for the python functions. For JS, it was easier since there are other classes/methods commented to use as reference.