You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add qrcode support for BIP38, WIF and stealth #330
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.
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?
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.
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.
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.
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.
Activity
[-]qrcode should support BIP38 and WIF private keys[/-][+]qrcode support for BIP38 and WIF keys[/+][-]qrcode support for BIP38 and WIF keys[/-][+]qrcode support for BIP38, WIF and stealth[/+]skaht commentedon Apr 4, 2016
Note the qrcode should also support altcoins. This creates an ambiguity for -v used by altcoins.
evoskuil commentedon 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.
[-]qrcode support for BIP38, WIF and stealth[/-][+]Add qrcode support for BIP38, WIF and stealth[/+]thecodefactory commentedon Aug 16, 2018
Given the various types of formats requested, would it make sense to extend bx to have two additional qr commands such as
base16-qr-encodeandbase58-qr-encodethat take arbitrary inputs that are properly encoded and offers all of the options otherwise available onqrcode?evoskuil commentedon Aug 16, 2018
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 commentedon Aug 16, 2018
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
qrcodecommand 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 commentedon Aug 17, 2018
Why base58 encoding?
thecodefactory commentedon Aug 17, 2018
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 commentedon 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 commentedon 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.