Also, great work. Finally a project of creating addresses written in javascript. Many cold wallets can be created from your project.
Topic: Bitcoin Visual private key generator - page 2. (Read 2087 times)
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.
Also, great work. Finally a project of creating addresses written in javascript. Many cold wallets can be created from your project.
ricardosuperx, HeitorMessias, thank you for your feedback. If you have any ideas for project development please do not hesitate to tell me.
Very cool, i ll test this soon, very interesting 
Very Good! I played a little...LOL
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
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
-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? Furthermore, it's known ECDSA can be cracked by O(n1/2) algorithms. So the security of bitcoin is actually 2^128
-snip-
-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.
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(n1/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.
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...
-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? Furthermore, it's known ECDSA can be cracked by O(n1/2) algorithms. So the security of bitcoin is actually 2^128
-snip-
-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.
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(n1/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.
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-
-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.
Furthermore, it's known ECDSA can be cracked by O(n1/2) algorithms. So the security of bitcoin is actually 2^128
-snip-
-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.
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.
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...
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.
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...
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...
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-
-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.
Furthermore, it's known ECDSA can be cracked by O(n1/2) algorithms. So the security of bitcoin is actually 2^128
-snip-
-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.
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-
Furthermore, it's known ECDSA can be cracked by O(n1/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 2256. Specifically, the order of g written in hexadecimal is
n = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141.
This means that we get approximately 256/2 = 128 bits of security because √(2256) = 2128.
https://www.johndcook.com/blog/2018/08/14/bitcoin-elliptic-curves/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 2256. Specifically, the order of g written in hexadecimal is
n = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141.
This means that we get approximately 256/2 = 128 bits of security because √(2256) = 2128.
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
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.
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.
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.
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.
legendary
Activity: 2464
Merit: 3878
Hire Bitcointalk Camp. Manager @ r7promotions.com
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 :-DThe 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.
Have you considered to add it in the website. Visitors will have real interest in that case to give it a try.
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.
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.
legendary
Activity: 2464
Merit: 3878
Hire Bitcointalk Camp. Manager @ r7promotions.com
Thank you and good to see the conversation is still alive.
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
I also created the repository on GitHub and added the link to the initial message of this topic: https://github.com/MrFreeDragon/VisualBTC
I also created the repository on GitHub and added the link to the initial message of this topic: https://github.com/MrFreeDragon/VisualBTC
Chances of twopeole drawing the same pattern? Relatively high.
Nice question. And it has been already discussed in this topic earlier. Of course the pattern could be not secure.
I will add the warning message not to create the real money bitcoin address based on visual pattern, and use these addresses only for educational purposes or just for funny small gifts to the friends, which could be unusual and cool in some cases.
The most secured way to create the address is to flip the physical coin and fill each cell of the square based on the coin's outcome.
Jump to: