Pages:
Author

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

sr. member
Activity: 437
Merit: 415
1ninja
https://www.bitaddress.org/bitaddress.org-v3.2.2-SHA256-f4d047c264a2b71946de319482a9365e56d8d7289dd85a352da3b1448b7647df.html
v3.2.2
 - version bump for unix line endings

The grunt build process already forces UNIX line endings. In this case I built in a branch and pushed to git. Then auto-merged the pull request and pulled to local master. After the pull to local master bitaddress.org.html had DOS line endings.

I updated the process I use to sign to re-build before sign to enforce the UNIX line endings so even in a scenario like above I will avoid this in the future.
sr. member
Activity: 437
Merit: 415
1ninja
gpg: Signature made Sun Aug 21 12:40:40 2016 PDT using RSA key ID 63974F5A
gpg: BAD signature from "pointbiz <[email protected]>" [unknown]

I think the issue is DOS line endings. I'm going to re-release.
sr. member
Activity: 437
Merit: 415
1ninja
I'd already updated all the keys & also specifically imported your public key before doing the --verify

gpg: key 63974F5A: "pointbiz <[email protected]>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

OK. Which file returned bad "CHANGELOG.txt.asc" or "bitaddress.org-v3.2.1-SHA256-ca6a34d4ac6742dc8cebfbe0089e28392b6ee9b33b05eaa68c9e00b00e355f48.html.sig"?
legendary
Activity: 3052
Merit: 1031
RIP Mommy
I'd already updated all the keys & also specifically imported your public key before doing the --verify

gpg: key 63974F5A: "pointbiz <[email protected]>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
sr. member
Activity: 437
Merit: 415
1ninja
gpg: Signature made Sun Aug 21 12:40:40 2016 PDT using RSA key ID 63974F5A
gpg: BAD signature from "pointbiz <[email protected]>" [unknown]

Strange. Do you have the key I updated in 2015. I added uid for [email protected]

Quote
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.13 (MingW32)

mQENBE5lizQBCADhDeJALMhaXOW6U5Lj1wyNyYwf5bh4kcP4m5pDrQCk3GzduMBh
NKsa21zgejhST74l7PRVNWJc7cLsdpQ7fCGUgbEBaApQ7+J1pSAClEdBCZ6wycgI
gAln86LmsmtsGnr77jPJEeeYI2FH6o5JEEYdc6Kji8Mkj1fNMqa8qrOFydazbvTm
EcuwtWsf+EFM1DwnaS2D0CU8Y4rB7wzaQkS/m+9yXqmhLgFI1B5mYyEhWz/YGcKs
ln93a/rLemHty54UWtpi1bn5F7alB/HnvNt65wHvXKnvi+/Teqft2jk4i0Uqd7QR
uFUBc/wTC9tJXwf83qOMOv8zqU8uJCryp4cjABEBAAG0HG5pbmphIDxuaW5qYUBi
aXRhZGRyZXNzLm9yZz6JAT4EEwECACgCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4B
AheABQJV9gLjBQkQ9njvAAoJEIdJe5Fjl09a6eMH/j0TIX/fQzvWhVOFNdS3rKeG
7xJ90QvlgzSwXig/lCtf2/wO216bgDwY0yZCIcvsjusneXbjSIqJ1eXIZE06B3yP
6Xmlc6GU8vu5XJvqf27axAGoghy0Y7Wag2FlgPbKJPSapqIj3O4JV/fwKH/Wmua/
J36XVW3+0G3Hx4vB15v1w4WX56ttDXo5vCMcCPn8zh5+MA2+HK1ts/SMvhG9pWuk
TCTPka3hawIQOOawoAty/zQIDma3XHjAUM4oErTLlgux7LwNl+H772GIfvy4ltj3
/LhZBDIe6NB0JArb4NqvICIZ5pDUr4Zp6QccZO6jL3KXomo6c9DPkeXMz1gpx1u0
InBvaW50Yml6IDxwb2ludGJpekBiaXRhZGRyZXNzLm9yZz6JAT4EEwECACgFAlX2
Bc0CGwMFCRD2eO8GCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIdJe5Fjl09a
2CMH/iUwNXr9NP9brt93+E2YpH1zGqgnOoYVGz72WTUD+v0WP5/LN2qVMec8nqXb
dzwQI6ERQlEkgahynzaxZw44U5AKfpvxI8AFD4mOuB4aAMJxt5k5a9O1AgegJAX6
Ev04mIXGhNisq3oLIVkbhCR8IS43B6mWUYyBcICWec/gkxh/EJh3BuavlmDZBkp8
/5K/oBg6Un80jCWP1h87Fxv8dWClcF8wROaSnoFDKPsbpPNEudgxUkAycbcByy0o
v62d1X5GNFrr432EMZpTO5Up6vCA/B8K7cCS7qYsLbvo5WglYpscoDWozUld5ga1
qeZdjDI8u5qDnGKgI3ZkT5sV/WC5AQ0ETmWLNAEIAN1eqRI6ltxWZhR3EaWIca1/
p3PrV/BqY0CpWufjr/ZWjufN+QSVgICrVF/CjYxxZeo0tZ48m3qzIfr3MYIMW2+Y
Rno1p/uMbf43oqOiQy7o30u8rhLgWc3nmKFyE8I1iRToqcGM2+YxQ80zp8TvjFQW
zvMClFHS+JAa+n7Z5RwerTQPf3j4spo4oZGrxxu8UWT4qxR8BRzs6q4BSkuehzxT
TgYhxSOrKqZLKVQ/kVfUZaCy29WqV9LxnQXLFrqZeHccocp+Hd01xyCybGgynJfg
O2Oz52RXRHDEPv0hjR+b419O7QOiqGI7TQ7fcaIBUByIn84fodOnddak9XYwd1MA
EQEAAYkBHwQYAQIACQIbDAUCVfYGGwAKCRCHSXuRY5dPWsk6B/0XNmalHNn175fJ
DeFTTmZ0BAEj3izjYb4NWExutcF4AcJjqEU+oSaY7QrZoV6YBpeJ8YXVigK9EOf8
4eaQONk/ZT5yjYYn6IrFmL0SL+O2HKOxFNogv2yyLYJJXFvUcSSBZGQrNK2pbhbc
Y/r6XXpgKl/JqazvVGGl3j38t7KzTMDkmhtkL+EzX9GiaXx0tF7ZPI2JfcizotuF
ONiWDc5ferDBJaFPMYb9ElcxC5knnfkM0ti5SH3vUw1qCT6+vKB4PG7W4V1MpoMx
ZHAcHt6uj5cE2IfHO4aPRU1BnqB6lRK2ob0c8/o7d0dWwvciQhH+NrRQThqlGf8E
sjLBqm5u
=9YLe
-----END PGP PUBLIC KEY BLOCK-----
legendary
Activity: 3052
Merit: 1031
RIP Mommy
gpg: Signature made Sun Aug 21 12:40:40 2016 PDT using RSA key ID 63974F5A
gpg: BAD signature from "pointbiz <[email protected]>" [unknown]
sr. member
Activity: 437
Merit: 415
1ninja
v3.2.1
https://www.bitaddress.org/bitaddress.org-v3.2.1-SHA256-ca6a34d4ac6742dc8cebfbe0089e28392b6ee9b33b05eaa68c9e00b00e355f48.html
 - BigInteger modInverse should be positive
 - throw if modInverse 0
 - improve BigInteger constructor so that it works if caller forgets 'new'
 - add unit tests for BigInteger
 - thanks to dooglus, jprichardson, dcousens
