Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add qrcode support for BIP38, WIF and stealth #330

Open
skaht opened this issue Apr 4, 2016 · 9 comments
Open

Add qrcode support for BIP38, WIF and stealth #330

skaht opened this issue Apr 4, 2016 · 9 comments

Comments

@skaht
Copy link
Contributor

skaht commented Apr 4, 2016

Title is self explanatory.

Should also support stealth addresses.

@evoskuil evoskuil changed the title qrcode should support BIP38 and WIF private keys qrcode support for BIP38 and WIF keys Apr 4, 2016
@evoskuil evoskuil changed the title qrcode support for BIP38 and WIF keys qrcode support for BIP38, WIF and stealth Apr 4, 2016
@skaht
Copy link
Contributor Author

skaht commented Apr 4, 2016

Note the qrcode should also support altcoins. This creates an ambiguity for -v used by altcoins.

@evoskuil
Copy link
Member

evoskuil commented Apr 4, 2016

Given that the encoding accepts a payment address, altcoin versioning is already incorporated. As ek, wif and stealth are not payment addresses they are not supported. The qrcode version remains necessary and independent of these altcoin versions, as they are attached to distinct commands.

@evoskuil evoskuil added this to the 4.0 milestone May 12, 2016
@evoskuil evoskuil changed the title qrcode support for BIP38, WIF and stealth Add qrcode support for BIP38, WIF and stealth May 18, 2016
@thecodefactory
Copy link
Member

Given the various types of formats requested, would it make sense to extend bx to have two additional qr commands such as base16-qr-encode and base58-qr-encode that take arbitrary inputs that are properly encoded and offers all of the options otherwise available on qrcode?

@evoskuil
Copy link
Member

If so I wouldn't use those names :) It sounds to me that there is a desire to create qr codes from arbitrary data. This implies a standard data format and a single command to convert that format to an image file. We already have various data formatting options. Those could presumably be applied to the outputs of relevant commands.

@thecodefactory
Copy link
Member

Heh, command naming is not a strength of mine :-)

I can personally see the benefit of being able to generate qrcodes for BIP38 encrypted keys, and we already support payment addresses. WIF and stealth (as requested) could be useful too. Unless I'm missing something, I think we could agree on a common base58 format. The qrcode command is already used to convert payment addresses to an image file, so maybe we just need to loosen up the input from payment_address to base58? That does lose the advantage of making sure in the payment case, it's actually a correct payment address though, which might be a fair reason to keep it separate. Not sure.

@evoskuil
Copy link
Member

Why base58 encoding?

@thecodefactory
Copy link
Member

Why base58 encoding?

There are existing tools for sending to (and retrieving from) QR codes representing base58(check) payment addresses and also importing encrypted BIP38 keys (also in that encoding). Seemed like a decent way to go about it?

I can't really speak to WIF or stealth, as I'm not sure of how useful QR codes would be for those in general.

@thecodefactory
Copy link
Member

thecodefactory commented Aug 17, 2018

Ok, so with the exception of stealth (just because I don't know much about them), I guess they're all base58(check) encoded, which seems ok ... ?

@evoskuil evoskuil removed this from the 4.0 milestone Jan 3, 2019
@evoskuil
Copy link
Member

evoskuil commented Mar 6, 2021

Stealth is now moot and dropped from v4 server indexing (the linear search would be a problem is it was in fact widely used), but keeping this open for the other formats.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants