Display Output in Specter Friendly Way

[mflaxman]

From btcguide/btcguide.github.io#7

Some ideas:

Option A: Easiest solution

A string of text for copy-pasting. Specter uses a somewhat bizarre format that is:
[xfp/path]slip132pub)
like this:
[083AA3DB/48h/0h/0h/2h]Zpub75b...bhK (they also accept 48'/0'/0'/2' but I think ' is harder than h for humans)

Notice that path has no leading m/

Option B: JSON File (to download)

A .json file that Specter can understand as it's one less step that users can mess up:

{
    "xfp": "083AA3DB",
    "p2wsh": "Zpub75X6f85rTN5uUwonxhEbVWe1HGd1kevff2nx9DMBHgp9R9mto2PgASkeqRs42w5fyT1MN9XG89VoDpx5sZSaB4yUJwaXd7ixVsX1FssYWxG",
    "p2wsh_deriv": "m/48'/0'/0'/2'"
}

A good name for this file would be seedpickerxp-083AA3DB.json as coldcard uses ccxp-083AA3DB.json

Option C: QR Code (to scan)

This would also be good, but I need to research the Specter format.
There are many use-case where you wouldn't do this though (perhaps you generate offline and burn to DVD for example).

---

I think the best choice is Option B for now (as it's the lowest common denominator), with the goal to add a QR code soon?

[merland]

Thanks for the rich input. Agree that Option B sounds like a good start. Then we can test the flow of things in practice, and see where that takes us.

[mflaxman]

Thanks @merland, it's always a pleasure writing up nice specs for your repo because you so consistently deliver.

Now that Specter is getting so good, I think your library is about to get a lot more interest. This feature is probably the last thing that normies need to be able to confidently use seedpicker to add security/redundancy to their setup.

[stepansnigirev]

@mflaxman You don't have to use slip132, Specter also understands [xfp/derivation]xpub like in Bitcoin Core, and can display the key in this format as well - we have a switch now that toggles derivation and xpub encoding between canonical and slip132.
Both h and ' work for hardened derivatoin.

For json files we currently support ColdCard's json file formats, but can easily add something more reasonable as well.

Regarding QR codes - the same as for text - [xfp/derivation]xpub should work fine. Also, all json-like formats that Cobo Vault uses, but I am more a fan of simple plaintext for that. If you want to encode more than one xpub in the QR code you can separate it with \n and Specter will understand that.

[mflaxman]

Thanks for chiming in @stepansnigirev!

Re slip132 vs traditional xpub formatting, SLIP132 is useful in that it maintains interoperability with Electrum (which IIRC doesn't accept xpubs for multisig). I think Specter-Desktop is far superior, but having a backup/redundant system is very comforting for end-users. For example, it makes it easy to configure an eternally quarantined / airgapped Electrum watch-only instance that is only used to verify receive addresses (working on a tutorial of this here).

[stepansnigirev]

AFAIK all software wallets except Bitcoin Core use slip132, so we kinda stuck with it...
But master fingerprint and derivation paths are also necessary for PSBT, so we came up with this weird structure that is Core-like but not quite.

I completely agree, having a backup option for software wallet if something doesn't work with the main one is very important.

[merland]

@stepansnigirev Thanks for valuable insights! I agree with @mflaxman that Specter is looking very good and promising.

I have a working implementation of this feature on my machine now, that produces a one-line file that I have verified works with Specters' Choose files button. In your opinion, what file association should i use for this file? It's not a .json and .txt may be confusing(?)

[mflaxman]

It's not a .json and .txt may be confusing(?)

I thought "Choose files" only accepts a JSON file? Is this option B or something else? Sorry if I'm missing something obvious!

[merland]

I tested with a file containing only one line:
[5436d724/48'/0'/0'/2']xpub6E79FaRWLSJCAgA2jDHRvyrWKwT6aSmR685zptzyYPvmUd44omcxZ1NAzDtbdFBvEADjcVbV4NzTDwQeU6oiSV9KGiMSWhjANZjbfUHkm3Y

Which worked nicely. The form may accept some json format too, but I haven't seen anything about that.

[merland]

@mflaxman Sorry, I misunderstood. I have now re-read your inital post and realized that the json you supplied is actually working. I understood it as more of a wish/request. So, Spectre accepts several formats, good! But the GUI doesn't say much about this :)

[merland]

After that initial confusion (my bad), I opted to use the .json format for the export. (So the question to you @stepansnigirev is not valid anymore)

The feature is live and working now, but I have not spent too much thinking about UX or wording... Also, the code needs some refactoring/cleanup.

Looking forward to any feedback.

[stepansnigirev]

I will answer anyway :)

Specter supports different file formats for uploading:

• ColdCard json files that they create for Electrum and Generic json
• Plain text file with line-separated keys in the format [fingerprint/derivation]xpub where xpub can be either canonical or slip132.

Specter doesn't care about file extension, so even some custom extension should work fine.

BTW this doesn't look right:

[merland]

Thanks. Wow, that's bad. Don't know what has happened. Will fix asap.

…

On Mon, 7 Sep 2020, 13:53 Stepan Snigirev, ***@***.***> wrote: I will answer anyway :) Specter supports different file formats for uploading: - ColdCard json files that they create for Electrum and Generic json - Plain text file with line-separated keys in the format [fingerprint/derivation]xpub where xpub can be either canonical or slip132. Specter doesn't care about file extension, so even some custom extension should work fine. BTW this doesn't look right: [image: Screenshot 2020-09-07 at 13 51 50] <https://user-images.githubusercontent.com/1706012/92384978-56ba2800-f111-11ea-9c88-ec2412ff0f22.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADOTZGBD6ULXERVTDCGAV3SETCTBANCNFSM4QTLSBLQ> .

[merland]

@stepansnigirev Fixed now, thanks for noticing!

[mflaxman]

Sorry for the delay, I was out of town. I just tested this out and it looks great!

Nit: would it be easy to format this in a more human-readable way (with newlines and indents) as shown in example B?

For 23x zoo this would look like the following...

Current

$ cat seedpickerxp-669dce62.json 
{"xfp":"669dce62","p2wsh":"Zpub74sb5KB3Ak1RwabGr8SHQnMTkd2mC3boVDgPf1jBFNxcXh7Nx4KV3XakPDtWLN5RpszdM7qcBN4wm7xreh8Ys2xYUBqQ9GtkTN8h5kRVecc","p2wsh_deriv":"m/48'/0'/0'/2'"}

Proposed:

$ cat seedpickerxp-669dce62.json | python -m json.tool
{
    "p2wsh": "Zpub74sb5KB3Ak1RwabGr8SHQnMTkd2mC3boVDgPf1jBFNxcXh7Nx4KV3XakPDtWLN5RpszdM7qcBN4wm7xreh8Ys2xYUBqQ9GtkTN8h5kRVecc",
    "p2wsh_deriv": "m/48'/0'/0'/2'",
    "xfp": "669dce62"
}

[merland]

No worries, thanks for verifying it!
I was planning to do the pretty-printing, but I must have forgot, so good that you reminded me! Simple fix, committed and deployed now.
Do you think this issue can be closed?

Would love more ideas for more ideas to make SeedPicker work even better together with your excellent guide.
I have some ideas on how to restructure SeedPicker to better fit the developing usecase(s). Like changing from basic vs advanced to last word calculation vs xpub calculation. Any thoughts appreciated.

[mflaxman]

Awesome!

Ya, maybe new/separate issues for future improvements would make sense? Closing this.

I'm curious what you have in mind. To me the big split on use-case is you have single-key uses where you just want to append the 24th word checksum (I'm not a fan of this, I think single-key sig is too risky for non-experts) and multisig cases (where you want to append the 24th word but also calculate the fingerprint, Zpub, etc).

