Since there has been a discussion about how Bitcoin addresses can be safely generated as the point sum of two public keys, you ought to consider making Bitaddress.org support creation of such addresses. This has generated a lot of interest, and would be a relatively simple change.
The result of making the change I propose, is that someone could paste in an EC point generated from somewhere else (e.g. smartphone) and the entire sheet of paper wallets would then have "half" private keys. (they are still full length, but they are only half of what's needed to spend the funds).
The other "half" needed to redeem the funds would be the private key used to create that other EC point. Basically, the paper wallet would be completely immune to a compromised machine or even a fake website, as long as the attacker didn't also control the independent source of that other EC point.
In brief:
1. Allow a user to paste in a public key (which is 65 bytes). Detect typos by verifying that X and Y are on the curve. Recall that a public key is an EC point.
2. You generate a Bitcoin address exactly the same way - but as you are computing the Bitcoin address - right after you generate the public key (pubkey = privkey * G), you do an EC point addition, adding in the public key you were just given. (so, pubkey = privkey * G + point)
3. You encode the private key in some way that indicates that it is only half of a private key. This clues redeemers into the fact that some other key is needed. (I would like to propose that this be signalled by using something other than 0x80 as the version byte when doing the base58 encoding, perhaps something that makes the Base58 coded number start with '6' instead of '5').
I will put a bounty on it. One of my silver coins mailed to the address of your choice.
The result of making the change I propose, is that someone could paste in an EC point generated from somewhere else (e.g. smartphone) and the entire sheet of paper wallets would then have "half" private keys. (they are still full length, but they are only half of what's needed to spend the funds).
The other "half" needed to redeem the funds would be the private key used to create that other EC point. Basically, the paper wallet would be completely immune to a compromised machine or even a fake website, as long as the attacker didn't also control the independent source of that other EC point.
In brief:
1. Allow a user to paste in a public key (which is 65 bytes). Detect typos by verifying that X and Y are on the curve. Recall that a public key is an EC point.
2. You generate a Bitcoin address exactly the same way - but as you are computing the Bitcoin address - right after you generate the public key (pubkey = privkey * G), you do an EC point addition, adding in the public key you were just given. (so, pubkey = privkey * G + point)
3. You encode the private key in some way that indicates that it is only half of a private key. This clues redeemers into the fact that some other key is needed. (I would like to propose that this be signalled by using something other than 0x80 as the version byte when doing the base58 encoding, perhaps something that makes the Base58 coded number start with '6' instead of '5').
I will put a bounty on it. One of my silver coins mailed to the address of your choice.
I'm reading that thread now... your bounty has peaked my interest.
