Bitcoin Visual private key generator - page 2.

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Quote from: BlackHatCoiner on August 01, 2020, 08:22:34 AM

What is the difference of compressed and uncompressed private key? (importing for wallets)
-snip-

"Compressed public keys were introduced to bitcoin to reduce the size of transactions and conserve disk space on nodes that store the bitcoin blockchain database"
For every private key we can generate compressed and uncompressed legacy (starting with 1) bitcoin address*. Every public key contains x and y coordinates of elliptic curve: for uncompressed the public key contains both coordinates, but for compressed only x coordinate and "sign" for y - so the compressed key is less in size, and less in transaction fees as well.

More details are here: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04.asciidoc

* Of course there are also segwit (starting with 3) and bech32 (starting with bc) bitcoin address. They are not generates by my tool. However segwit and bech32 also generated from compressed public key.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

What is the difference of compressed and uncompressed private key? (importing for wallets)
Also, great work. Finally a project of creating addresses written in javascript. Many cold wallets can be created from your project.

MrFreeDragon

sr. member

Activity: 443

Merit: 350

ricardosuperx, HeitorMessias, thank you for your feedback. If you have any ideas for project development please do not hesitate to tell me.

HeitorMessias

member

Activity: 222

Merit: 33

"Non est ad astra mollis e terris via" Seneca _

Very cool, i ll test this soon, very interesting

ricardosuperx

member

Activity: 109

Merit: 13

A positive attitude changes everything *_*

Very Good! I played a little...LOL

MrFreeDragon

sr. member

Activity: 443

Merit: 350

I have made some updates of the tool - added new features and advanced options. Also made small optimization for faster calculation.

New features (Inverse and Rotation):
While creating the visual private key, now it is possible to inverse the key (all bits will be changed to the opposite) and also to rotate the key (the bits 16x16 square will be rotated clockwise).

Advanced options (Explorer, block lines, online check):
Added the possibility to change the default block explorer (by default it is BTC.com, but now it is possible to change it to blockchain.com, blockchair.com, ViaBTC.com, etc.)
In order to create the less bit key the user can block some lines from edditing (block lines option), and the bits in the blocked line will be preset to 0.
Also added the online check option. If this option active, the tool checks the generated address for received transactions. For the already used addresses the tool shows the total volume of received transactions and changes the colour of the cell.

The block line option and online check were requested by github users.

Some screenshots of new features/options:

Rotate and Reverse features (pattern used for clear explanation):

Online check options:

Visual private key generator: https://btckeygen.com

Edited: added link to the tool

Saint-loup

legendary

Activity: 2604

Merit: 2353

Quote from: MrFreeDragon on October 23, 2019, 03:47:11 AM

Quote from: Saint-loup on October 22, 2019, 05:51:32 PM

Quote from: MrFreeDragon on October 22, 2019, 02:20:36 PM

-snip-

Quote from: Saint-loup on October 22, 2019, 01:03:12 PM

Furthermore, it's known ECDSA can be cracked by O(n^1/2) algorithms. So the security of bitcoin is actually 2^128
-snip-

This square root could be applied if you know the pulic key. But the public key is unknown for addresses without outgoing transactions. And modern wallets also designed in the way to generate new addess after every spending, so knowing the public key actually useless.

I'm not sure "modern wallets" don't reuse old addresses, where have you seen that exactly? Huh

In fact I think people prefer using few addresses, and especially beginners. Most people don't even know they can check all the transactions of their HD wallet on blockchain explorers by simply using their xpub/zpub key.
-snip-

I didn't write that HD wallets re-use old addresses. I just wrote that they generate the next address and "transfer" the change to it remained after the spending.
You wrote that "ECDSA can be cracked by O(n^1/2) algorithms", however this could ne done ONLY if you know the public key of the address (without public key you still need 2^256 operations). You know the public key if there are outgoing transactions from the address, however in the case of HD wallets, as soon as you make the payment, the whole remained balance is transferred to new address there oublic key is unknown. So, you still need 2^256 operations.

I understood what you meant and I answered you most of people don't do that so it doesn't concern the majority of transactions.
The change feature only transfer the change of the UTXOs used for paying the transaction, not all the UTXOs of the address, so the other UTXOs and their funds remain at the same address.
Moreover I don't think the change feature is enabled by default in the "modern wallets", as I said above people mostly don't like this feature, especially the beginners. They prefer to be able to easily check and manage few addresses. Look at the transactions of people in a blockchain explorer, you will see change is mostly sent back to the sending addresses...

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Quote from: Saint-loup on October 22, 2019, 05:51:32 PM

