0

I would like to generate a bitcoin paper testnet wallet.
A paper wallet is a QR code of a private key and a QR code of a bitcoin testnet address,
I assume it can be generate juste like this link does : https://api.qrserver.com/v1/create-qr-code/?size=150x150&data=privateKeyOrBtcAddress

But when I'm trying to read it via Testnet3 android app, funds are not recognized.
When I read the QR Code from a QR Reader app, I see correctly the content (privateKey for instance).
Should I conclude that the application has a problem with this feature or did I miss something ?

  • Paper wallets are not forced to be in a quick response (QR) formant. However, testnet WIF-encoded private keys can be quick response (QR) encoded. – skaht Jul 3 '16 at 2:47
1

Here is an example of taking a 256-bit hex-encoded private key and creating an uncompressed Wallet Input Format (WIF) private key for testnet using the libbitcoin v3.0 bitcoin-explorer (bx) command line interface. bx sub-commands manual pages are located on the right column of its Wiki

% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx base58check-encode -v 239

91avAoeY5k21BDnfaHNLv63frRJhn5RmnEw4XgcsbfpWxPg1A9N

Similarly, here are the results for the associated compressed public key. (Note by convention that "01" is tucked on to the private key.)

echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff01" | bx base58check-encode -v 239

cMahgGtgBvsRn7SZFuFCuKGnV8H8yxYLegVcaRsLL2LjD6WFLuAg

More details for using bx for altcoins can be found at Altcoin Version Mapping. There is a table up top of the wiki that provides insight as to why 239 and 111 are used as versions in bx commands above and below.

Use what ever QR-encoding mechanism you like (e.g., QRencode and encode either 91avAoeY5k21BDnfaHNLv63frRJhn5RmnEw4XgcsbfpWxPg1A9N or cMahgGtgBvsRn7SZFuFCuKGnV8H8yxYLegVcaRsLL2LjD6WFLuAg, but remember the following 256-bit hex encoded private key

0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

is one of the worst private keys ever... but makes the point real clear we have a 256-bit hex-encoded key.

Be aware if the funds are deposited to an uncompressed public address and you provide the private WIF key for a compressed address an import or sweep is not likely to work.

The uncompressed public address for the very simple private key can be found by:

% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public -u | bx ec-to-address -v 111

n2nkn4KFNtNbu6Q6GQPZwNZWDiiNsmm9d8

Similarly, the compressed public address can be found by:

% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public | bx ec-to-address -v 111

n47QBape2PcisN2mkHR2YnhqoBr56iPhJh

0

It could vary well be an issue with the app.

To test if its the app or the public/private keys you can generate a qr code for each using an external qr generator such as http://barcode.tec-it.com/en

  • If you aren't able to sweep/scan the newly created "paper wallet" then its an issue with the app.

  • Another issue could be the funds haven't been verified by any other nodes.

  • Probability suggest that you missed typed the address or key. (It happens more then you think.)

Check these things. once you are sure that its non of these update your post with more info.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.