sr. member
Activity: 424
Merit: 343
I currently setup my paper wallets and want to use split wallets.

Is there a way to proof the Shares and check if the right private key works or not
without run it live with BTC?

Thank you.
Sure you can! Enter separate shares into "Available Shares (whitespace separated)" and click "Combine Shares" button to get the private key (it is displayed at the bottom of the screen).

Then you can use "Wallet Details" tab where you can enter the private key (you just got from "Split wallet tab") and check if public address (from "Split Wallet" tab and "Wallet details" tab) match. If it does, it works!


Quote
What is the best wallet to pay from a paper wallet? iOS or Mac
Mycelium (Android) and Breadwallet (iOS) work great. CoPay
is also fine and it works on Android, iOS and Win phones.


Perfect. Thank you so much!
donator
Activity: 674
Merit: 522
I currently setup my paper wallets and want to use split wallets.

Is there a way to proof the Shares and check if the right private key works or not
without run it live with BTC?

Thank you.
Sure you can! Enter separate shares into "Available Shares (whitespace separated)" and click "Combine Shares" button to get the private key (it is displayed at the bottom of the screen).

Then you can use "Wallet Details" tab where you can enter the private key (you just got from "Split wallet tab") and check if public address (from "Split Wallet" tab and "Wallet details" tab) match. If it does, it works!


Quote
What is the best wallet to pay from a paper wallet? iOS or Mac
Mycelium (Android) and Breadwallet (iOS) work great. CoPay
is also fine and it works on Android, iOS and Win phones.
sr. member
Activity: 424
Merit: 343
One more question:

What is the best wallet to pay from a paper wallet? iOS or Mac
sr. member
Activity: 424
Merit: 343
I currently setup my paper wallets and want to use split wallets.

Is there a way to proof the Shares and check if the right private key works or not
without run it live with BTC?

The find the private key I can only use bitaddress.org or is there also other ways
in case the service is offline in a couple of years?

I just don´t want to lose my money Smiley

Thank you.
sr. member
Activity: 424
Merit: 343
Why are someone is going to encrypt the paper wallet?
I think the bigger risk is not that the wallet get stolen instead of forget the passphrase. Or I don´t unterstand the idea behind it?

When securing your coins you have two conflicting issues to address:

