Bitcoin Forum

I wrote a coin address generator in Java.

https://github.com/MrMaxweII/Bitcoin-Address-Generator

https://user-images.githubusercontent.com/34688939/75117189-a18dba00-566f-11ea-9ff1-2c1db29ded1a.png


Would someone like to help and feel free to test the software?



Freeware and open source

The Coin-AddressGenerator creates a private key in Wallet Import Format WIF, as well as the associated coin address and public key.
A paper wallet with QR code can be created and printed out.



Start the program

https://github.com/MrMaxweII/Bitcoin-Address-Generator/releases/download/V3.1.0/CoinAddressGeneratorV3.1.0.jar


The "Coin_Address_Generator.jar" file is located in the "release" folder. You can start this under Windows if Java is installed simply by double-clicking.
On Linux, type in the console: java -jar CoinAddressGeneratorV3.1.0.jar



This is a Java application, so you need to install Java!

https://java.com/de/download/



Multicoin

There is a large list of coins to choose from that can be imported. However, some coins may not work properly because the coin parameter list is quickly out of date and cannot be kept up to date. It is the responsibility of each user to check that the keys created are correct! Use of this software is at your own risk!



Input:

There are three ways to create the private key:

    - Entry as text: Any text can be entered. This text then becomes the private key with a hash, Public key and the Bitcoin address generated.

    - cube sign: There can be 100 dice characters in Base6 (also characters between 1 and 6). This includes: 1=1, 2=2, 3=3, 4=4, 5=5, 6=0.

    - The private key can also be entered directly in all common formats: Hexa, Base58, Base58 compressed and Base64. Checksum check is implemented.



output

    The format of the generated keys and addresses can be set under "Settings"
    the public key is given in hexa
    The coin address can be output in WIF-uncompressed, WIF-compressed, P2SH and Bech32
    The QR code of the private key and the coin address is displayed



Issue of the coin amount

    If the internet connection is active, the coin amount belonging to the key is displayed
    The amount is queried on a suitable website
    If no internet connection is available, nothing is displayed.



Save and open the wallet

An encrypted wallet with any number of keys can be saved. A strong password must be entered for this. To increase security, encryption is carried out in succession using AES and Twofish. In addition, the encryption contains a certain brute force protection, which extends the runtime with the help of a scrypt hash.



Create a paper wallet

The surface of the program can be printed out or saved as an image.

Thank you very much.  :)

@BitSlapped   
So I specialize in Java and currently have no plans to do anything with PHP or other programming languages. But you never know what the future will bring.


@Aloys65
Yes, I have a project in mind with transaction functionality.
But I still don't know if I will really do that.
Maybe there will be a second program with transactions. Let's see.

Interested, isn't the same system websites that generates the paper wallet work? Or you're using a different hashing to generate the pub/priv key?

Anyway I installed it and was quite happy about how it went out! Maybe you can do something similar and generate a better way to help in mixing the btc between same addresses generated by the same wallet. It might be great to see a mixer in a wallet.

Sent you my last merit, totally worth for the work you've done

Just curious. You use 100 dice rolls. So the number of possible private keys that gives is:

6^100 = 653318623500070906096690267158057820537143710472954871543071966369497141477376

but the maximum number of Bitcoin private keys is a factor of 5.6 less than that at:

115792089237316195423570985008687907852837564279074904382605163141518161494336

So how do you handle that situation. In other words, what happens if someone rolls the dice 100 times and gets a number that is higher than the largest number of Bitcoin private keys ?

Most people, including myself, use 99 dice rolls since,

6^99 = 108886437250011817682781711193009636756190618412159145257178661061582856912896

which is a factor of about 0.94 the maximum number of Bitcoin private keys.

Thanks

I use the same hash SHA256 as others.
No I can't program a mixer in a wallet, I wouldn't know how to do it.







Bitaddres.org or other generators using base6 make a mistake, they use a smaller set of numbers and thus reduce the number space. This error is not critical, but it is also not necessary.
https://github.com/pointbiz/bitaddress.org/issues/181

