Creating offline transactions from just the script hashes/indexes and private keys?Or some multisig magic?

N1bor

I'd like to do something with split keys for the use case of savings wallets. The goal would be to have a secure paper wallet if both computers are compromised. A casual user should be able to use bitaddress.org at work and at home to print each part of the key. Keys will need to be split and matched in bulk because once you bring a key back together it is "compromised" (if you are sufficiently paranoid) and must be spent immediately to another address. Users would divide their savings up into convenient amounts so they can cash out small portions of their savings without compromising the whole amount. For example taking 1000 BTC and sending 50 BTC to 20 bitcoin addresses. You print two copies of each half key (A & B). Keep one set of copies together in a safety deposit box (A + B). Keep one half of the keys at work (A) and one half of the keys at home (B).

upon clicking the Print button, if the user has not generated new addresses since the last time he clicked it, it should tell him: "For security, new addresses will be generated before printing. Continue?" (OK=regenerate and print, Cancel = do nothing).

This will help avert a potential disaster if a user unknowingly prints a large batch more than once and then distributes the duplicate batches.

I realize it's of little use if the user chooses Print from his browser rather than the Print button in the page, but it's far better than nothing, and I think most users will use a Print button provided to them anyway when available, knowing it gives them the overall best chance of printing a print-friendly version. The advanced user also maintains the option to reprint a batch if needed: he can just use the browser's Print function.

are there people scrutinizing these new releases to ensure there are no changes to the private key generation or presentment that shouldn't be there?

I review pull requests sent by others. On various occasions people have reported bugs in the code and version 0.1 to 0.4 are no longer online; I made the project open source and available at github at request on this thread and started the commits with v0.5.

v0.5 to v2.0 are online and I recommend you use the last version you have reviewed yourself if you read JavaScript.

Stephen Gornick checks that the online versions checksum matches what is in github.

I would like to invite others to review the safety of the code. I have attempted to arrange the code in a way that the libraries can be reviewed separately from the ninja code. I have recently refactored the wallet code such that each wallet has separate code and does not use methods from the other wallets. So reviews can be focused on the wallet you personally use.

At the bottom is "Transfer", then you see a tab for "Redeem". Then click the magnifying glass to scan the QR code. Scan, click "Redeem coins" and you're done. The app tells you how much coin was on the address and it will automatically sweep that amount into your Mt. Gox account. If at a later time any more funds arrive at that address, another transaction will be made to sweep them at that time as well.

Another method to redeem these keys is with Blockchain.info/wallet. This is only done through the web interface, and not from the Blockchain for Android (or iOS) mobile app.

One feature that would be useful would be the ability to redeem a private key.

[...]

But if Easywallet were to have this feature (to redeem a private key), I could then hand a paper Bitcoin to someone and then that person can use a mobile to go to Easywallet.org, click Redeem, scan the private key QR code and be done. After the transaction confirms they can spend it. That's easy!

I can verify that the BitAddress.org website has been updated and returns the same HTML from the commit with the description v2.0 (54c26d38e68eb87ea5b083f07091b547e10f8eac) in github: - https://github.com/pointbiz/bitaddress.org

To confirm this I first check the sha1sum hash of the html returned by a request to http://bitaddress.org:

At the bottom is "Transfer", then you see a tab for "Redeem". Then click the magnifying glass to scan the QR code. Scan, click "Redeem coins" and you're done. The app tells you how much coin was on the address and it will automatically sweep that amount into your Mt. Gox account. If at a later time any more funds arrive at that address, another transaction will be made to sweep them at that time as well.

Another method to redeem these keys is with Blockchain.info/wallet. This is only done through the web interface, and not from the Blockchain for Android (or iOS) mobile app.

One feature that would be useful would be the ability to redeem a private key.

[...]

But if Easywallet were to have this feature (to redeem a private key), I could then hand a paper Bitcoin to someone and then that person can use a mobile to go to Easywallet.org, click Redeem, scan the private key QR code and be done. After the transaction confirms they can spend it. That's easy!

It is presently able to take two private keys in hexadecimal, and provide the EC product of the two, along with its corresponding public key and bitcoin address. I would like this page enhanced.

Here is what I'd like changed:

1. I would like it to accept key input in any private key format the codebase recognizes (compressed private keys may either be disallowed, or simply not allowed to be combined with uncompressed keys). Specifically that should include "minikeys" (30-characters) as well as the usual 51-character code that starts with '5'.

2. I would also like it to accept user input of up to one public key - in other words, one box can contain a public key and the other box can be a private key, and the resulting public key and bitcoin address will be shown (with the corresponding private key unavailable, of course).

The reason is that I would like to start offering 2-factor physical bitcoins (mostly my gold-plated savings bar), and have BitAddress.org be the only tool the other party needs to securely participate in this sort of offering.

The reward for completion: Five gold-plated two-factor Casascius savings bars engraved with the vanity addresses of your choice (because you will generate your addresses starting with five different public keys I give you, one for each bar.) Shipping is included.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper wallets instead.

