<p>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 <a href="https://github.com/libbitcoin/libbitcoin-explorer/wiki" rel="nofollow">Wiki</a></p>

<p><code>% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx base58check-encode -v 239</code></p>

<p><strong>91avAoeY5k21BDnfaHNLv63frRJhn5RmnEw4XgcsbfpWxPg1A9N</strong></p>

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

<p><code>echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff01" | bx base58check-encode -v 239</code></p>

<p><strong>cMahgGtgBvsRn7SZFuFCuKGnV8H8yxYLegVcaRsLL2LjD6WFLuAg</strong></p>

<p>More details for using bx for altcoins can be found at <a href="https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-Mappings" rel="nofollow">Altcoin Version Mapping</a>.  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.</p>

<p>Use what ever QR-encoding mechanism you like (e.g., <a href="https://github.com/fukuchi/libqrencode" rel="nofollow">QRencode</a> and encode either <strong>91avAoeY5k21BDnfaHNLv63frRJhn5RmnEw4XgcsbfpWxPg1A9N</strong> or <strong>cMahgGtgBvsRn7SZFuFCuKGnV8H8yxYLegVcaRsLL2LjD6WFLuAg</strong>, but remember the following 256-bit hex encoded private key</p>

<p><strong>0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff</strong> </p>

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

<p>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.</p>

<p>The uncompressed public address for the very simple private key can be found by:</p>

<p><code>% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public -u | bx ec-to-address -v 111</code></p>

<p><strong>n2nkn4KFNtNbu6Q6GQPZwNZWDiiNsmm9d8</strong></p>

<p>Similarly, the compressed public address can be found by:</p>

<p><code>% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public | bx ec-to-address -v 111</code></p>

<p><strong>n47QBape2PcisN2mkHR2YnhqoBr56iPhJh</strong></p>

CC BY-SA 3.0
2016-07-03T03:39:52.067Z
2016-07-03T03:39:52.067Z
skaht
<p>It could vary well be an issue with the app.</p>

<p>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 <a href="http://barcode.tec-it.com/en" rel="nofollow">http://barcode.tec-it.com/en</a></p>

<ul>
<li><p>If you aren't able to sweep/scan the newly created "paper wallet" then its an issue with the app.</p></li>
<li><p>Another issue could be the funds haven't been verified by any other nodes.</p></li>
<li><p>Probability suggest that you missed typed the address or key. (It happens more then you think.)</p></li>
</ul>

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

CC BY-SA 3.0
2016-05-02T23:03:44.563Z
2016-05-02T23:03:44.563Z
T. Thomas
<p>I would like to generate a bitcoin paper testnet wallet.<br>
A paper wallet is a QR code of a private key and a QR code of a bitcoin testnet address, <br>I assume it can be generate juste like this link does : <a href="https://api.qrserver.com/v1/create-qr-code/?size=150x150&amp;data=privateKeyOrBtcAddress" rel="nofollow">https://api.qrserver.com/v1/create-qr-code/?size=150x150&amp;data=privateKeyOrBtcAddress</a></p>

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

CC BY-SA 3.0
2016-07-03T02:47:03.923Z
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
<testnet><qrcode>
Generate QR Code tesnet
onepix
# Generate QR Code tesnet

(Asked by: username_0 on 2016-05-02)

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 ?

**Tags:** testnet, qrcode

> **Comments:**
> **username_1**: 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.  

---

## 2 answers

### Answer by username_1 on 2016-07-03. Score: 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](https://github.com/libbitcoin/libbitcoin-explorer/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](https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-Mappings). 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](https://github.com/fukuchi/libqrencode) 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**


---

### Answer by username_2 on 2016-05-02. Score: 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.


---