Quote from: MrFreeDragon on October 22, 2019, 02:20:36 PM

-snip-

Quote from: Saint-loup on October 22, 2019, 01:03:12 PM

Furthermore, it's known ECDSA can be cracked by O(n^1/2) algorithms. So the security of bitcoin is actually 2^128
-snip-

This square root could be applied if you know the pulic key. But the public key is unknown for addresses without outgoing transactions. And modern wallets also designed in the way to generate new addess after every spending, so knowing the public key actually useless.

I'm not sure "modern wallets" don't reuse old addresses, where have you seen that exactly? Huh

In fact I think people prefer using few addresses, and especially beginners. Most people don't even know they can check all the transactions of their HD wallet on blockchain explorers by simply using their xpub/zpub key.
-snip-

I didn't write that HD wallets re-use old addresses. I just wrote that they generate the next address and "transfer" the change to it remained after the spending.
You wrote that "ECDSA can be cracked by O(n^1/2) algorithms", however this could ne done ONLY if you know the public key of the address (without public key you still need 2^256 operations). You know the public key if there are outgoing transactions from the address, however in the case of HD wallets, as soon as you make the payment, the whole remained balance is transferred to new address there oublic key is unknown. So, you still need 2^256 operations.

Saint-loup

legendary

Activity: 2604

Merit: 2353

Quote from: MrFreeDragon on October 22, 2019, 02:20:36 PM

Quote from: bitmover on September 25, 2019, 05:39:14 PM

Quote from: Saint-loup on October 22, 2019, 01:03:12 PM

Quote from: MrFreeDragon on September 25, 2019, 05:21:09 PM

Nobody could crack 256 independent outcomes generated by a physical coin fliped offline. It is 2^256 possible combinations - you can not imagine how much is it! It is the most secure way for paper wallet creation, as it does not use any computer random algorithms.

2^256 is the security of the bitcoin network, all keys are generated within that range.
-snip-

No in fact the security of the bitcoin network can't be 2^256 because there are only 2^160 addresses existing thanks to the RIPEMD160 hashing. RIPEMD160 provides hashes on only 160bits, so addresses have several different private keys. To crack one address in brute-force you don't need to try each 2^256 keys but only 2^160 at most.
-snip-

Yes, you are talking about the colission here. And here it is offtopic. You are welcome to discuss this in my separate topic: https://bitcointalksearch.org/topic/example-of-btc-collision-2-different-priv-key-to-the-same-btc-address-5185726
From the point of the exact private key the security is 2^256. But of course due to RipeMD160 there is actually no need in exact private key, and on average 2^96 keys could be suitable.

Quote from: Saint-loup on October 22, 2019, 01:03:12 PM

Furthermore, it's known ECDSA can be cracked by O(n^1/2) algorithms. So the security of bitcoin is actually 2^128
-snip-

This square root could be applied if you know the pulic key. But the public key is unknown for addresses without outgoing transactions. And modern wallets also designed in the way to generate new addess after every spending, so knowing the public key actually useless.

I'm not sure "modern wallets" don't reuse old addresses, where have you seen that exactly? Huh

In fact I think people prefer using few addresses, and especially beginners. Most people don't even know they can check all the transactions of their HD wallet on blockchain explorers by simply using their xpub/zpub key.

For being more on-topic, I think we can get a little bit more robust brain wallet without using an unmemorable salt, by creating a key with your graphic brain wallet and then using this key(private, public or address) with a passphrase in a classic text brain wallet. Thus we just need to remember the drawing and the passphrase.

Otherwise I think the best keys for (half)brain wallets are hash256 of unique files(own photos for example).
You can keep your file in the cloud, in your e-mail box, on your smartphone, on your windows computer or everywhere you want, nobody will guess that's the key of your wallet. And if you want to make a discreet transaction you can simply send the file to the person you want to pay...
But that's not a true brain wallet unfortunately. Embarrassed

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Quote from: DiamondCardz on October 22, 2019, 03:44:43 PM

Very nice project, it's almost deceiving in how simple it makes private keys look - people have already asked if it's easy to brute force keys because of it, I feel that they don't understand how many combinations of 256 bits you can get!

I would appreciate it if you put a warning in telling people explicitly to use it offline, especially as you encourage people to put in their own private keys to 'visualize' it in your application. Obviously anyone doing that would be crazy to do it online, but there are a lot of newbies in this community nowadays...

Thank you for your feedback.

As for the recomendation to use it offline I made it in "Information" block (link at the bottom):
"[9] Security.
The code is open source. All the private keys are generated on client side, in your browser. This site does not copy or store the information generated by you. Even so we recommend downloading this site (it is available in zip) on your computer, disconnect from the internet and generate the key offline."

zip is available for download form the site directly, and the code is also pubslihed on github, so everybody can have a look at the code and confirm that there are no any back doors or other things to store alien private keys.

I personally like the idea to download the project and generate the key offline - so it makes the process completely secure. Moreover, while you use the physical coin, nobody can assume what outcomes did you have. Other projects (even offline) could generate the key pseudo-random - you will see different points on the screen during your text typing or mouse moving, but you can not be sure that the the final key is random :-) With physical coin you can be sure!

PS. I ordered 16-side dice, and some later will make video how to generate a key with that dice (HEX symbols could be typed directly to the input field of Visualize section). Only 64 tosses are requred (instead of 256 coin flips) - one 16dice toss contains 4bits (from 0000 to 1111). So, the key could be generated within 4-5 minutes instead of 15-20min.

DiamondCardz

legendary

Activity: 1134

Merit: 1118

Very nice project, it's almost deceiving in how simple it makes private keys look - people have already asked if it's easy to brute force keys because of it, I feel that they don't understand how many combinations of 256 bits you can get!

I would appreciate it if you put a warning in telling people explicitly to use it offline, especially as you encourage people to put in their own private keys to 'visualize' it in your application. Obviously anyone doing that would be crazy to do it online, but there are a lot of newbies in this community nowadays...

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Quote from: Saint-loup on October 22, 2019, 01:03:12 PM

Quote from: MrFreeDragon on September 25, 2019, 05:21:09 PM

Nobody could crack 256 independent outcomes generated by a physical coin fliped offline. It is 2^256 possible combinations - you can not imagine how much is it! It is the most secure way for paper wallet creation, as it does not use any computer random algorithms.

2^256 is the security of the bitcoin network, all keys are generated within that range.
-snip-

No in fact the security of the bitcoin network can't be 2^256 because there are only 2^160 addresses existing thanks to the RIPEMD160 hashing. RIPEMD160 provides hashes on only 160bits, so addresses have several different private keys. To crack one address in brute-force you don't need to try each 2^256 keys but only 2^160 at most.
-snip-
[/quote]

Yes, you are talking about the colission here. And here it is offtopic. You are welcome to discuss this in my separate topic: https://bitcointalksearch.org/topic/example-of-btc-collision-2-different-priv-key-to-the-same-btc-address-5185726
From the point of the exact private key the security is 2^256. But of course due to RipeMD160 there is actually no need in exact private key, and on average 2^96 keys could be suitable.

Quote from: Saint-loup on October 22, 2019, 01:03:12 PM

Furthermore, it's known ECDSA can be cracked by O(n^1/2) algorithms. So the security of bitcoin is actually 2^128
-snip-

This square root could be applied if you know the pulic key. But the public key is unknown for addresses without outgoing transactions. And modern wallets also designed in the way to generate new addess after every spending, so knowing the public key actually useless.

Saint-loup

legendary

Activity: 2604

Merit: 2353

Quote from: bitmover on September 25, 2019, 05:39:14 PM

Quote from: MrFreeDragon on September 25, 2019, 05:21:09 PM

Nobody could crack 256 independent outcomes generated by a physical coin fliped offline. It is 2^256 possible combinations - you can not imagine how much is it! It is the most secure way for paper wallet creation, as it does not use any computer random algorithms.

2^256 is the security of the bitcoin network, all keys are generated within that range.

-snip-

No in fact the security of the bitcoin network can't be 2^256 because there are only 2^160 addresses existing thanks to the RIPEMD160 hashing. RIPEMD160 provides hashes on only 160bits, so addresses have several different private keys. To crack one address in brute-force you don't need to try each 2^256 keys but only 2^160 at most.

Furthermore, it's known ECDSA can be cracked by O(n^1/2) algorithms. So the security of bitcoin is actually 2^128

Quote

