Topic: Bitcoin brainwallet implementation in Rust (Read 559 times)

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


Actually i was referring to specific version of NodeJS to use, especially because NodeJS version increasing quickly. But blog you mentioned also makes sense.


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#?

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?...

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.



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.

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


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


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.


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

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.

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.

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 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.

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

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.

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


You should try installing software which use NodeJS/npm

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  
 
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?

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?  


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.

That is not a python specific problem.

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.

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.

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.

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.

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

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:
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.

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...

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 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?

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.

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.

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.

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

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.

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.

---

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.


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


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


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]