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 had a similar idea. Did not get yet to the point to make that work... (my lack of java script skills...)
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.
Fortunately, I took precautions against this in the code, so that this dangerous outcome can never happen! (I should have mentioned it explicitly though such that the user is not afraid using this feature!)
The script always checks the whole list for consistency before actually proceeding to generate the graphic outputs, QR codes etc. If a pair [private key ; BTC address] that was entered in the field does not match, then first a warning message will be displayed that the user has to click away, and then in the process of generating the notes/paper wallets (same also for the simple paper wallet w/o art design) each respective non-matchig pair will be replaced by a randomly generated pair instead. Just try it out by entering intentionally wrong BTC addresses or priv keys, and you'll see! :-)
Example:
List of Priv keys = A, B, C, D
List of BTC addresses = a, x, c, d (i.e. 2nd pair [x, C] is not consistent),
then the generated paper wallets/bitcoin notes will be
[a, A], [r, R], [c, C], [d, D],
with [r, R] being a new randomly generated key pair ("x" and "B" are discarded)
In general, you are right that there is probably no great need for the btc address field at all. My idea for including it anyway was the following: The user is able to make sure that he enters the right set of private keys, e.g. those that really match "his/her" list of vanity BTC addresses. Then he/she does not have to browse through the list of generated paper wallets/bitcoin notes and scan the list visually, but instead he/she knows for sure that
if there is no warning message displayed, then all the private keys that were entered do match the BTC addresses entered.
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.
Intersting idea. But this is neither a "paper wallet" nor a "bitcoin note" then, but more something like a special bank account number handed over to the client for certain purchases, if I understand this correctly. Generally I think a good idea, but I think it would also require a different design and therefore justify an extra tab in the bitaddress.org tool if this is intended to be included.
Just to get aware of the
classification that we have here:
(1) paper wallets
(2) bitcoin paper notes (=bitcoin paper bills)
(3) sale slips with only BTC addresses printed on it, w/o priv keys.
Items (1) and (2) have a lot in common: Both contain public BTC address and the matching priv key on one piece. So in both cases, if you own the piece, you own everything that is sent to that BTC address. The difference is that (1) is normally
intended for loading the address by the owner him/herself, while (2) is just intended for passing the piece further or spending it, although it can technically be equally well used for "purpose (1)". Also, (2) always has a denominated face value printed on it, whereas (1) typically does not (but it can say something like ">=5 BTC for example"). Also, (2) must have the private key sealed, while for (1) this is optional.
Technically,
(2) is a superset of (1). If you produce a piece of type (2), it can do everything that (1) can do for you, plus something more. So I consider the amount of commonalities sufficient to justify having one common tab in the bitaddress.orrg tool for producing pieces of category (1) and (2).
On the other hand, category (3) is completely different. If I transfer BTCs to the indicated BTC address on this piece, it means that these bitcoins are NOT owned by me any more but by someone else. So type
(3) kind of pieces is not a superset or subset of (1) or (2) but something completely different.
So the design should be fundamentally different to avoid confusing type (3) kind of pieces with type (1)/(2) kind of pieces:
While (1) and (2) could be designed like something that has value (like a cash note, possibly with a face value included), the design of (3) should more look like an invoice or a slip with somebody else's bank account number.