It is presently able to take two private keys in hexadecimal, and provide the EC product of the two, along with its corresponding public key and bitcoin address. I would like this page enhanced.

Here is what I'd like changed:

1. I would like it to accept key input in any private key format the codebase recognizes (compressed private keys may either be disallowed, or simply not allowed to be combined with uncompressed keys). Specifically that should include "minikeys" (30-characters) as well as the usual 51-character code that starts with '5'.

2. I would also like it to accept user input of up to one public key - in other words, one box can contain a public key and the other box can be a private key, and the resulting public key and bitcoin address will be shown (with the corresponding private key unavailable, of course).

The reason is that I would like to start offering 2-factor physical bitcoins (mostly my gold-plated savings bar), and have BitAddress.org be the only tool the other party needs to securely participate in this sort of offering.

The reward for completion: Five gold-plated two-factor Casascius savings bars engraved with the vanity addresses of your choice (because you will generate your addresses starting with five different public keys I give you, one for each bar.) Shipping is included.

I have a request for two slight (?) (but very useful) enhancements to the javascript html file on bitaddress.org:

Both are for the "Paper Wallet" tab:

1) To offer the option of using my own private keys instead of new random ones.2) To offer an option for reducing the size of the secret key QR code such that it can be covered by a 2.5 cm (1 inch) square hologram sticker. For this the secret QR code size should be only 1.5 cm in size, such that 0.5 cm border is left on each side where the hologram sticker can be attached to. The size of the white square surrounding the QR code could be reduced from 3 cm to 2.5 cm to match the size of the hologram sticker.Also, when this option is checked, the private key should not be printed in plain text on the bill, and instead a place holder text could be printed, reading for example:[For the private key see QR code in the square field labeled "Spend"]Alternatively (if there are worries that the QR code might not be readable anymore if this small), there could be another checkbox opting for printing the plain text secret key instead of a QR code within this 1.5 cm x 1.5 cm area.

You may ask why I do not use http://print.printcoins.com/ instead of requesting this feature from bitaddress.org.The reason is quite simple: printcoins.com uses server-side php scripts etc. to generate the printed bills, so the private keys are sent to the server (and this even unencrpted via http right now). To generated 100% safe printed bills with the "printcoins.com method" I would need to download the various source files, set up my local web server and run this code on that server on an offline PC. On the other hand, for bitaddress.org I just need to view the HTML source, copy-paste it to a single new txt (or "html") file on my PC and can run it immediately in any browser on any offline PC.

Translating all the printcoins.com stuff to javascript is probably much more work than adding the two features above to bitaddress.org's javascript html file, that's why I assume I have higher chances to get this done at this place.

With this feature, everyone would ultimately have a really easy method for generating bitcoin bills absolutely securely for purposes of private promotion/gifts/etc.

----------Here is an illustration of how I think it should look (smaller QR code (or alternatively plain text)) and changed text next to the square:

And here is my idea how I would create a gift/promotion bitcoin paper bill, if I do not have any holograms at hand:I use a solid-black printed square of paper (here indicated in red for illustration purposes) and attach it with 4 stripes of transparent tape (here indicated as transparent cyan coloured lines):

If I use a paper material that has a coarse surface, it shall not be possible to remove the transparent tape (and therefore view the private key) without trace.The hand-written message/greeting/hand-written signature serves as a "pragmatic" kind of counterfeit protection.

I think this is an easy to use do-it-yourself gift/promotion bitcoin paper bill.

1) To offer the option of using my own private keys instead of new random ones.

I think this feature is kind of for very small niche... Just take the graphic from elsewhere and create the note yourself.

Of course, manually patching the bill together with a graphics program is always possible. However, the idea of solutions like bitaddress.org or printcoins.com is to simplify the job and be able to print it with little efforts and no special skills.

Moreover, I do not agree at all with the statement that this feature is for a "very small niche" only - at least not less of a "niche" than what "printcoins.com" is made for. Or one could define the Bitcoin community as a whole as a "very small niche" today, which is probably true compared to the number of people paying with EUR and USD today, so with the same argument one could justify that any development in the Bitcoin world is just useless. Similarly, any special developments within the Bitcoin world could be considered niches by themselves, since each such development may be of interest only for a subset of all Bitcoin users - So with the same argument all these things are unnecessary either. So where do you draw the line for what is a "niche" and what is not, and who decides it?

--> Instead, let's wait for an open discussion and let's not have the idea killed in advance by classifying it as a "very small niche" by some individuals who are not interested in the respective development/feature - maybe other individuals are very well interested.

I think anybody skilled in javascript can add such feature to bitaddress.org's html file - I may try to also hack this into the code myself, but I have never programmed javascript, so not sure if I can do it...

All we need is to identify the point in the javascript code where the size of the QR code is defined, and to identify the place where the random addresses are generated for the paper wallet and replace it by an interface where it is read in from a list of copy-pasted public-private-key pairs.