1) you want to be able to access the coins at some point in the future
2) you don't want anyone else to be able to access the coins without your permission

If you don't encrypt your paper wallet then you are making (1) more likely, but (2) less likely. If anyone finds your printed paper wallet they can immediately just take your coins.

So you encrypt it. It's relatively hard to crack the password on paper wallets, but there's a risk that you will forget the password yourself. So (1) is less likely, but (2) is more likely.

It's a trade off. Encrypt if you like. Or don't.

Thank you very much for your explanation.
I personally think the higher risk is to forget in a couple of years the passphrase - all BTC are useless, that will be one of the hardest pain, especially if it >10k/btc
legendary
Activity: 2940
Merit: 1330
@pointbiz:
I find labeling in v3.2.0 a little bit confusing:

In "Single wallet" tab, string "Bitcoin Address" represents compressed address.
In "Wallet Details" tab, string "Bitcoin Address" represents normal uncompressed address.
The same is true for private keys...

Also - if usage of compressed keys is preferred, it would make sense (at least to me) that compressed bitcoin address would be the first choice (on the left side) in "Wallet Details" tab.

Just my 0.00000002


Yes, I see what you are saying. I want to make wallet details less confusing. And de-emphasize the uncompressed info.

Also in v3.2.0 I found another confusing inconsistency:

If I use the 'paper wallet' or 'bulk wallet' tabs to encrypt a private key, I get a "6Pn" (compressed) or "6Pf" (not compressed) encrypted private key, whereas if I use the 'wallet details' tab to encrypt the same private key, I get a "6PY" (compressed) or "6PR" (not compressed) encrypted private key.

The little research I did tells me that 6Pn and 6Pf represent "Encryption when EC multiply mode is used" whereas 6PY and 6PR represent "Encryption when EC multiply flag is not used".

Why is "multiply mode" used in 2 of the 3 tabs offering encryption but not in the 3rd? Is that deliberate? Is there a good reason for it? Is using "multiply mode" any more or less secure than not using it?
legendary
Activity: 2940
Merit: 1330
Why are someone is going to encrypt the paper wallet?
I think the bigger risk is not that the wallet get stolen instead of forget the passphrase. Or I don´t unterstand the idea behind it?

When securing your coins you have two conflicting issues to address:

1) you want to be able to access the coins at some point in the future
2) you don't want anyone else to be able to access the coins without your permission

If you don't encrypt your paper wallet then you are making (1) more likely, but (2) less likely. If anyone finds your printed paper wallet they can immediately just take your coins.

So you encrypt it. It's relatively hard to crack the password on paper wallets, but there's a risk that you will forget the password yourself. So (1) is less likely, but (2) is more likely.

It's a trade off. Encrypt if you like. Or don't.
sr. member
Activity: 424
Merit: 343
Why are someone is going to encrypt the paper wallet?
I think the bigger risk is not that the wallet get stolen instead of forget the passphrase. Or I don´t unterstand the idea behind it?
sr. member
Activity: 437
Merit: 415
1ninja
@pointbiz:
I find labeling in v3.2.0 a little bit confusing:

In "Single wallet" tab, string "Bitcoin Address" represents compressed address.
In "Wallet Details" tab, string "Bitcoin Address" represents normal uncompressed address.
The same is true for private keys...

Also - if usage of compressed keys is preferred, it would make sense (at least to me) that compressed bitcoin address would be the first choice (on the left side) in "Wallet Details" tab.

Just my 0.00000002


Yes, I see what you are saying. I want to make wallet details less confusing. And de-emphasize the uncompressed info.
donator
Activity: 674
Merit: 522
@pointbiz:
I find labeling in v3.2.0 a little bit confusing:

In "Single wallet" tab, string "Bitcoin Address" represents compressed address.
In "Wallet Details" tab, string "Bitcoin Address" represents normal uncompressed address.
The same is true for private keys...

Also - if usage of compressed keys is preferred, it would make sense (at least to me) that compressed bitcoin address would be the first choice (on the left side) in "Wallet Details" tab.

Just my 0.00000002
hero member
Activity: 836
Merit: 1007
"How do you eat an elephant? One bit at a time..."
I'm trying to understand the use case/purpose for having the compressed address. Can anyone enlighten?



Compressed public keys are 66 hex characters. Uncompressed are 130 hex characters. Using compressed keys saves space in the block chain because the transaction size is smaller and potentially would reduce the transaction fee which is calculated by transaction size in the reference bitcoin implementation.

There is no downside.

Thank you!

sr. member
Activity: 437
Merit: 415
1ninja
I'm trying to understand the use case/purpose for having the compressed address. Can anyone enlighten?



Compressed public keys are 66 hex characters. Uncompressed are 130 hex characters. Using compressed keys saves space in the block chain because the transaction size is smaller and potentially would reduce the transaction fee which is calculated by transaction size in the reference bitcoin implementation.

There is no downside.
Pages:
Jump to: