Bitcoin brainwallet implementation in Rust

[larry_vw_1955]

That's not a flaw. Such a collision in cryptography exists in all algorithms and it is only considered a flaw if one could spend reasonable amount of computing power and find such collision in reasonable time. Otherwise when it would take something like millions of years we consider it safe.

ok then I'll rename it as an "imperfection" if that satisfies you. an imperfection is anything less than perfection. having collissions means it is not perfect.

now having gotten that out of the way, i don't think just saying something will take millions of years is fully satisfying in the sense that did the people that developed this standard even stop to consider what the actual probabilities for such a thing were and where is their analysis. i doubt it exists. i'd love to see it though.

The problem with "inventing" an algorithm with the purpose of generating a private key is that it is difficult to measure how much entropy (security) your private key really has.

Well, i think the chances of someone writing down a random private key that matched my private key would be higher than them being able to design an algorithm that generated my private key given some input. Much higher.

If you can think of an algorithm, there is no reason why someone else couldn't think of a similar algorithm.

Not necessarily. There's no reason to think that is the case in general.

Although my recommendation is to create a seed that has 256 bits of entropy, if you insist on creating a brain wallet with low amounts of entropy, I would suggest using an algorithm that is computationally inefficient.

That certainly is one possible feature such an algorithm could have.

Obviously, this assumes that new technology will not be invented that can go from 'brain wallet' phrase to private key more efficiently in the future.

yeah that's not an issue when the algorithm being used to "go from 'brain wallet' phrase to private key" is not known.
they will have to find some other way to crack the bitcoin address. and that's something that all bitcoin addresses would be susceptible to no matter how they were created.