I do not make this mistake and use the entire number range. by mod (p)
Since it is a modular number space, it does not matter if dice numbers larger than mod (p) are rolled, since the numbers start from the beginning, like a clock.

Thank you for the response. I like your method since it makes use of the full maximum private key space.

But a further question for you please.

The maximum number with base 6 using 100 digits is 5.642 times more than the maximum number of Bitcoin private keys.
6^100 / 115792089237316195423570985008687907765725278347314657735981263638985499361600
= 5.642

I understand you are using the modulus to wrap around as you say, “like a clock”. But if I understand correctly this then means that the last 6th time you start to go around the clock, you only get 0.642 (or 64.2%) of the way to the end and then must stop. Is that correct ? I think yes since you only have 6^100 digits.

If yes, then the probability of getting a private key in the first 64.2% of the maximum number of Bitcoin private keys is greater than the probability of getting a key in the remaining 35.8% of the keys. That probability is (6/5), or 20% higher.

So in summary, by using Base 6, 99 digits we remove about 6% of the private keys from the random selection space. But each key in that space has an equal probability.
By using Base 6, 100 digits as you do, we maintain all possible private keys in the space for selection. But we have a 20% higher probability that the private key will be in the first 64.2% of all possible private keys.

Either way, we are dealing with such large number, that from a security point of view it doesn’t matter if 99 or 100 digits are used.

Please correct me if I am wrong. Thank you !

I tried generate P2SH address using SHA256 hash of text by insert "blue snow" then generated ↴
Then clossed aplication, reopening by inserting same text, generated the same result.
is this mean "blue snow" only become to be my Seed (un 12 or 24 mnemonic)?

https://i.postimg.cc/q76WnFvr/55.png

That's basically a brainwallet, "blue snow" is your passphrase in BrainWallet terms.

It simply computes the SHA256 hash of your text and use it as the 'private key' (HEX) thus,
the same text will always result with the same address and WIF Private key.

Type it here, it'll result in the same HEX Private key (Secret Exponent): https://brainwalletx.github.io/#generator (https://brainwalletx.github.io/#generator)

o i see, same result fdae1025c2330f52e7de28c0e1fa11d5684828ca3c2ba37bcf0b754356d161a5, thanks for your explain, master!

And in case it wasn't already obvious and well known... DO NOT USE BRAINWALLETS!

There have been countless examples of people losing bitcoins from bruteforced brainwallets. No matter how "random" you think your brainwallet phrase is... eg. lines from obscure poems, all the street names you've ever lived on in reverse chronological order etc... it isn't.

They're a "bad idea"™

Stick with properly randomly generated seeds and/or private keys.

I don't know your statement is right or not, but total valid private key according to https://en.bitcoin.it/wiki/Private_key (https://en.bitcoin.it/wiki/Private_key) is 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140 (115792089237316195423570985008687907852837564279074904382605163141518161494336) which makes your calculation is slightly wrong.


For reference, here's good example why using brainwallet is bad idea : Collection of 18.509 found and used Brainwallets (https://bitcointalk.org/index.php?topic=4768828.0)

Opps, sorry. Yes you are correct. Thank you for the correction. The maximum number of private keys is:

0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
= 115792089237316195423570985008687907852837564279074904382605163141518161494336

I was off by a factor of 1.0000000000000000000000000000000000008.

My overall question still stands though if someone would care to answer ?

You bring up an interesting point and here is my analysis.  You may be surprised.

99 dice method

Since the results are evenly distributed from 0 to 6⁹⁹-1, the probability of a collision in that range is 1/6⁹⁹. Note that there is no point to testing outside that range.

100 dice method

As you noted, the distribution is not uniform with numbers in one section of the range having a higher rate of occurrence than the other section. Lets analyze each section separately.

The probability of collision in the first section is 6/6¹⁰⁰, or 1/6⁹⁹, which is equivalent to the 99 dice method.

The probability of collision in the second section is 5/6¹⁰⁰, or ⁵/₆ * 1/6⁹⁹, which is less than the 99 dice method.

Results