Mainnet/testnet is another orthogonal option (that should be highly encouraged for beginners).

Then you have pro users who want their own derivation paths, want to do stuff with xpubs, may want p2sh-wrapped segwit or even legacy p2sh (ugh), want to validate an existing seed (which may not use the alphabetically first word for the checksum), etc.

I'm going to clean up my code for a CLI version for experts, but that's not so nicely suited for normies as your tool (which I'm a big fan of).

[merland]

Thanks for your input. All valid points!
Another orthogonal (sortof) aspect that I have thought about is the fact that the initial calculation of the 24th word (only) is completely safe. If someone hacks SeedPicker and changes the SeedPicker code, they can not inject any malicious code or switch any addresses. He/she can only create an invalid checksum word, and that would be discovered when the seed is being entered into any hardware wallet (during validation)
And since the code is being run on a safe machine that is (should be) wiped afterwards, this hacker cannot leave anything malicious behind. As a result, the code does not need to be understood or audited, making a "normie" being able to use it and understand that it is safe.

The code that calculates the xpubs, on the other hand, is highly susceptible to malicious code. It would take a programmer to make sure the code does not produce the wrong xpubs.

So, one idea would be to divide SeedPicker into these safe and less safe parts.

---

Having said all this, I think the best strategy now is to keep cool and try to understand what the best next step is. If you include the Specter export feature in your guide, I could try to run through the guide as a user/reader and see if I find any wrinkles with the process. Even better would be if some normies would run through the guide and voice their questions/issues!

The main objective of SeedPicker right now is to work well together with btcguide.github.io :)

[mflaxman]

Yes please do run through! You can even submit that PR yourself.

btcguide.github.io and seedpicker.net pair together excellently. Maybe even kill the references to Electrum? Electrum is sadly too hard for normies, so advanced users will be able to figure it out whereas normies will be confused by references to Electrum (if using Specter).

[merland]

I could probably write a first draft of that section, at least. Not entirely sure what aspects you want to focus on. Stay tuned.

I agree about Electrum, and I have already started to strip references to it. Maybe it's time to take the final step...

[mflaxman]

Awesome, would love that first draft!

The secret to a good open-source site is to iterate quickly and not make the perfect the enemy of the good :)