Pages:
Author

Topic: [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key - page 2. (Read 152871 times)

newbie
Activity: 35
Merit: 0
I've considered printing the private key portion in invisible ink, which requires a special reader, and doesn't allow the printing party to view the QR code, but even this involves an element of trust in the minting process, and would also require that the private key and QR code is not visible as the paper wallets are generated. Perhaps the only way for someone without Internet access to securely purchase bitcoin is at a BTM that prints a paper wallet as he deposits the cash. But one still has to trust the BTM and those who operate it - or have some type of escrow or reputation trademark.

By way of comparison, many industries - including banking - are overly trusted. It's a double standard. But I will continue my quest for trustless money.
legendary
Activity: 3262
Merit: 16303
Thick-Skinned Gang Leader and Golden Feather 2021
I am using this tool to create BitCheques (a physical bitcoin currency). I need to guarantee to holders that the private key is not recorded or memorized before the BitCheques are folded and sealed. What is the simplest, most user-friendly, and most straightforward way to do this without significantly altering the program?
Are you talking about proving the software isn't compromised, or do you mean you want to prove you didn't record the private keys? The former is probably possible (Bitaddress has been around for many years), the latter isn't. Having some else create private keys for you means you can't ever be 100% sure you're the only one who can access it.

Quote
Ballet uses bip38 and generates a passphrase - and generates the key over multiple locations. But I would like to omit the need for passwords altogether and keep everything self-contained.
If the buyer creates a BIP38 password, and you only store the encrypted private key, the buyer can be sure you can't access the funds (assuming the password is strong enough). That's the only way to be absolutely sure.

Quote
Is there a way to split or further encrypt the private key - or somehow tie it to the serial number? I'm not sure if this has been covered already in this thread.
Encrypting the private key works, see BIP38. I can't think of another way to do this without trusting you. Using a serial number won't help, as long as both you and the buyer know it, you can both recreate the private key.
newbie
Activity: 35
Merit: 0
I am using this tool to create BitCheques (a physical bitcoin currency). I need to guarantee to holders that the private key is not recorded or memorized before the BitCheques are folded and sealed. What is the simplest, most user-friendly, and most straightforward way to do this without significantly altering the program? Ballet uses bip38 and generates a passphrase - and generates the key over multiple locations. But I would like to omit the need for passwords altogether and keep everything self-contained. Is there a way to split or further encrypt the private key - or somehow tie it to the serial number? I'm not sure if this has been covered already in this thread. I read through much of it, but it is rather lengthy. I'm open to all options.
jr. member
Activity: 41
Merit: 18
i have btc in wallet created in 2018 by bitaddress.org site and i havent touched them till now.
back then i didnt knew what gpg signature is so i didnt verified.

But i worry too much are my funds safe.  
Should i send them in new address generated via better methods(like linux electrum{python better randomness} offline gpg verified).

It is as safe as your password. If it is multiple words, that are nowhere written in the internet or your computer, or at least 8 random characters with uppercase, lowercase and numbers, then it is safe:

https://en.wikipedia.org/wiki/Password_strength#Guidelines_for_strong_passwords

The problem with moving it is that if you have a malware installed, then it can get stolen when you try to move it.

And nowadays 30% of all computers in the US are malware infected:

https://dataprot.net/statistics/malware-statistics/

And there are new and more sophisticated malware every day. So a hardware wallet is the only safe solution for the average user. Or a computer which is not connected to the internet, and then create and sign the transactions offline. But the average user can't do this.

I think Trezor is a good hardware wallet. It is like a strong brainwallet, but you can still use your coins regularly without the fear that malware steals it. And if you write down the passphrase for it (only on paper, never on any computer or password manager app), the hardware can even get lost or destroyed, and you can just enter it in a new Trezor device to get it back.

It has also a nice feature to create an addtional hidden wallet. In case of a $5 wrench event, you can just tell them the first decoy wallet with less value, and your main value is in the hidden wallet.
newbie
Activity: 25
Merit: 5
i have btc in wallet created in 2018 by bitaddress.org site and i havent touched them till now.
back then i didnt knew what gpg signature is so i didnt verified.

But i worry too much are my funds safe.  
Should i send them in new address generated via better methods(like linux electrum{python better randomness} offline gpg verified).
newbie
Activity: 5
Merit: 0
I did a diff of the original repository and the new repository.
Thanks for looking into it!

Would have been better to just fork the original repository and send it as a PR
Agreed, don't know why I didn't... maybe I will.

Should be safe, unless boomdev found a new png image decoder backdoor Smiley
I wish I was that smart  Grin
jr. member
Activity: 41
Merit: 18
Well thank you very much for implementing new paper wallet designs! I still won't use your repo/website/app as for now since I am not that good of a programmer myself to confirm that it is completely safe. If there are more reputable members that can confirm the safeness in the future then I will try it out!
I did a diff of the original repository and the new repository. Would have been better to just fork the original repository and send it as a PR, but boomdev is right, the only differences I can see (at this moment, version e7ab666c7e754a134e92494c2849eee1909e3ded ) are the new templates, an unnecessary yarn.lock file, no .gitignore file, removed bitaddress copyright in the website (but the original repository is still mentioned), and changed logo. All the security related functions in the JavaScript files are untouched. Should be safe, unless boomdev found a new png image decoder backdoor Smiley
legendary
Activity: 1078
Merit: 1123
Here's a new repo with 5 new paper wallet templates (feel free to add more).
This time, I didn't try to fix something that wasn't broken, it's a copy of the original bitaddress.org repo, with only 2 files modified. No Electron or anything.
Repo: https://github.com/boomdev/billify2
Screenshot:https://i.ibb.co/qrjkpmb/Billify2-Example.png
Well thank you very much for implementing new paper wallet designs! I still won't use your repo/website/app as for now since I am not that good of a programmer myself to confirm that it is completely safe. If there are more reputable members that can confirm the safeness in the future then I will try it out!
newbie
Activity: 5
Merit: 0
Here's a new repo with 5 new paper wallet templates (feel free to add more).
This time, I didn't try to fix something that wasn't broken, it's a copy of the original bitaddress.org repo, with only 2 files modified. No Electron or anything.
Repo: https://github.com/boomdev/billify2
Screenshot:https://i.ibb.co/qrjkpmb/Billify2-Example.png
newbie
Activity: 5
Merit: 0
I've gifted a few paper wallets so far and would love to have a few new designs.

Hodl my BTC, I'll BRB.
legendary
Activity: 1078
Merit: 1123
Thanks for your message, sam00! My repo actually offers less features than bitaddress.org, as it just does the paper wallet, not the other types.

~

I thought it would be a cool idea to have an app/website only for creating paper wallets IF it had more functionalities for specifically for this purpose.
I thought he had maybe added more designs to it, since that's what I've been looking for so many times already Cheesy
I've gifted a few paper wallets so far and would love to have a few new designs.
newbie
Activity: 5
Merit: 0
This sounds interesting. Can you tell us what features your site offers that bitaddress.org doesnt offer ?
Can you provide screenshots, proof of your work or even create an announcement thread maybe ?
As of right now, I wouldn't download and run a file from a Newbie. 

Thanks for your message, sam00! My repo actually offers less features than bitaddress.org, as it just does the paper wallet, not the other types.
I really just thought it would be cool to be able to have a "native" app you could potentially install with apt instead of the site and quite frankly it was my first time trying Electron.
Also as you said I'm a super noob so there is probably no reason to use my app over the OG.

I wouldn't say it sounds interesting, sounds fishy to me. Looks like the source code is mostly the same from the original webpage. For example compare this script from the new program:
https://github.com/boomdev/billify/blob/d472db85683b30f1b63dc84122234e43e0a055bd/js/ninja.paperwallet.js
with this from the original page:
https://github.com/pointbiz/bitaddress.org/blob/72aefc03e0d150c52780294927d95262b711f602/src/ninja.paperwallet.js
Nothing wrong with it, the licence allows to use the code, and the new repository cites everything correctly in the licence file, as required.

But the point of an address generator is to be sure that it is safe. The application in the deb file is an Electron app. It includes a large amount of binary executable for the Chromium extension. It would be (relatively) easy to modify Chromium, to modify one of the JavaScript programs to generate addresses which are unsafe and predictable.

With the original website, you can examine each JavaScript file that it is safe, and then just open it in an unmodified webbrowser of your choice on an internet disconnected computer to generate your wallet. This would be the safest way. There is no need for an Electron app. Even more so because it generates a paper wallet, so you can't verify it. For example if it would provide the a brain wallet functionality as well, then you could test a brain wallet address with the old site, and then compare it with the new site to check if it works, before using it for your secret brain wallet.

That said, the deb file might be innocent. But it is simply not needed and I wouldn't install or run it.

You are correct, programmer-frank, the original site is safer/better. There is nothing fishy here though - or at the very least none intended. This "project" was a learning opportunity (which I think is encouraged by the author of bitaddress.org) and I was out of my depth in the cryptographic side of the codebase but it was a lot of fun. I debated using Electron, tried a few alternatives that don't bundle Chromium & Nodejs (namely tauri & neutralino) but for some reason I stuck with Electron.
I also see why using the deb (or rpm) directly would be illadvised. The best way to use the app would prabably be to build it from the source code - which, yeah, kinda defies the purpose of it all  Roll Eyes

To be fair, I'm not sure most people actually audited the code of bitaddress.org before using it (now I have, at least in part), but it's all about having the option - I guess.
All in all, a pretty pointless result for a not-so-pointless exercise, might you agree.

Anyways, thanks to you both for taking the time.  Grin
https://i.ibb.co/fdmNsZ5/Billify-Screenshot.png
jr. member
Activity: 41
Merit: 18
This sounds interesting.

I wouldn't say it sounds interesting, sounds fishy to me. Looks like the source code is mostly the same from the original webpage. For example compare this script from the new program:
https://github.com/boomdev/billify/blob/d472db85683b30f1b63dc84122234e43e0a055bd/js/ninja.paperwallet.js
with this from the original page:
https://github.com/pointbiz/bitaddress.org/blob/72aefc03e0d150c52780294927d95262b711f602/src/ninja.paperwallet.js
Nothing wrong with it, the licence allows to use the code, and the new repository cites everything correctly in the licence file, as required.

But the point of an address generator is to be sure that it is safe. The application in the deb file is an Electron app. It includes a large amount of binary executable for the Chromium extension. It would be (relatively) easy to modify Chromium, to modify one of the JavaScript programs to generate addresses which are unsafe and predictable.

With the original website, you can examine each JavaScript file that it is safe, and then just open it in an unmodified webbrowser of your choice on an internet disconnected computer to generate your wallet. This would be the safest way. There is no need for an Electron app. Even more so because it generates a paper wallet, so you can't verify it. For example if it would provide the a brain wallet functionality as well, then you could test a brain wallet address with the old site, and then compare it with the new site to check if it works, before using it for your secret brain wallet.

That said, the deb file might be innocent. But it is simply not needed and I wouldn't install or run it.
legendary
Activity: 1078
Merit: 1123
Hello! I made an installable (deb & rpm) version of the paper wallet generator on bitaddress.org.
I also wanted to say hi and thank you to @pointbiz and the other contributors to the bitaddress repo.

Here it is: https://github.com/boomdev/billify
Cheers!

This sounds interesting. Can you tell us what features your site offers that bitaddress.org doesnt offer ?
Can you provide screenshots, proof of your work or even create an announcement thread maybe ?
As of right now, I wouldn't download and run a file from a Newbie. 
newbie
Activity: 5
Merit: 0
Hello! I made an installable (deb & rpm) version of the paper wallet generator on bitaddress.org.
I also wanted to say hi and thank you to @pointbiz and the other contributors to the bitaddress repo.

Here it is: https://github.com/boomdev/billify
Cheers!
jr. member
Activity: 41
Merit: 18
A few months ago, the owner/creator of bitaddress.org commented in this thread and stated that he does not want to withdraw the coins from his deposit address to keep is privacy. It is still pretty amazing that he just has 36 bitcoin sitting around Cheesy

Interesting, you are right. But was not this thread, but here: https://bitcointalksearch.org/topic/m.56454923
I probably wouldn't worry about my privacy and just hire a big lawyer firm to convert it to fiat to keep my privacy. But I like the owners idea to donate it to new projects.
legendary
Activity: 1078
Merit: 1123
BTW, the donations address currently contains 36.4 BTC, worth $1.7 million. Nobody should say open source is not profitable Grin

A few months ago, the owner/creator of bitaddress.org commented in this thread and stated that he does not want to withdraw the coins from his deposit address to keep is privacy. It is still pretty amazing that he just has 36 bitcoin sitting around Cheesy
jr. member
Activity: 41
Merit: 18
Nice that this website is still live. I mentioned it in an article about Bitcoin I wrote for the 2600 magazine (The Hacker Quarterly), which was published in the autumn 2013 issue, with the brain wallet "Frank test for 2600" for whoever of the readers got it first. Of course was claimed shortly after the magazine was printed (no ebooks of 2600 back in 2013).

BTW, the donations address currently contains 36.4 BTC, worth $1.7 million. Nobody should say open source is not profitable Grin
newbie
Activity: 1
Merit: 0
Does Anyone Know?

Is there a specific reason why bitaddress.org
generates randomness over 512 hex characters?
newbie
Activity: 1
Merit: 0
Why does bitaddress.org (and indeed older versions) also accept mini private keys whose test byte is "01"?
Is the information on https://en.bitcoin.it/wiki/Mini_private_key_format wrong, where it says that the test byte must be "00"?

I first thought this was a bug, but it looks like it was intentionally programmed that way:

line 5939:  
Code:
return ((testBytes[0] === 0x00 || testBytes[0] === 0x01) && (validChars22 || validChars26 || validChars30));
Pages:
Jump to: