cantonbecker / bitcoinpaperwallet Goto Github PK

This is nice, but it would be nicer to have some graphics that would make for a good-looking paper wallet printed on a monochrome laser printer. Got any ideas?

Hi Canton,

I'm a huge fan of the project (have purchased stickers and envelopes from you before!) and would like to contribute by helping refactor the monolithic HTML file down into separate components. Is this sort of contribution welcomed and/or encouraged?

Proposal:

1. Separate global JS modules into separate files in /libs folder, or include them with Bower
2. Separate application-level code into separate modules/files in /src folder
3. Use AlmondJS (with RequireJS) to join these libs and src together into a unified JS file that is then included by the HTML when the site is deployed.

This would dramatically simplify the HTML page, separate the JS source from the static layout, and allow developers to contribute to the individual code-sections. The JS can be all built together into one monolithic JS file which I still recommend), but they start off as individual pieces. I don't know if having all the JS in one HTML file is intentional or a byproduct of the development process, but I'd like to help and contribute if I can.

Thanks,
John Tibble

Images do not load at all when the program is used.

When using the wallet to generate a BIP38 encrypted paper wall against a compressed pubkey, the decrypted key does not match the input.

For example, the compressed private key for "17bbQL696yc37SxbXwAs9Zi6yCwzBwhFH" is "L452QJZK6rn2imxzQrJiBArX25reWqwvdBuKzmv11YDQb7cgGHJf" which is compressed, when encrypted with "bitcoinpaperwallet" yields a BIP-38 wallet of "6PRJAp2oK4NXHe6dvPjazggtcSt6Sr737D79UA2K4isba4GGtfJWSrq3Hx".

However, decrypting the above wallet in bitcoinpaperwallet yields a public key of "1JpuWDAUoKHFVNzL3cmuhR2psac7JqfNfC" instead, with a private key of "5KKW9Ay1gF2hzjGsx8pQcZW8q24tvXXesrv5eMwKkwRWkN6eCSF".

There appears to be a bug with how bitcoinpaperwallet is encrypting compressed wallets.

The unit test is implemented with bitcoin addresses only. If you intend to set up another default currency e.g. Litecoin:

default:
    setCryptoCurrency('Litecoin');

Source

the unit test will fail.

I would like to make a paper wallet for a new coin called Magnetcoin which is too forked from Bitcoin. https://github.com/magnetcoindev/MagnetCoin/tree/master/src Could you please let me know how to fork this paper wallet for this new crypto.

I don't know if this problem lies with bitcoinpaperwallet or Firefox. I filed a bug report over at https://bugzilla.mozilla.org/show_bug.cgi?id=1178056 just in case. To restate the problem here, Firefox seems to thwart or ignore my attempts to change the zoom and/or horizontal scale parameters. If I print the calibration sheet with the "ignore scaling and shrink to fit page width" checkbox in the print dialog checked, I get an image that's somewhat in scale, but offset about 3 or 4mm too far left. If I uncheck that box, the best I can get is a ruler that's too big and the right side of the box is cut off. Monkeying with either parameter positive or negative only makes things worse.

Calibration does work perfectly with Chrome and parameters of zoom=5 horiz=5. I'm using Debian 8 with a Brother HL-5250DN monochrome laser printer.

Hi,

I've been thinking that bulk generation of paper wallets would be very useful when printing wallets that are meant to be handed out.

Ideally, I am imagining an extra tab asking for the number of paper wallets to be generated (N) and a target folder. The output to the target folder should be:

• N two-page PDF files containing all the generated paper wallets, with numbered filenames
• A .csv of all the private keys
• A .csv of all the public keys

How hard would this be and how many Dogecoin in bounty would motivate you? :)

I distribute paperwallets a lot but never without words along the line that I will take the money back if they don't take it within a year and I'm super paranoid about getting a hoard of lawyers against me for stealing the waiters tip that came to be worth millions down the line. I therefore added to my paperwallets that the maker of the wallet also has access to the funds and that these has to be moved to an actual private wallet to be save. Also I added that I will remove funds after 90 days with the intention to remove funds after one year or so. Also I guess it makes sense to add functionality to add personal text on the paperwallets. I added my email address to mine.

See pointbiz#132 - the same issue affects this repository.

I can see fee-less coins having a certain advantage when used with paperwallets.
But I can't draw a nice design, otherwise I'd open a pull request... I'll be looking for artists though...

I'd love to have access to the PSDs (I assume you Photoshop) to ease the creation of other wallets.

For extra paranoia I generate my keys with vanitygen (which I now see in a commit message can be imported.) and have a python script to throw that on paper but I can't find what license the back and front images are. I'd share my scripts with my modifications if that's not in violation with the license.

Printing the wallets in b/w results in reasonably good wallets but the highlighting gets lost. Maybe use underline instead of color.

Just a small suggestion to improve the security a bit. To prevent prying eyes (or screen recording software) from seeing the password, it would be best to

• Remove the paperencryptpassphrase div.
• Set the paperpassphrase input type to password
• Add another input to confirm the passphrase to avoid the user making a typing mistake.

On the plus side, by using a password input if someone makes a non-HTTPS rehost of the website, the end user will be warned by their web browser that it is not secured.

Just an idea... if the user could upload their own background picture / font .. etc for the wallet.. then people might start a 'paper wallet design gallery' site enticing submissions from the bitcoin community.

Heya,
I know bitcoinpaperwallet uses a good chunk of bitaddress' code -- bitaddress has a nice Grunt-based build system whereas bitcoinpaperwallet just uses one flat file. To make it easier for others to add functionality, would you consider offering a src directory alongside the flat file?

when you print the wallet.. the 'back' prints bigger than the 'front' and when you use the website you can see that indeed on the site the back is significantly bigger than the front

It would be great and more secure. Please consider adding BIP0038 support.
You can watch the code at https://github.com/pointbiz/bitaddress.org

Hello,

I generated some paper wallets some time ago using this tool. I am attempting to sweep my paper key, and have noticed that the private key is 50 characters, not 51.

I have scanned the QR code and verified that it is the same 50 character long value.

I was able top replicate this bug on about 10% of wallets generated using the current release. If you click "Generate" many times once in a while the public or private key will be short by 1 character.

What can be done to recover the missing character? Can you elaborate on how the keys are generated in the first place?

Thank you.

@cantonbecker
Hello,
I really appreciate bitcoinpaperwallet and I use it for Bitcoins paper wallet.
But is it possible to add Ethers paper wallet (Ethereum), please?
I think Ethereum is not really the same pattern than Bitcoin and it's not so easy... but it exists.
I know it exists https://github.com/ryepdx/ethaddress.org - https://ryepdx.github.io/ethaddress.org/ (for Chrome) - it works well...
Or it exists also https://www.myetherwallet.com/ - https://github.com/kvhnuke/etherwallet
You can print an Ethers paper wallet with myetherwallet.com .
I'm absolutely not a dev and I don't know how you can adapt this to bitcoinpapperwallet... but I know you can do it because you're very gifted...
Thanks in advance for your answer.

The readme states:
"gpg --recv-key 36E1D9B6".
You should change it to your long key id. I believe the correct long key id is 0x9277AD7136E1D9B6 but you better double check that!

With the rather high fees for transactions now, methods to reduce these are welcome.
As I understand it, SegWit transactions reduce the on-block transaction size, so reduce data, and reduce fees. Maybe by half. I read an article which suggested if everyone moved to SegWit, we wouldn't currently have the transaction backlog and high fees.
There are other (not so pretty) SegWit paper wallet generators out there, so technically it is possible, but this paper wallet generator is one I know and trust.
I give these wallets to friends and I know they will really appreciate me looking after them if I give them SegWit wallets.
Are there any plans on the roadmap to add SegWit functionality to this generator?

Thanks.

As the QR code and the address is generated on top of the graphics, it would make things easier if the rest of the text can be added programmatically.

This would make it easier to in case of a new graphics to be available for all supported languages. E.g. the Chinese New Year design can be available for Chinese, English, Czech, ... on one click instead of having to do graphics editing and adding more large files to the repo.

Of course this can be tricky, as it might need to include the relevant font in the repo and some ways to do text formatting for better look. Just starting a conversation. :)