[moderator's note: consecutive posts merged]

[vjudeu]

having collissions means it is not perfect

All hash functions have collisions. If there would be no collisions, then it would be called "compression".

i don't think just saying something will take millions of years is fully satisfying

In that case you will never reach "fully satisfying" things. Even Bitcoin mining works because finding low hashes is difficult and the fastest known way is checking every single combination. Bitcoin works because overwriting the chain would take a lot of computing power. Also it works because finding any collision will take millions of years if you use existing algorithms to do that.

[PrimeNumber7]

The problem with "inventing" an algorithm with the purpose of generating a private key is that it is difficult to measure how much entropy (security) your private key really has.

Well, i think the chances of someone writing down a random private key that matched my private key would be higher than them being able to design an algorithm that generated my private key given some input. Much higher.

It is not. In base 10, the number 2^256 is 77 digits long. It is well documented that the average person can memorize 7 pieces of information at once. You are not going to be able to reasonably memorize a function that is one out of 2^256 possibilities.

If you can think of an algorithm, there is no reason why someone else couldn't think of a similar algorithm.

Not necessarily. There's no reason to think that is the case in general.

People tend to have a bias towards their own experiences. If a function is something you thought of on your own, it is probably not random. If the function is partially the output of a random generator (for example if at one point you multiply your starting number by 5, and "5" is the output of a random generator), your function will be more difficult to memorize.

Although my recommendation is to create a seed that has 256 bits of entropy, if you insist on creating a brain wallet with low amounts of entropy, I would suggest using an algorithm that is computationally inefficient.

That certainly is one possible feature such an algorithm could have.

Obviously, this assumes that new technology will not be invented that can go from 'brain wallet' phrase to private key more efficiently in the future.

yeah that's not an issue when the algorithm being used to "go from 'brain wallet' phrase to private key" is not known.
they will have to find some other way to crack the bitcoin address. and that's something that all bitcoin addresses would be susceptible to no matter how they were created.

[moderator's note: consecutive posts merged]

I was referring to the algorithm that you may invent that would be computationally expensive.

IMO, the only excuse for having a low entropy input to generate a private key is that it is expensive to go from input to private key.

[larry_vw_1955]

I was referring to the algorithm that you may invent that would be computationally expensive.

IMO, the only excuse for having a low entropy input to generate a private key is that it is expensive to go from input to private key.

I do agree that computational expense is an extra thing to throw in but it's not everything. I don't even find it necessary, as what is expensive today might not be expensive tomorrow so we can't just pin all our hopes on that one thing. With that said, I would be more than confident that no one could ever come up with the algorithm I have in mind. Their chances of brute forcing the bitcoin address would be just as good if not higher. And easier. As I have already pointed out. You have a bitcoin address. You might have a probable brainwallet passphrase. You don't know anything about the brainwallet algorithm. You are stuck.
 

Maybe sometime I'll actually deposit some funds onto a brainwallet address. Just to prove my point. And let you know the passphrase. Not that anyone would actually want to waste their time trying to get the money because it would be just like brute forcing a bitcoin private key no simpler than that.

My end of the bargain will be that I have to have the entire brainwallet algorithm memorized in my head and there can be no program that I use to ever redeem the money. When I wish to redeem the money since no one is ever going to crack it, I have to do a cleanroom implementation of the algorithm from scratch all over again. All from my head. How's that sound?

[pooya87]

I do agree that computational expense is an extra thing to throw in but it's not everything. I don't even find it necessary, as what is expensive today might not be expensive tomorrow so we can't just pin all our hopes on that one thing.

You are denying how cryptography has always worked, from its inception thousands of years ago until today. Every cryptography algorithm that has ever been invented has had some sort of expiration date before which it couldn't be broken (the cost were too high) and after that date it was broken.
For example substitution ciphers were a popular encryption algorithm in first century, today they are a joke. The first book on "breaking" cryptography is from the year 800 by an Arabic linguist of Persian descent.

[larry_vw_1955]

You are denying how cryptography has always worked, from its inception thousands of years ago until today. Every cryptography algorithm that has ever been invented has had some sort of expiration date before which it couldn't be broken (the cost were too high) and after that date it was broken.
For example substitution ciphers were a popular encryption algorithm in first century, today they are a joke. The first book on "breaking" cryptography is from the year 800 by an Arabic linguist of Persian descent.

tell me something i don't already know. i'm not talking about published algorithms. mine would never see the light of day and you would never imagine what it is.   as i already said, even if i told you the brainwallet passphrase and the related bitcoin address, it would do you no good at all. you don't seem to get that but it's ok...

[PrimeNumber7]

I do agree that computational expense is an extra thing to throw in but it's not everything. I don't even find it necessary, as what is expensive today might not be expensive tomorrow so we can't just pin all our hopes on that one thing.

You are denying how cryptography has always worked, from its inception thousands of years ago until today. Every cryptography algorithm that has ever been invented has had some sort of expiration date before which it couldn't be broken (the cost were too high) and after that date it was broken.
For example substitution ciphers were a popular encryption algorithm in first century, today they are a joke. The first book on "breaking" cryptography is from the year 800 by an Arabic linguist of Persian descent.

I think you are referring to something different than what larry_vw_1955 and I were discussing.

It is very easy to get from a string (or a file) to the SHA256 hash of said string (or file). Very little computational effort is required. I was referring to an algorithm that takes a relatively long time to get from the string to the ALGORITHM hash of that string.

It is currently not possible to calculate a string based on the SHA256 hash -- the only way to know that the SHA256 hash
C67F9F258F01BEC38DB1E0ACC35CBD33675774153B1460BDB414A2252E50E9EE
is the hash of the following string:

Code:

pooya87 November 10 2021 9:05 PM

is by going from the above string to SHA256 hash, you cannot go the other direction. I believe this is what you were referring to.

In the future, it is possible that someone will "break" SHA256 hashing algorithm, and whatever algorithm larry_vw_1955 is thinking of. Then again, secp256k1 curve cryptography could also be broken in the future.

[larry_vw_1955]

In the future, it is possible that someone will "break" SHA256 hashing algorithm, and whatever algorithm larry_vw_1955 is thinking of. Then again, secp256k1 curve cryptography could also be broken in the future.

Short of "breaking bitcoin itself" as you describe above, that's really the only feasible way someone would have a chance since the chances of them coming up with my secret algorithm they wouldn't even know where to start and a computer wouldn't either. It's not that I'm some super genius that has some talent for designing secret algorithms either. But it is fun 

I came up with one quick one the other day passphrase is satoshi. Address is here: https://live.blockcypher.com/btc/address/1BGuYNzNsxDxAEn9roDrVa1Z9aqr3ENZU2/

Thing is I kind of almost forgot the steps but i did record them but I'm trying to see if I can remember them without having to remind myself. i wasn't doing it seriously though. it was just a quick test to see what a possible secret algorithm could look like

[programmer-frank]

I simplified the code, see the github repository. No extra functions and no macro needed anymore for the Sha256 and Ripemd160 hash, 20 lines shorter and easier to read now.

I think Rust is a good choice for writing blockchain related code. Typesafe and fast like C++, but the Rust compiler is much better. Together with the borrowing memory concept it is really hard to write code which crashes, or has memory leaks or undefined behavior at runtime, which is no problem at all with C++. And there are over 70,000 Rust crates (what other languages call modules or libraries) available for nearly everything you can imagine, usable with one line in the cargo.toml file with the nice "cargo" build system.

[larry_vw_1955]

I think Rust is a good choice for writing blockchain related code. Typesafe and fast like C++, but the Rust compiler is much better.

What do you think about how it compares with Python for blockchain related things? I find python to be a real confusing thing when it comes to bitcoin simply because you have old packages and then newer packages that presumably do the same things in some cases. Then you have vitalik's circa 2013 that has over 800 forks how do you know which fork to use or trust? Its a real crapshow. The even worse thing is that his package and its derivatives are not really fully featured. They only do a limited set of things and I'm not even sure they do it really well. the code seems kind of hacked together and not very well commented at all but anyhow...

It would be nice to have some type of quality control process to the package management system where the only packages that could make it into the repository were verified and vetted for not only functionality but full functionality and correctness and professionally written not cobbled together. And don't include 2 packages whose functions overlap.

[programmer-frank]

Python is nice, and the programs are shorter and easier to read than the same in Rust. But right, package management is not as nice as with the Rust cargo build system.

Package quality is always a problem. For Rust I use the crates.io site and sort for number of downloads. Usually the more popular a library is, the better the quality and maintained it is. For example for the secp256k1 algorithm this is the search result:
https://crates.io/search?q=secp256k1&sort=downloads
The first library is just a wrapper around a C library, which I want to avoid, to avoid build problems on Windows. Second crate is really big, with lots of different signatures, but i wanted just secp256k1. So 3rd result looked good and I checked the documentation, github, test cases etc., and then I used it for my project (btw, all the 0.x.y packages don't mean beta quality in Rust, it is just a convention that the interface might change until the first 1.0.0 version).

But for larger applications, the lack of static typing in Python can be problem (which is the reason why they introduced type annotations in Python 3.9), and it is much slower and needs more memory, so you don't really want to process gigabytes of blockchain data with it, or use it for a high traffic network node. But I think for such tools like the brainwallet, Python is better than Rust, and I use it often for such tasks. A Python REPL (Python in interactive mode) is also one of the best hand calculator replacements and very useful with Jupyter for interactive data manipulation and visualization.

[pooya87]

I find python to be a real confusing thing when it comes to bitcoin simply because you have old packages and then newer packages that presumably do the same things in some cases.

That is not a python specific problem.

It would be nice to have some type of quality control process to the package management system where the only packages that could make it into the repository were verified and vetted for not only functionality but full functionality and correctness and professionally written not cobbled together. And don't include 2 packages whose functions overlap.

This can't happen because it would limit development and discourage any new developers from creating any new packages. It's true that there are sometimes more than one package doing the same thing but most of the times they are different in some ways, for example one could perform better, have some additional functionality, or better API, etc.
In the end, the choice is up to the developer using those packages. They have to do some research into the respective repository and see how mature the project is before using the package.

[larry_vw_1955]

That is not a python specific problem.

yes it is. python is a very good example of how that whole thing can really get out of hand. i doubt other software programming languages have this issue to that degree whatsoever other than Rust of course since the OP mentioned it kind of has that issue  
 

This can't happen because it would limit development and discourage any new developers from creating any new packages.

clearly there is a need for centralization to some degree. i mean if bitcoin core just let anyone put their code into it without serious peer review and evaluation of whether it was really necessary do you think there would be a bitcoin?

It's true that there are sometimes more than one package doing the same thing but most of the times they are different in some ways, for example one could perform better, have some additional functionality, or better API, etc.

no it's not that at all. vitalik's bitcoin package was forked over 800 times. do we know what the difference is between them all? and do we even know which one we're running when we install bitcoin on python?  

In the end, the choice is up to the developer using those packages. They have to do some research into the respective repository and see how mature the project is before using the package.

well, and that's the part of the problem. using one metric to get a handle on another metric. maturity doesn't equal no bugs necessarily. they need some better way to guarantee people the packages run correctly such as certification process that they give to particular packages. one for each type. one for bitcoin for example. then if someone wanted to change that package, it would have to go through a peer review process like linux kernel.

[ABCbits]

I think Rust is a good choice for writing blockchain related code. Typesafe and fast like C++, but the Rust compiler is much better. Together with the borrowing memory concept it is really hard to write code which crashes, or has memory leaks or undefined behavior at runtime, which is no problem at all with C++.

Your post remind me of this discussion, [meta] Rust in Bitcoin reference implementation.

That is not a python specific problem.

yes it is. python is a very good example of how that whole thing can really get out of hand. i doubt other software programming languages have this issue to that degree whatsoever other than Rust of course since the OP mentioned it kind of has that issue 

You should try installing software which use NodeJS/npm

[larry_vw_1955]

You should try installing software which use NodeJS/npm

no thanks.

i remember doing that once with a particular company's tool that let you get your private keys to your wallet. Just to install a piece of software that did that simple task took a huge amount of time and storage space because it created a huge number of directories I think thousands. I don't understand that at all but it can't be a good thing. I don't know why a company would ever want to use that method of software packaging because I certainly won't be using their products now or in the future.

[programmer-frank]

Maybe NodeJS programs have so many files, because JavaScript programmers like to use a lot of packages, even for one-liners:
https://dev.to/jyotishman/10-useless-npm-package-with-millions-of-downloads-de9
To be fair, the upper-case package can do a lot more, like converting to and from camelCase etc. But is-odd and is-even really doesn't make sense. I mean just import is-odd, and do a negation on the result to get is-even for free, as the source code of the is-even package demonstrates

[pooya87]

yes it is. python is a very good example of how that whole thing can really get out of hand. i doubt other software programming languages have this issue to that degree whatsoever other than Rust of course since the OP mentioned it kind of has that issue 

C#: https://www.nuget.org/packages?q=bitcoin
2nd result is an RPC wrapper, it is not even a bitcoin library despite the name. It is also abandoned and hasn't been updated for 3 years.
3rd result is an ancient low quality library last updated 7 years ago.
...
There are a lot of other results that aren't even bitcoin libraries, they are for altcoins but since the dev added the bitcoin tag (for some unknown reason!) the search brings it up.

There are 515 packages out of which only about 10 is worth looking into.

clearly there is a need for centralization to some degree. i mean if bitcoin core just let anyone put their code into it without serious peer review and evaluation of whether it was really necessary do you think there would be a bitcoin?

There is a huge difference between inserting code into someone else's existing project and letting people create new projects and publish them! My previous comment was about the later.

no it's not that at all. vitalik's bitcoin package was forked over 800 times. do we know what the difference is between them all? and do we even know which one we're running when we install bitcoin on python? 

The package is not forked, the code on github is. And those forks don't release a package unless they have actually changed something or updated this abandoned project.

well, and that's the part of the problem. using one metric to get a handle on another metric. maturity doesn't equal no bugs necessarily. they need some better way to guarantee people the packages run correctly such as certification process that they give to particular packages. one for each type. one for bitcoin for example. then if someone wanted to change that package, it would have to go through a peer review process like linux kernel.

If you are looking for no-bugs, you are out of luck because you will never find any code that has no bugs ever. The bigger they are the more bugs they have and no amount of license can solve it.

[larry_vw_1955]

C#: https://www.nuget.org/packages?q=bitcoin

There are 515 packages out of which only about 10 is worth looking into.

ok maybe you proved your point although with python 1019 packages come up. so that's almost twice as bad.

There is a huge difference between inserting code into someone else's existing project and letting people create new projects and publish them! My previous comment was about the later.

but still i think the argument could be made that "bitcoin" belongs in the standard library of python in the core

The package is not forked, the code on github is. And those forks don't release a package unless they have actually changed something or updated this abandoned project.

if you go to https://github.com/vbuterin/pybitcointools you can see that master branch contains nothing. so i'm not sure where python is getting this "bitcoin 1.1.42" package from and how they are coming up with that particular version number. and even if you say they are getting it from such and such a place, you don't really have a way of verifying it short of comparing the files line by line visually. to see if they really are the same or not. that seems kind of inefficient but whatever.

If you are looking for no-bugs, you are out of luck because you will never find any code that has no bugs ever. The bigger they are the more bugs they have and no amount of license can solve it.

we can't be having software that generates the wrong bitcoin address. that could cost someone their lifetime savings.

[larry_vw_1955]

Then you already know it's not Python specific problem.

I don't use (try not to rely on) software that has that problem. In general. If it needs to be that complicated then to me that means whoever programmed it doesn't know what they are doing. How could they if they are letting something else do all the work for them and they are just slapping something together?...

Maybe NodeJS programs have so many files, because JavaScript programmers like to use a lot of packages, even for one-liners:
https://dev.to/jyotishman/10-useless-npm-package-with-millions-of-downloads-de9

Yeah, I've played around with javascript bitcoin tools here and there but I'm not a big fan of them. To me, running programs in a web browser for doing things like creating bitcoin addresses I don't trust web browsers. They connect to the internet. Which is a bad thing when it comes to keeping things secret.

Your comparison doesn't make sense, the number (515 vs 1019) means Python is more popular programming language among Bitcoiner who have programming skill. For example, there are 154 bitcoin library for Ruby (https://rubygems.org/search?query=bitcoin). Does that mean Ruby is 6.6x times better than Python and 3.3x times better than C#?

it might mean that. it all depends on the quality of the ruby and C# packages. if there are some good ones then it could mean that.