PS: One motivation for using non-random addresses for such paper bitcoin bills is to use vanity addresses for personalized gifts, e.g. like 1TomXjk4d93jfZT45RZEtcEtcEtcEtcEtc or whatever.

I think support for custom private keys is a great idea and I have an idea how it could be handled without much change to layout and interface.

There is already a bulk wallet tab. So when you choose the paper wallet maybe it can check here first and deposit the keys in that tab after completion. That also provides a way for the creator to back them up in bulk with a simple copy/paste. A slight alteration of the paper wallet code could check that tab before generating and if a series of keys/addresses is already present then it could use them to create the bills instead of generating new ones.

This way you could mix random keys, replace some with vanity keys, or take the ones from your existing wallet and paste them in to make paper bill backups. It would also possible to use a seed and have all your bills generated sequentially from the seed (eg. using an Electrum temporary wallet listing and pasting it here).

I could also see the ability to use vanity addresses useful as custom "gift certificates" for various businesses. Using this method above avoids re-designing layout and perhaps only a simple help text would let people know this is an option.

@Michael_S - I have javascript skills and can code this if you like this idea. I'd prefer to do it if it were to be accepted into the main version but I guess it's also possible as a custom version.

I think anybody skilled in javascript can add such feature to bitaddress.org's html file - I may try to also hack this into the code myself, but I have never programmed javascript, so not sure if I can do it...

@Michael_S - I have javascript skills and can code this if you like this idea. I'd prefer to do it if it were to be accepted into the main version but I guess it's also possible as a custom version.

Well, I did it! I acquired some JavaScript skills - sufficient to do the necessary changes. And I did all the features that I was mentioning a few days ago, plus more! It works very neatly, and the interface is still readable. Also thoroughly tested, works with Windows and Linux versions of FIREFOX.

All changes only affect the tab "Paper Wallet" in bitaddress.org! Here a visual impression first (screesnshot):

Support of specifying ANY arbitrary image on the user's PC as the art background (will be forced to a fixed aspect ratio of 1.862:1 though)

Can enter free text for "amount" and for the center area of the bitcoin note (compare screenshot above).

Vanity-Address generation supported (but very very slow)

--> My enhanced html file (it's basis is the bitaddress.org html file as downloaded from their website on 2 Dec 2012) can be downloaded here, and you can run it offline in standalone-mode on any suitable browser (for sure Firefox works fine while Opera runs faster as long as I keep working on the PC/browser, but Opera fails rendering correctly for the actual printouts. Other browsers not tested.).

@pointbiz: I would be happy if these changes went inside the official version of bitaddress.org! It is very nice because now everybody can plot his/her own bitcoin notes fully securely (=offline) without any need for IT expert knowledge for setting up a webserver (like printcoins.com'2 solution) or configuring scripts and working on the console (like salfter's solution), and still the notes have very good print quality (600 dpi)!

PS: Thanks to pointbiz (=bitaddress.org), salfter, casascius, printcoins.com and the other "printed bitcoin paper note activists and visionaries" that have inspired me and provided me with material (source code and designs) that I could build on for making this happen. What a great community!

PPS: My donation address is still unknown in the blockchain - I am wondering if and when this is going to change...

Wow. That's an amazing amount of goodies. I've downloaded and will give it a try. The only thing I would suggest as an improvement (I think it's a bit overwhelming for newbies), is perhaps making all the new stuff initially hidden in a fold with an "Advanced" button at top. So they can use it as before, or click "Advanced" and see all the cool things you can do.

I also suspect that having the address field may lead to serious mistakes if not used carefully. ie. people don't get the key-address alignment right and bills get printed with mismatch. Given that a key should never print with the wrong address I'm not sure that being able to paste the addresses has any benefit.

I can also see a use case for printing without private key. Retail store loads their cash register with sale slips that have addresses from the store wallet. Then during a sale the clerk can hand the slip to the customer to scan, note the sale details and place it in the register with cash as a sale, ready for end-of-day processing. So maybe an option for no key would be useful.

My enhanced html file (it's basis is the bitaddress.org html file as downloaded from their website on 2 Dec 2012) can be downloaded here, and you can run it offline in standalone-mode on any suitable browser (for sure Firefox works fine while Opera runs faster as long as I keep working on the PC/browser, but Opera fails rendering correctly for the actual printouts. Other browsers not tested.).

When developing my note generator, I considered using HTML and CSS to overlay text on SVG artwork. One snag I ran across was that the printed output from Chrome looked like it was rasterized at 72 dpi or thereabouts before it was sent to the printer. Printed output from Firefox was as good as the printer could manage; the output from Chrome was clearly inferior. Rendering to PDF from both browsers exhibited the same behavior. I suspect you might run into the same print-quality issues with your generator running under Chrome, but I haven't had a chance to test it. If my hypothesis holds, it'd be a bit of a shame...Chrome is so much faster at running JavaScript.

(As an aside, these issues are part of what led me to shift from HTML & CSS to PostScript for layout...that, and that I'm a little bit more proficient at bending PostScript to my will. It takes browser print-quality issues out of the equation.)