You undo exponentiation by taking logarithms, so the process of solving for k is called the discrete logarithm problem. The security of elliptic curve cryptography depends on the difficulty of computing discrete logarithms.

Counting bits of security
The best algorithms for solving discrete logarithm problem in a group of size n currently require O(√n) operations. How big is n in our case?

The base point g was chosen to have a large order, and in fact its order is approximately 2²⁵⁶. Specifically, the order of g written in hexadecimal is

n = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141.

This means that we get approximately 256/2 = 128 bits of security because √(2²⁵⁶) = 2¹²⁸.

https://www.johndcook.com/blog/2018/08/14/bitcoin-elliptic-curves/

https://bitcointalksearch.org/topic/bitcoins-public-key-security-level-2859033

https://bitcointalksearch.org/topic/why-does-256-bit-ecc-offers-equivalent-security-of-128-bit-symmetric-encryption-1007619

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: naska21 on October 14, 2019, 07:06:40 AM

Quote from: MrFreeDragon on September 25, 2019, 01:09:21 AM

snip

Funny tool but I wonder if there is any algorithm capable to randomly choose the cells in that 16x16 square. In fact I have found how to randomly select Excel's cells that can be applied for such task but I'm not quite sure if the method they offer is truly random.

if you don't think of it as "selecting cells" then the solution would become clear. (same with your link about excel). basically it is two steps: 1) assigning a number to each cell. 2) selecting a random number!
in this case each cell is the binary representation so it has only two modes: on and off or 1 and 0. so all you have to do is generate a random number, convert it to binary and set cells state using the bits.
by the way that is what the random button at the bottom of the square is supposed to do.

bitmover

legendary

Activity: 2352

Merit: 6089

bitcoindata.science

Quote from: MrFreeDragon on October 12, 2019, 04:06:17 PM

I also made a video instruction how to create a bitcoin private key by flipping a coing 256 times: https://youtu.be/WyBdYhwweaE

The video is fast moving, but in reality the total my time to flip the coin 256 times was 16 minutes. I tried to do it very fast.
Considering the time for filling the cells and printing the key, the total time for private key generation will be approximately 20 minutes.

Good job.
This method is very cool, as you can generate a private key without a computer.
however, to get the public address we need a computer.

naska21

hero member

Activity: 1358

Merit: 635

Quote from: MrFreeDragon on September 25, 2019, 01:09:21 AM

snip

Funny tool but I wonder if there is any algorithm capable to randomly choose the cells in that 16x16 square. In fact I have found how to randomly select Excel's cells that can be applied for such task but I'm not quite sure if the method they offer is truly random.

AB de Royse777

legendary

Activity: 2464

Merit: 3878

Hire Bitcointalk Camp. Manager @ r7promotions.com

Quote from: MrFreeDragon on October 12, 2019, 04:06:17 PM

I also made a video instruction how to create a bitcoin private key by flipping a coing 256 times: https://youtu.be/WyBdYhwweaE

The video is fast moving, but in reality the total my time to flip the coin 256 times was 16 minutes. I tried to do it very fast.
Considering the time for filling the cells and printing the key, the total time for private key generation will be approximately 20 minutes.

Okay this is fun :-D
Have you considered to add it in the website. Visitors will have real interest in that case to give it a try.

MrFreeDragon

sr. member

Activity: 443

Merit: 350

I also made a video instruction how to create a bitcoin private key by flipping a coing 256 times: https://youtu.be/WyBdYhwweaE

The video is fast moving, but in reality the total my time to flip the coin 256 times was 16 minutes. I tried to do it very fast.
Considering the time for filling the cells and printing the key, the total time for private key generation will be approximately 20 minutes.

AB de Royse777

legendary

Activity: 2464

Merit: 3878

Hire Bitcointalk Camp. Manager @ r7promotions.com

Thank you and good to see the conversation is still alive.

MrFreeDragon

sr. member

Activity: 443

Merit: 350

I added the warning messages about drawing patterns and suggested to create the address only with the coin flip. Also added the messsage to the "Visualize Key" section to think twice before visualizing the key. "Drawing" pictures, logos, figures and use them for private keys could be made only for educational purposes, or/and some small bitcoin gifts to friends Cool

I also created the repository on GitHub and added the link to the initial message of this topic: https://github.com/MrFreeDragon/VisualBTC

Topic: Bitcoin Visual private key generator - page 2. (Read 2122 times)