Quote from: pooya87 on Today at 04:40:05 AM

Keep this educational and don't create any serious addresses using this. Most importantly is that you won't find bugs by just testing it a couple of times with random cases, there are a lot of edge cases that you may not know of and may not face in your "random tests" but can encounter in a real scenario.
Off the top of my head since you mentioned Java and are probably using the BigInteger class,is that you may forget the necessary padding for the public key and use a smaller than 32 byte x/y coordinate in the pubkey for your hash and end up with coins that can never be spent.

The best real life example I can think of that is similar to what I explained here is the bitcore-lib by Bitpay written in Javascript that had a similar bug with lack of padding. https://github.com/bitpay/bitcore-lib/issues/47

I would also say that generating a serious key (to send actual funds to) using your own code is not a good idea even if you verify the correctness of the key->address using a secondary tool. Because there can be other vulnerabilities in your code like your RNG being weak.

Thanks. As I said it's for educational purposes only. Btw I have used BitcoinJ which provided me with some classes that were kind of plug-and-play.

Quote from: ranochigo on Today at 03:07:34 AM

As I've mentioned, if you're able to import the address into a well-known wallet, it should be fine. They are unlikely to allow you to import a private key that cannot be spent. The first one would be the best, if you can do so. It doesn't affect the security nor the privacy of your paper wallet so long as you spend the coins back to yourself.

But in order to broadcast the transaction you will need to use the internet. So this requires importing the private key to an application that's connected to the internet. Therefore your wallet immediately becomes hot.