The probability of a collision in the 100 dice method is equal to the 99 dice method in the worst case, but it is less overall.

Very well analyzed.
They seem right. The probability appears to have shifted somewhat in a small area.
This would affect a single cube sign.

However, this area is far too small to have any relevance in terms of safety technology.
In the end, whether you take 99 or 100 dice characters doesn't matter for security.

Nevertheless, I would like to thank you for the analysis, it is good to know.

Has anyone of you ever tried an exotic coin?
I cannot test all 1000 coins.
It would be very good if someone could report which coins have been tested!

Thank you for the response and effort.

But I need to disagree with your statement

100 dice method
“The probability of collision in the first section is 6/6100, or 1/699, which is equivalent to the 99 dice method.”
- That is not true. The 6th time you go “around the clock” you only get 64% of the way to the end of all possible keys. 64% of the number of bitcoin private keys is:
74106937111882365071085430405560261025816041138607938804867304410571623356375

But 6^99 is:
108886437250011817682781711193009636756190618412159145257178661061582856912896

The ratio of the 6th time keys available to the 6^99 is:
0.681

In other words, the 6th time you go around the clock, you only go 68.1% of the way into the 6^99 keys. As such, the probability of getting one of the 6^99 keys is not the same with the 100 dice rolls. The selection is biased to the lower 68.1% of private keys by a factor of 6/5 or 20% higher.

This is the bias influence I was trying (unsuccesfully) to describe.

Maybe a simple example to clarify. I have 7 apples in a row numbered 1 to 7. I then tell you that you can have one of the apples by picking a random number from 1 to 10. If you pick 2, you get the 2nd apple. If you pick 7, you get the 7th apple. But if you pick 8, I will use the mod operator and give the 1st apple. If you pick 9, I give you the 2nd apple. And if you pick 10 you get the 3rd apple. So your odds of getting apple 1, 2, or 3 are twice as high as getting apple 4, 5, 6, and 7. The mod operator introduces a bias towards the 1, 2, or 3rd apple.

So whether the 100 dice rolls method is better than 99 dice rolls is still unclear to me due to this mod operator bias influence with the 100 dice rolls to the lower 68.1% of private keys.

Thanks again.

I agree with you that there is a bias, but doing an extra roll never increases the odds of a collision. Remember, the comparison is between the odds of a collision in two methods, and not between the odds in the outcomes in any single method.

Lets use your your example because the numbers are smaller and it is easier to demonstrate the comparison. In this case, p is 7 and you are rolling either 1 or 2 5-sided dice.

1 die method

Outcome	1	2	3	4	5	6	7
Count	1	1	1	1	1	0	0
Probability	0.2	0.2	0.2	0.2	0.2	0.0	0.0

What are the odds of a collision? For the numbers 1-5, the odds are 20%. For the numbers 6-7, the odds are 0%.

2 dice method

Outcome	1	2	3	4	5	6	7
Count	2	2	2	1	1	1	1
Probability	0.2	0.2	0.2	0.1	0.1	0.1	0.1

What are the odds of a collision? For the numbers 1-3, the odds are 20%. For the numbers 4-7, the odds are 10%.

In the first method, an attacker choosing a number randomly will have a 14% chance of picking the right one, but a smart attacker will choose a number in the range 1-5 and have a 20% chance.
In the second method, an attacker choosing a number randomly will also have a 14% chance of picking the right one, but a smart attacker will choose a number in the range 1-3 and still have a 20% chance.

This demonstration can be proven mathematically, but it is a lot of typing and I think the example is clear.

Thank you very much for taking the time to write this up. I agree 100%.

I've seen similar programs and github repositories, but never before. I have no idea about the security status of wallets created in this way. Unfortunately, I do not have any technical knowledge to conduct an opinion on security. Therefore, I would be very pleased if anyone shares more detailed information on this subject.

Since you're doing mod(p) there's a chance of a collision, two base6 inputs making the same private key, one being a very small base6 input, the other that equal to the first input + the number range. Is it dangerous for two different inputs to be making the same private key?